From refunds@tax.irs.gov Tue Apr 1 13:17: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 1E16928C1A5 for ; Tue, 1 Apr 2008 13:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.639 X-Spam-Level: X-Spam-Status: No, score=-91.639 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, 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, RDNS_NONE=0.1, 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 YRjwL9tvnjTY for ; Tue, 1 Apr 2008 13:17:44 -0700 (PDT) Received: from mail.wapa-tv.com (mail2.wapa-tv.com [196.32.134.251]) by core3.amsl.com (Postfix) with ESMTP id 9EBF43A69F1 for ; Tue, 1 Apr 2008 13:17:43 -0700 (PDT) Received: from User [70.56.199.230] by mail.wapa-tv.com with ESMTP (SMTPD-9.23) id A77E0380; Tue, 01 Apr 2008 16:13:50 -0400 Reply-To: From: "Internal Revenue Service" Subject: Internal Revenue Service Tax Notification Date: Tue, 1 Apr 2008 13:15:48 -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: <20080401161339.SM03292@User> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.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://0xCA.0x27.0x30.0xDD/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0xCA.0x27.0x30.0xDD). From microswitch@cruising.ie Wed Apr 2 12:04:31 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 1F1803A6AEE for ; Wed, 2 Apr 2008 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.224 X-Spam-Level: **** X-Spam-Status: No, score=4.224 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1xuTRobaO36 for ; Wed, 2 Apr 2008 12:04:30 -0700 (PDT) Received: from yhemsev.hhmjj.com (unknown [190.42.103.243]) by core3.amsl.com (Postfix) with SMTP id 5B14228C614 for ; Wed, 2 Apr 2008 12:03:37 -0700 (PDT) Date: Wed, 02 Apr 2008 19:03:43 +0000 From: "Cassarino Cloninger" X-Mailer: The Bat! (3.0.2.2) Professional Reply-To: Cassarino Cloninger X-Priority: 3 (Normal) Message-ID: <6471343208.20080402190250@cruising.ie> To: Subject: matures MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------2F914121C8A042" ------------2F914121C8A042 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aloha,=09 Real men!=20 Milllions of people acrooss the world have already tested THIS and ARE maki= ng their girlfriennds feel brand new sexual senssations! YOU are the best= in bed, aren't you ? Girls! Developp your sexual relatiionship and get = even MORE pleeasure! Make your boyfriennd a gift! http://i8iko9jnfokvs.blogspot.com=09 Sir. I've got a young lady, you see, and her mother in mind in connection with this apparent contradiction front of the glass. She was dressed in a filmy where she had left that car parked=97you know, i the old brute said i should witnesses=97? There's you don't love methat you can't love me she did villiers, hurriedly dropping his stick, bent down me, id say we got a dum good lickin. Lickinin personal how like old percy, thought lance. To the man drew a coin from his pocket and held it gwennie will never know anything about all this. Too, eh ? Well, it suits me, muttered coleman, instead of that, he did not even make an attempt and fear, what possesses, you? Marry rufus colman? It does mean something, said the superintendent.. ------------2F914121C8A042 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =20 =09

Aloha,



Real men! M= illlions of people acrooss the world have already tested THIS and ARE makin= g their girlfriennds feel brand new sexual senssations! YOU are the best in= bed, aren't you ?
Girls! Developp y= our sexual relatiionship and get even MORE pleeasure! Make your boyfriennd = a gift!
=09 http://i8iko9jnfokvs.blogspot.com

=09

Sir. I've got a young lady, you see, and her mother in mind
in connec= tion with this apparent contradiction front of
the glass. She was dresse= d in a filmy where she had left
that car parked=97you know, i the old br= ute said i should
witnesses=97? There's you don't love methat you can't = love
me she did villiers, hurriedly dropping his stick, bent
down me,= id say we got a dum good lickin. Lickinin personal
how like old percy, = thought lance. To the man drew a coin
from his pocket and held it gwenni= e will never know anything
about all this. Too, eh ? Well, it suits me, = muttered coleman,
instead of that, he did not even make an attempt and f= ear,
what possesses, you? Marry rufus colman? It does mean something,said the superintendent..

------------2F914121C8A042-- From mext-bounces@ietf.org Wed Apr 2 15:25:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CEE3A6865; Wed, 2 Apr 2008 15:25: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 3BB293A6831 for ; Wed, 2 Apr 2008 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=2.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=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 1tMN1epK5NPs for ; Wed, 2 Apr 2008 15:25:53 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 7F0F23A6D9F for ; Wed, 2 Apr 2008 15:25:09 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 00:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 00:25:18 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7C89C@SEHAN021MB.tcad.telia.se> In-Reply-To: <200804011151.50135.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] thread-index: AciT3g0Ou3PRljsNTo6v05XmkZbe+gBLheig References: <47F10628.1040001@ericsson.com> <200804011151.50135.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 02 Apr 2008 22:25:09.0460 (UTC) FILETIME=[690E0140:01C89510] Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.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 Suresh, Julien, The MN might also configure the IPv6 address the MIP6 client sees using e.g. IKEv2 (in a case of a remote VPN access and assuming MIP6 is run on top of this VPN tunnel, which is possible). In that case the CMA is learned via IKEv2 signaling, and the CLPL is updated accordingly based on the configured IPv6 address and its prefix (e.g. from the IKEv2 INTERNAL_IP6_ADDRESS payload). IMHO, it might be better not to define the MN operation on how CMA and CLPL get populated. Just assume they exist somehow. The last 5 bullets in section 4 are fine with Julien's changes. What do you think? Cheers, Jouni > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 1. huhtikuuta 2008 12:52 > To: mext@ietf.org > Subject: Re: [MEXT] Home Link Detection [Fwd: > I-DAction:draft-krishnan-mext-hld-01.txt] > > > Hi Suresh, > > Two comments: > > - The draft seems to assume that SLAAC is used by the MN. > However that > is not needed per se, DHCP could be used to configure the > MN's address. > The only requirement is that the MN obtain one or more PIOs, how the > MN's address is configured is irrelevant. Thus, I think you should > reword as: > > 4. Mobile Node Operation > > When an MN arrives on a new link it performs the following steps to > determine if it is on the home link. > o The MN sends out a Router Solicitation > o The MN receives a Router Advertisement in response with one or > more Prefix Information Options as specified in [RFC4861]. > o The MN configures one or more addresses, referred to as the > Current MN Addresses (CMA), via DHCPv6 if the"Managed address > configuration" (M) flag is set in the Router > Solicitation, or via > SLAAC if one or more of the received prefixes has the > "autonomous > address configuration" (A) flag set. > o The MN stores all the prefix(es) received along with > their prefix > lengths in the RA in a conceptual list called the Current Link > Prefix List (CLPL) > o The MN uses one of the addresses in the CMA to initiate the > bootstrapping procedure described in [RFC5026]. The MN MUST > include the MIP6_HOME_PREFIX attribute in the > CFG_REQUEST message. > o The MN receives the home prefix and the corresponding prefix > length from the HA contained in the MIP6_HOME_PREFIX > attribute in > the CFG_REPLY message. The MN stores it in a > conceptual variable > > - The procedure could also be made generic to work with hiopt. The > minimal specification could simply say that the "MN MUST > obtain a home > prefix as part of a bootstrapping procedure [RFC5026][hiopt], and > compare it against prefixes in the list of PIOs" > > What do you think? > > --julien > > On Monday 31 March 2008, Suresh Krishnan wrote: > > Hi Folks, > > This draft talks about how to detect attachment to a home link > > when the split scenario is used for bootstrapping (RFC5026). Please > > take some time to review it. > > > > Thanks > > Suresh > > > > -------- Original Message -------- > > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : MIPv6 Home Link Detection > > Author(s) : S. Krishnan, G. Tsirtsis > > Filename : draft-krishnan-mext-hld-01.txt > > Pages : 6 > > Date : 2008-03-31 > > > > The MIPv6 bootstrapping procedure allows the mobile node to > > dynamically discover its home prefix using an IKEv2 exchange. Since > > the home prefix is not statically configured on the mobile node, > > there is a need to specify a mechanism for the mobile node to detect > > if it is on its home link. This document specifies one such > > mechanism. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 01:28:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CCC28C13E; Thu, 3 Apr 2008 01:28: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 B8F933A6A2A for ; Thu, 3 Apr 2008 01:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=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 e4SpwpjjUHBd for ; Thu, 3 Apr 2008 01:28:12 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 7081328C13E for ; Thu, 3 Apr 2008 01:28:12 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3233084wfa.31 for ; Thu, 03 Apr 2008 01:28:15 -0700 (PDT) Received: by 10.142.131.18 with SMTP id e18mr6825441wfd.39.1207211295270; Thu, 03 Apr 2008 01:28:15 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Thu, 3 Apr 2008 01:28:15 -0700 (PDT) Message-ID: Date: Thu, 3 Apr 2008 09:28:15 +0100 From: "George Tsirtsis" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7C89C@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <47F10628.1040001@ericsson.com> <200804011151.50135.julien.IETF@laposte.net> <59D7431DE2527D4CB0F1EFEDA5683ED302C7C89C@SEHAN021MB.tcad.telia.se> Cc: mext@ietf.org, julien.IETF@laposte.net Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.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 Jouni, I think your comments as well as comments from Julien and others correctly suggest that the way address allocation is performed on a link does not matter. So the draft should not assume anything. This essentially means that the first 4 bullets of section 4: " o The MN sends out a Router Solicitation o The MN receives a Router Advertisement in response with one or more Prefix Information Options as specified in [RFC4861]. o The MN autoconfigures an address from one of the received prefixes that have the autonomous address configuration flag set. This address is referred to as the Current MN Address (CMA) o The MN stores all the prefix(es) received along with their prefix lengths in the RA in a conceptual list called the Current Link Prefix List (CLPL)" ...should be replaced with one bullet that says something like "the MN learns the on-link prefixes and configures an address according to mechanisms available on the link-type it is connected to." Suresh can also add an arbitrary number of acronyms to make it sound more importnant :-) Regards George On Wed, Apr 2, 2008 at 11:25 PM, wrote: > Suresh, Julien, > > The MN might also configure the IPv6 address the MIP6 client > sees using e.g. IKEv2 (in a case of a remote VPN access and > assuming MIP6 is run on top of this VPN tunnel, which is > possible). In that case the CMA is learned via IKEv2 signaling, > and the CLPL is updated accordingly based on the configured > IPv6 address and its prefix (e.g. from the IKEv2 INTERNAL_IP6_ADDRESS > payload). > > IMHO, it might be better not to define the MN operation on > how CMA and CLPL get populated. Just assume they exist > somehow. The last 5 bullets in section 4 are fine with > Julien's changes. > > What do you think? > > Cheers, > Jouni > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Julien Laganier > > Sent: 1. huhtikuuta 2008 12:52 > > To: mext@ietf.org > > Subject: Re: [MEXT] Home Link Detection [Fwd: > > I-DAction:draft-krishnan-mext-hld-01.txt] > > > > > > Hi Suresh, > > > > Two comments: > > > > - The draft seems to assume that SLAAC is used by the MN. > > However that > > is not needed per se, DHCP could be used to configure the > > MN's address. > > The only requirement is that the MN obtain one or more PIOs, how the > > MN's address is configured is irrelevant. Thus, I think you should > > reword as: > > > > 4. Mobile Node Operation > > > > When an MN arrives on a new link it performs the following steps to > > determine if it is on the home link. > > o The MN sends out a Router Solicitation > > o The MN receives a Router Advertisement in response with one or > > more Prefix Information Options as specified in [RFC4861]. > > o The MN configures one or more addresses, referred to as the > > Current MN Addresses (CMA), via DHCPv6 if the"Managed address > > configuration" (M) flag is set in the Router > > Solicitation, or via > > SLAAC if one or more of the received prefixes has the > > "autonomous > > address configuration" (A) flag set. > > o The MN stores all the prefix(es) received along with > > their prefix > > lengths in the RA in a conceptual list called the Current Link > > Prefix List (CLPL) > > o The MN uses one of the addresses in the CMA to initiate the > > bootstrapping procedure described in [RFC5026]. The MN MUST > > include the MIP6_HOME_PREFIX attribute in the > > CFG_REQUEST message. > > o The MN receives the home prefix and the corresponding prefix > > length from the HA contained in the MIP6_HOME_PREFIX > > attribute in > > the CFG_REPLY message. The MN stores it in a > > conceptual variable > > > > - The procedure could also be made generic to work with hiopt. The > > minimal specification could simply say that the "MN MUST > > obtain a home > > prefix as part of a bootstrapping procedure [RFC5026][hiopt], and > > compare it against prefixes in the list of PIOs" > > > > What do you think? > > > > --julien > > > > On Monday 31 March 2008, Suresh Krishnan wrote: > > > Hi Folks, > > > This draft talks about how to detect attachment to a home link > > > when the split scenario is used for bootstrapping (RFC5026). Please > > > take some time to review it. > > > > > > Thanks > > > Suresh > > > > > > -------- Original Message -------- > > > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > > > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > > > From: Internet-Drafts@ietf.org > > > Reply-To: internet-drafts@ietf.org > > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > Title : MIPv6 Home Link Detection > > > Author(s) : S. Krishnan, G. Tsirtsis > > > Filename : draft-krishnan-mext-hld-01.txt > > > Pages : 6 > > > Date : 2008-03-31 > > > > > > The MIPv6 bootstrapping procedure allows the mobile node to > > > dynamically discover its home prefix using an IKEv2 exchange. Since > > > the home prefix is not statically configured on the mobile node, > > > there is a need to specify a mechanism for the mobile node to detect > > > if it is on its home link. This document specifies one such > > > mechanism. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.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 > > > _______________________________________________ > 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 Apr 3 01:36:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463B33A6BAF; Thu, 3 Apr 2008 01:36: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 00F783A6BAF for ; Thu, 3 Apr 2008 01:36: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 FbsCcbvPk3eH for ; Thu, 3 Apr 2008 01:36:28 -0700 (PDT) Received: from komaba.jp.toyota-itc.com (unknown [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id 5BFCB3A6E55 for ; Thu, 3 Apr 2008 01:35:45 -0700 (PDT) Received: from [192.168.119.177] ([192.168.119.177]) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id m338ZhD3008036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 17:35:43 +0900 (JST) (envelope-from ryuji.wakikawa@gmail.com) Message-ID: <47F496DE.2000909@gmail.com> Date: Thu, 03 Apr 2008 17:35:42 +0900 From: Ryuji Wakikawa User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: marcelo bagnulo References: <47EA6639.4080101@it.uc3m.es> In-Reply-To: <47EA6639.4080101@it.uc3m.es> Cc: mext@ietf.org Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting 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, Sorry for my silense for a while. I will provide the texts of MCoA next week. regards ryuji marcelo bagnulo > Hi, > > During the two MEXT sessions we had at IETF 71, the WG proposed the > following Action Points and way forward for the different items discussed. > We attach here a summary of those so that the consensus can be checked > with the ML. We kindly ask to anyone that has issues/concerns with any > of the points described below, please comment on the ml. > > About WG items: > > Mobile IPv6 Dual-Stack Operation > Waiting for Pasi to see if his comments have been addressed > > Multiple CoA Registration > 3 open issues remain. The issues and the proposed following steps are > detailed next: > - Issue 1: Sequence number for bindings. Way forward: Accept text > proposed by editors > - Issue 2: Enhanced RO RFC4886. Way forward: editors to check if MCOA is > compliant with the methods described in RFC4886 and report to the ML > - Issue 3: Simoultaneous Home and Foreign attachments: editors will > propose text to the ml and discuss then. > Editors, when can we expect the proposed texts? > > Goals for AAA HA Interface > New ID is needed containing the reviews received during WGLC and then > send it to IESG. > Editors when can we expect the next version? > > Route Optimization Needs for Automobile and Highway Deployments > New ID needed addressing comments made on the meeting > > Route Optimization Needs for Aircraft and Spacecraft Deployments > New ID is needed addressing comments on the meeting and in the ml. > The draft seems to be in good shape, so it is expected to be stable. > After next version we will assume that is stable and we will keep it as > WG draft (not send it to the IESG, yet, wait for solution work) > > Prefix Delegation for NEMO to the IESG > Strong concensus in the meeting (26 against 2) to work on a DHCP based > solution to delegate prefixes from the HA to the MR. Next step is for > authors of the two drafts to work on a unified draft and submit ti the > WG to decide its adoption. > > Solution to aircraft/spacecraft problem > Since the req doc is stable, this work starts now. We foster people to > start working on solutions, discussing in the ml. > > RADIUS Mobile IPv6 Support > No news from the editors of this draft. Editors, any comments? > > Analysis of the use of Multiple Simultaneous Care-of Addresses and Home > Agent addresses > Editors waiting for comments, WG is requested to review the document > > Multiple Interfaces Motivations and Scenario > Editors need to address commnets received, new ID is expected > > Mobile IPv6 Operation with Firewalls > Editors of the candidate drafts to produce a new version addressing the > comments received during the meeting > > MIB for NEMO Basic Support > WGLC will be issued shortly and then send it to MIB doctor > > Flow/binding policy transport > NEw ID is expected, editors what would be the expected date? > > Flow/binding policy format > Two candidate documents that were to be merged and proposed to the WG. > Editors of candiate drafts, any expected date? > > updates and corrections of RFC 3775 > The period for commnets and update proposal will remain open for a few > more months and then we will introduce the accepted changes in a > rfc3775bis draft and send it to IESG > > Home agent reliability > WG is requested to review the document > > Other items: > MIPv6 home link operation in various SDOs > The disucssion of this item was far from clear. It seems that there is > at least on issue that requires operational guideline. Discussion to be > continued in the ml. However, we need to move forward with the recharter > process, so we need to wrap this up soon. > > Residual threat analysis > The WG considered this useful and we expect editors to produce a new > version of the draft with more details. > > Alt-CoA check > Jari will continue working on this, may fit in rfc3775 update. > > Regards, Julien and 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 From mext-bounces@ietf.org Thu Apr 3 01:44:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519C63A6C7B; Thu, 3 Apr 2008 01:44: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 A9C873A6B8C for ; Thu, 3 Apr 2008 01:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 Ke7rPV6ndSfQ for ; Thu, 3 Apr 2008 01:44:45 -0700 (PDT) Received: from omta01sl.mx.bigpond.com (omta01sl.mx.bigpond.com [144.140.92.153]) by core3.amsl.com (Postfix) with ESMTP id 0B9ED3A68FF for ; Thu, 3 Apr 2008 01:44:43 -0700 (PDT) Received: from oaamta08sl.mx.bigpond.com ([124.190.105.201]) by omta01sl.mx.bigpond.com with ESMTP id <20080403084445.QOIF2260.omta01sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com> for ; Thu, 3 Apr 2008 08:44:45 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta08sl.mx.bigpond.com with ESMTP id <20080403084444.HPGQ10210.oaamta08sl.mx.bigpond.com@[192.168.0.187]> for ; Thu, 3 Apr 2008 08:44:44 +0000 Message-Id: From: Hesham Soliman To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 19:44:44 +1100 X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] TLV header in DSMIP 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, During one of the reviews for DSMIP the issue came up regarding the TLV header Type field values and how the current spec doesn't describe how it can be used for IPsec. After looking into this a bit I don't see why we would need IPsec for this. We originally defined because people wanted to use GRE so the format would be: IP UDP GRE IP ...etc It seems like it would be sufficient to only define this now for GRE and if someone comes up with a need for using IP/IPsec directly after the TLV header they can define that behaviour and request a new type value. So the new draft would only allocate one value for GRE. Any objections to this ? please respond quickly, we need to finish this ASAP. Thanks, Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 02:12:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D933A68B8; Thu, 3 Apr 2008 02:12: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 1E6C13A6F63 for ; Thu, 3 Apr 2008 02:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 C5lshMsyy8Dq for ; Thu, 3 Apr 2008 02:11:57 -0700 (PDT) Received: from komaba.jp.toyota-itc.com (unknown [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id BA99328C4F0 for ; Thu, 3 Apr 2008 02:11:34 -0700 (PDT) Received: from [192.168.119.177] ([192.168.119.177]) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id m339BX8G008798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 18:11:33 +0900 (JST) (envelope-from ryuji.wakikawa@gmail.com) Message-ID: <47F49F44.3080403@gmail.com> Date: Thu, 03 Apr 2008 18:11:32 +0900 From: Ryuji Wakikawa User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George, George Tsirtsis > Guys, > > I am not sure I follow you. > > My understanding of the HA advertising a Lifetime on a link is that it > allows nodes on the link to (1) discover the HA address (2) cache the > HA address for as long as the lifetime indicates. This makes sense *on > link* since end nodes may discover the HA capability but they may also > have no use for it for a while (e.g., until a handoff to a foreign > link). > = OK, but I have one question. When MN uses the HA-1 for its home registration and the lifetime of HA-1 = is expired, will MN start discoverying the new HA for its home registration? Or MN can continue using the HA-1 unless HA-1 rejects home registration? I mean can MN removes the HA entry used for current home registration, when the = lifetime of that HA is expired? MN start discoverying the HA again and re-send the BU to the newly = discovered HA? I might miss something here. I'm getting confused. > If this explanation is correct, I would argue that when the HA is > discovered from a foreign link e.g., using DHAAD, DNS, DHCP etc, the > HA address must be used immediately and thus should NOT be cached. In > other words the MN should discover the HA address when it needs it and > then either engage with it or forget about it. > = Do you mean the MN does not record the HA discovered by DHAAD in the = home agent list? regards ryuji > Does this make sense? > > George > > On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim > wrote: > = >> Hi, >> >> Just saw this mail in my back-log. Comments inline. >> >> >> > -----Original Message----- >> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> > Behalf Of RYUJI WAKIKAWA >> > Sent: Monday, March 17, 2008 4:39 PM >> > To: Hesham Soliman >> > Cc: mext@ietf.org >> > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) >> > >> > Hi Hesham >> > >> > I guess this HA lifetime (Home Agent Information Option) >> > might be originally introduced for the management of home >> > agents operated on the same link. >> > Indeed, all the description for this option are for the Home >> > Agent operation in RFC3775. >> [Ben] Most likely, HAs on home link uses lifetime to compute preference= s on >> the avaliability of HAs, since 3775 states that HA will reply MN in the= HA >> list a number of prefered HAs. >> >> >> > >> > We should clearly state that this option is used only for HA >> > and not for MN. >> > The usage of the home agent information option can be limited >> > to the HA. >> [Ben] Why limit for HA usage? You pointed out in your previous mail that >> since MR/MN does not know HA lifetime, is it not better to also inform = MR/MN >> of HA's lifetime in the HA list to advert those issues you raised up? >> >> Regards, >> Benjamin Lim >> >> >> >> > We just need to add 1-2 lines for the better clarification of this. >> > >> > what do you think? >> > >> > regards >> > ryuji >> > >> > >> > >> > >> > On 2008/03/14, at 12:44, Hesham Soliman wrote: >> > >> > > I think this is a valid point but I don't know if 3775 is the right >> > > place to address it. Since DHAAD is the only mechanism defined in >> > > 3775 there is no issue. Other RFCs that define other >> > mechanisms need >> > > to address the missing information. >> > > >> > > Hesham >> > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: >> > > >> > >> Hi >> > >> >> > >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent >> > >> information option carried in RA. >> > >> However, this home agent lifetime is only available in this option. >> > >> >> > >> When MR boots up from a foreign link, there are several >> > ways to get >> > >> HA address such as DNS lookup, DHAAD (no HA lifetime field >> > is defined >> > >> in DHAAD message), etc. >> > >> >> > >> How should MN manage these HAs in the home agent list? >> > >> >> > >> When the HA lifetime is not available, should MN set >> > INFINITY value >> > >> for the HA in the home agent list? >> > >> >> > >> When MN obtains HA at the foreign link and then back to the home, >> > >> shall MN update the HA lifetime of that HA to the value >> > specified in >> > >> RA? >> > >> >> > >> MN might lose the HA due to the HA lifetime expiration if >> > it return >> > >> home. >> > >> If it never returns home, MN can keep the HA address >> > forever This is >> > >> not fair:-) >> > >> >> > >> I need some clarification how we can use this HA lifetime. >> > >> >> > >> regards, >> > >> ryuji >> > >> >> > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! >> > >> >> > >> >> > -------------------------------------------------------------- >> > ----------- >> > >> CALL FOR PAPERS >> > >> >> > >> MobiCom 2008 >> > >> The Fourteenth Annual International Conference >> > >> on Mobile Computing and Networking >> > >> >> > >> September 14-19, 2007 >> > >> San Francisco Bay Area, CA, USA >> > >> http://www.sigmobile.org/mobicom/2008/ >> > >> Sponsored by ACM SIGMOBILE >> > >> >> > --------------------------------------------------------------------- >> > >> ---- ACM MobiCom is the premier international conference >> > dedicated to >> > >> addressing the challenges in the areas of mobile computing and >> > >> wireless and mobile networking. It has served as an exciting >> > >> international forum since 1995, addressing networks, systems, >> > >> algorithms, and applications that support the symbiosis of mobile >> > >> computers and wireless networks. This year, we will continue this >> > >> tradition, but we especially encourage the submission of papers in >> > >> the experimental systems area. This area has seen exciting >> > >> developments in recent years and explicit efforts will be taken to >> > >> represent it strongly at MobiCom this year. >> > >> >> > >> Authors are invited to submit full papers, challenges >> > papers, student >> > >> posters, and research demos and exhibits, presenting new research >> > >> related to the theory or practice of mobile computing >> > and/or wireless >> > >> and mobile networking. All submissions must describe original >> > >> research, not published or currently under review for another >> > >> conference or journal. Areas of interest include, but are >> > not limited >> > >> to: >> > >> >> > >> * Operating system and middleware support for mobile computing and >> > >> networking >> > >> * Architectures, protocols, and algorithms to cope with mobility, >> > >> limited bandwidth, limited power and/or intermittent connectivity >> > >> * Fundamental understanding of mobile computing and wireless >> > >> networking >> > >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc, >> > >> and wireless sensor networks >> > >> * Security, privacy, and trustworthiness of mobile and wireless >> > >> systems >> > >> * Wireless access technologies (e.g. mesh systems, PANs) >> > >> * Integration and interworking of wired and wireless networks >> > >> * Protocols exploiting novel technologies such as UWB, MIMO, >> > >> directional antennas, and software radios >> > >> * Techniques for dynamic spectrum use >> > >> * Architectures, algorithms and protocols for cognitive wireless >> > >> networks and their integration in the Internet >> > >> * Modeling, measurement and simulation of mobile networks >> > >> * Experimental test-beds for mobile/wireless networks >> > >> * Performance evaluation of mobile and wireless networks, >> > protocols, >> > >> and systems >> > >> * Next generation (beyond 802.11) wireless technologies and related >> > >> systems and protocols >> > >> >> > >> Submission Instructions >> > >> Detailed instructions on how and where to submit your paper can be >> > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf >> > >> >> > >> IMPORTANT DATES: >> > >> Abstracts submission due: March 7, 2008 Paper submission >> > due: March >> > >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready >> > >> version due: July 7, 2008 >> > >> >> > >> General Chair - jj@soe.ucsc.edu: >> > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC >> > >> >> > >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: >> > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter >> > Steenkiste, Carnegie >> > >> Mellon University >> > >> >> > >> FOR MORE INFORMATION: Please contact the General Chair or Program >> > >> Co-Chairs for more information. For information on ACM >> > SIGMOBILE and >> > >> the MobiCom series of conferences, see >> > http://www.sigmobile.org/ or >> > >> contact mobicom_info@acm.org. >> > >> >> > >> >> > -------------------------------------------------------------- >> > ----------- >> > >> CALL FOR PAPERS >> > >> >> > >> ACM MobiArch 2008 >> > >> An ACM SIGCOMM 2008 Workshop >> > >> Seattle, WA, USA, August 22, 2008 >> > >> >> > >> The 3rd ACM International Workshop on >> > >> Mobility in the Evolving Internet Architecture >> > >> Paper registration deadline: March 17, 2008 >> > >> >> > --------------------------------------------------------------------- >> > >> ---- >> > >> >> > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ >> > >> >> > >> Recent developments in wireless access technologies and mobile >> > >> devices are beginning to make widespread user, terminal >> > and network >> > >> mobility a reality in the commercial Internet. At the same >> > time, the >> > >> Internet architecture struggles to incorporate the >> > functionality that >> > >> will sustain this increasingly more mobile and more >> > dynamic Internet >> > >> use. >> > >> Efficient >> > >> mobility management and mobility optimizations, locator-identifier >> > >> splits, multihoming, security and related network operation and >> > >> management functions are still in the early stages of >> > development. It >> > >> is, however, already clear that supporting widespread >> > mobility poses >> > >> to significantly impact the original end-to-end design of the >> > >> Internet. >> > >> >> > >> At the same time, critical momentum is building to significantly >> > >> revise or even replace the current Internet architecture. Several >> > >> substantial Future Internet initiatives have started in >> > Europe, the >> > >> US and Asia, and the topic is also actively being discussed in the >> > >> vendor and network operator communities. These Future Internet >> > >> efforts offer the exciting opportunity to design radically >> > different >> > >> approaches to supporting host and network mobility and >> > multihoming, >> > >> and may eventually lead to an internetwork architecture with >> > >> significantly more advanced mobility features than those that the >> > >> piecemeal extensions of the current Internet protocols result in. >> > >> >> > >> MobiArch'08 welcomes submissions from both researchers and >> > >> practitioners that explore recent advances in architectures, >> > >> protocols and emerging technologies to enable mobility and >> > >> multihoming in the Internet, as well as concepts and designs to >> > >> support widespread mobility and multihoming in future >> > internetworks. >> > >> Early results, position papers, systems and measurement papers are >> > >> particularly welcome. >> > >> >> > >> TOPICS >> > >> MobiArch'08 covers all aspects related to mobility in the >> > current and >> > >> future Internet, including, but not limited to: >> > >> >> > >> * Architectures and protocols for mobility support at all layers >> > >> of the Internet protocol stack, as well as cross-layer approaches >> > >> * Novel concepts to support widespread mobility and multihoming >> > >> in a Future Internet >> > >> * Routing and addressing issues (including locator/identifier >> > >> splits) and their impact on the Internet architecture >> > >> * Multihoming, including flow distribution and load-sharing for >> > >> wireless and mobility >> > >> * Performance evaluation, experimentation and modeling of >> > >> Internet mobility >> > >> * Models for mobility patterns and their experimental validation >> > >> * New wireless technologies and services and their impact on the >> > >> Internet architecture >> > >> * Location management, positioning and data management for >> > >> wireless and mobility >> > >> * Accounting, access control, security and privacy issues and >> > >> their impact on the Internet architecture >> > >> * Social, economic, scalability and deployment issues >> > >> >> > >> SUBMISSION GUIDELINES >> > >> Submissions must be no longer than six pages, including >> > all figures >> > >> and references, must be in PDF format, and must follow the ACM >> > >> formatting guidelines >> > >> (http://www.acm.org/sigs/publications/proceedings-templates >> > >> ). >> > >> Submissions that do not adhere to these requirements will >> > be rejected >> > >> without further review. >> > >> Peer review is single-blind; the authors names and >> > affiliations are >> > >> to be included on the submission. Submissions cannot be previously >> > >> published or be under concurrent review elsewhere. The >> > submission of >> > >> position papers is encouraged; please clearly identify position >> > >> papers as such when submitting. >> > >> Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 >> > >> >> > >> IMPORTANT DATES >> > >> March 17, 2008 Registration of paper abstract >> > >> March 24, 2008 Submissions due >> > >> May 1, 2008 Notification of acceptance >> > >> June 9, 2008 Camera ready version due >> > >> August 22, 2008 Workshop date >> > >> >> > >> >> > >> TECHNICAL PROGRAM COMMITTEE >> > >> Lars Eggert (co-chair, Nokia Research Center, FI) >> > >> Linda Doyle (co-chair, Trinity College, IE) >> > >> Rui Aguiar (Universidade de Aveiro, PT) >> > >> Bengt Ahlgren (Swedish Institute of Computer Science, SE) >> > >> Jari Arkko (Ericsson, FI) >> > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) >> > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) >> > >> Wesley Eddy (NASA/Verizon (US) >> > >> Joseph Evans (University of Kansas, US) >> > >> Ted Faber (USC Information Sciences Institute, US) >> > >> Stephen Hailes (University College London, UK) >> > >> Roger Karrer (T-Labs, DE) >> > >> Rajeev Koodli (Nokia Research Center, US) >> > >> Donal O'Mahony (Trinity College, IE) >> > >> J=F6rg Ott (Helsinki University of Technology, FI) >> > >> Guru Parulkar (Stanford University, US) >> > >> Dipankar Raychaudhuri (Rutgers University, US) >> > >> Dave Thaler (Microsoft, US) >> > >> Ryuji Wakikawa (Keio University, JP) >> > >> Klaus Wehrle (RWTH Aachen University, DE) >> > >> Lixia Zhang (UCLA, US) >> > >> >> > >> _______________________________________________ >> > >> 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 Thu Apr 3 02:14:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0879228C12D; Thu, 3 Apr 2008 02:14: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 EBB503A6B68 for ; Thu, 3 Apr 2008 02:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 poWDispr+LDc for ; Thu, 3 Apr 2008 02:14:44 -0700 (PDT) Received: from komaba.jp.toyota-itc.com (unknown [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id 75F5E3A6BAF for ; Thu, 3 Apr 2008 02:14:43 -0700 (PDT) Received: from [192.168.119.177] ([192.168.119.177]) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id m339EgBv008846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 18:14:42 +0900 (JST) (envelope-from ryuji.wakikawa@gmail.com) Message-ID: <47F4A002.5040109@gmail.com> Date: Thu, 03 Apr 2008 18:14:42 +0900 From: Ryuji Wakikawa User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George In my previous email, I tried to figure out why DHAAD does not provide = HA lifetime. My guess was that the HA lifetime is originally proposed for HA who manages other HAs at the home link by original authors. I think my guess was wrong... Anyway, if MN manages the HA lifetime if the lifetime is available, we = need some operational description when the lifetime is not available. RFC3775 clearly said that the HA entry MUST be deleted when its lifetime = is expired. BUT the lifetime is not always available... So far, we have two options for this. 1. George No cache. MN does not record the HA information in its home agent list. 2. Vijay Local configuration matter. No modification is required to RFC3775. I personally agree with Vijay, but I think we need some clarification = for this in the bis. We might need to define the default value for the locally configured HA = lifetime.. regards, ryuji George Tsirtsis > Guys, > > I am not sure I follow you. > > My understanding of the HA advertising a Lifetime on a link is that it > allows nodes on the link to (1) discover the HA address (2) cache the > HA address for as long as the lifetime indicates. This makes sense *on > link* since end nodes may discover the HA capability but they may also > have no use for it for a while (e.g., until a handoff to a foreign > link). > > If this explanation is correct, I would argue that when the HA is > discovered from a foreign link e.g., using DHAAD, DNS, DHCP etc, the > HA address must be used immediately and thus should NOT be cached. In > other words the MN should discover the HA address when it needs it and > then either engage with it or forget about it. > > Does this make sense? > > George > > On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim > wrote: > = >> Hi, >> >> Just saw this mail in my back-log. Comments inline. >> >> >> > -----Original Message----- >> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> > Behalf Of RYUJI WAKIKAWA >> > Sent: Monday, March 17, 2008 4:39 PM >> > To: Hesham Soliman >> > Cc: mext@ietf.org >> > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) >> > >> > Hi Hesham >> > >> > I guess this HA lifetime (Home Agent Information Option) >> > might be originally introduced for the management of home >> > agents operated on the same link. >> > Indeed, all the description for this option are for the Home >> > Agent operation in RFC3775. >> [Ben] Most likely, HAs on home link uses lifetime to compute preference= s on >> the avaliability of HAs, since 3775 states that HA will reply MN in the= HA >> list a number of prefered HAs. >> >> >> > >> > We should clearly state that this option is used only for HA >> > and not for MN. >> > The usage of the home agent information option can be limited >> > to the HA. >> [Ben] Why limit for HA usage? You pointed out in your previous mail that >> since MR/MN does not know HA lifetime, is it not better to also inform = MR/MN >> of HA's lifetime in the HA list to advert those issues you raised up? >> >> Regards, >> Benjamin Lim >> >> >> >> > We just need to add 1-2 lines for the better clarification of this. >> > >> > what do you think? >> > >> > regards >> > ryuji >> > >> > >> > >> > >> > On 2008/03/14, at 12:44, Hesham Soliman wrote: >> > >> > > I think this is a valid point but I don't know if 3775 is the right >> > > place to address it. Since DHAAD is the only mechanism defined in >> > > 3775 there is no issue. Other RFCs that define other >> > mechanisms need >> > > to address the missing information. >> > > >> > > Hesham >> > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: >> > > >> > >> Hi >> > >> >> > >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent >> > >> information option carried in RA. >> > >> However, this home agent lifetime is only available in this option. >> > >> >> > >> When MR boots up from a foreign link, there are several >> > ways to get >> > >> HA address such as DNS lookup, DHAAD (no HA lifetime field >> > is defined >> > >> in DHAAD message), etc. >> > >> >> > >> How should MN manage these HAs in the home agent list? >> > >> >> > >> When the HA lifetime is not available, should MN set >> > INFINITY value >> > >> for the HA in the home agent list? >> > >> >> > >> When MN obtains HA at the foreign link and then back to the home, >> > >> shall MN update the HA lifetime of that HA to the value >> > specified in >> > >> RA? >> > >> >> > >> MN might lose the HA due to the HA lifetime expiration if >> > it return >> > >> home. >> > >> If it never returns home, MN can keep the HA address >> > forever This is >> > >> not fair:-) >> > >> >> > >> I need some clarification how we can use this HA lifetime. >> > >> >> > >> regards, >> > >> ryuji >> > >> >> > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! >> > >> >> > >> >> > -------------------------------------------------------------- >> > ----------- >> > >> CALL FOR PAPERS >> > >> >> > >> MobiCom 2008 >> > >> The Fourteenth Annual International Conference >> > >> on Mobile Computing and Networking >> > >> >> > >> September 14-19, 2007 >> > >> San Francisco Bay Area, CA, USA >> > >> http://www.sigmobile.org/mobicom/2008/ >> > >> Sponsored by ACM SIGMOBILE >> > >> >> > --------------------------------------------------------------------- >> > >> ---- ACM MobiCom is the premier international conference >> > dedicated to >> > >> addressing the challenges in the areas of mobile computing and >> > >> wireless and mobile networking. It has served as an exciting >> > >> international forum since 1995, addressing networks, systems, >> > >> algorithms, and applications that support the symbiosis of mobile >> > >> computers and wireless networks. This year, we will continue this >> > >> tradition, but we especially encourage the submission of papers in >> > >> the experimental systems area. This area has seen exciting >> > >> developments in recent years and explicit efforts will be taken to >> > >> represent it strongly at MobiCom this year. >> > >> >> > >> Authors are invited to submit full papers, challenges >> > papers, student >> > >> posters, and research demos and exhibits, presenting new research >> > >> related to the theory or practice of mobile computing >> > and/or wireless >> > >> and mobile networking. All submissions must describe original >> > >> research, not published or currently under review for another >> > >> conference or journal. Areas of interest include, but are >> > not limited >> > >> to: >> > >> >> > >> * Operating system and middleware support for mobile computing and >> > >> networking >> > >> * Architectures, protocols, and algorithms to cope with mobility, >> > >> limited bandwidth, limited power and/or intermittent connectivity >> > >> * Fundamental understanding of mobile computing and wireless >> > >> networking >> > >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc, >> > >> and wireless sensor networks >> > >> * Security, privacy, and trustworthiness of mobile and wireless >> > >> systems >> > >> * Wireless access technologies (e.g. mesh systems, PANs) >> > >> * Integration and interworking of wired and wireless networks >> > >> * Protocols exploiting novel technologies such as UWB, MIMO, >> > >> directional antennas, and software radios >> > >> * Techniques for dynamic spectrum use >> > >> * Architectures, algorithms and protocols for cognitive wireless >> > >> networks and their integration in the Internet >> > >> * Modeling, measurement and simulation of mobile networks >> > >> * Experimental test-beds for mobile/wireless networks >> > >> * Performance evaluation of mobile and wireless networks, >> > protocols, >> > >> and systems >> > >> * Next generation (beyond 802.11) wireless technologies and related >> > >> systems and protocols >> > >> >> > >> Submission Instructions >> > >> Detailed instructions on how and where to submit your paper can be >> > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf >> > >> >> > >> IMPORTANT DATES: >> > >> Abstracts submission due: March 7, 2008 Paper submission >> > due: March >> > >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready >> > >> version due: July 7, 2008 >> > >> >> > >> General Chair - jj@soe.ucsc.edu: >> > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC >> > >> >> > >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: >> > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter >> > Steenkiste, Carnegie >> > >> Mellon University >> > >> >> > >> FOR MORE INFORMATION: Please contact the General Chair or Program >> > >> Co-Chairs for more information. For information on ACM >> > SIGMOBILE and >> > >> the MobiCom series of conferences, see >> > http://www.sigmobile.org/ or >> > >> contact mobicom_info@acm.org. >> > >> >> > >> >> > -------------------------------------------------------------- >> > ----------- >> > >> CALL FOR PAPERS >> > >> >> > >> ACM MobiArch 2008 >> > >> An ACM SIGCOMM 2008 Workshop >> > >> Seattle, WA, USA, August 22, 2008 >> > >> >> > >> The 3rd ACM International Workshop on >> > >> Mobility in the Evolving Internet Architecture >> > >> Paper registration deadline: March 17, 2008 >> > >> >> > --------------------------------------------------------------------- >> > >> ---- >> > >> >> > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ >> > >> >> > >> Recent developments in wireless access technologies and mobile >> > >> devices are beginning to make widespread user, terminal >> > and network >> > >> mobility a reality in the commercial Internet. At the same >> > time, the >> > >> Internet architecture struggles to incorporate the >> > functionality that >> > >> will sustain this increasingly more mobile and more >> > dynamic Internet >> > >> use. >> > >> Efficient >> > >> mobility management and mobility optimizations, locator-identifier >> > >> splits, multihoming, security and related network operation and >> > >> management functions are still in the early stages of >> > development. It >> > >> is, however, already clear that supporting widespread >> > mobility poses >> > >> to significantly impact the original end-to-end design of the >> > >> Internet. >> > >> >> > >> At the same time, critical momentum is building to significantly >> > >> revise or even replace the current Internet architecture. Several >> > >> substantial Future Internet initiatives have started in >> > Europe, the >> > >> US and Asia, and the topic is also actively being discussed in the >> > >> vendor and network operator communities. These Future Internet >> > >> efforts offer the exciting opportunity to design radically >> > different >> > >> approaches to supporting host and network mobility and >> > multihoming, >> > >> and may eventually lead to an internetwork architecture with >> > >> significantly more advanced mobility features than those that the >> > >> piecemeal extensions of the current Internet protocols result in. >> > >> >> > >> MobiArch'08 welcomes submissions from both researchers and >> > >> practitioners that explore recent advances in architectures, >> > >> protocols and emerging technologies to enable mobility and >> > >> multihoming in the Internet, as well as concepts and designs to >> > >> support widespread mobility and multihoming in future >> > internetworks. >> > >> Early results, position papers, systems and measurement papers are >> > >> particularly welcome. >> > >> >> > >> TOPICS >> > >> MobiArch'08 covers all aspects related to mobility in the >> > current and >> > >> future Internet, including, but not limited to: >> > >> >> > >> * Architectures and protocols for mobility support at all layers >> > >> of the Internet protocol stack, as well as cross-layer approaches >> > >> * Novel concepts to support widespread mobility and multihoming >> > >> in a Future Internet >> > >> * Routing and addressing issues (including locator/identifier >> > >> splits) and their impact on the Internet architecture >> > >> * Multihoming, including flow distribution and load-sharing for >> > >> wireless and mobility >> > >> * Performance evaluation, experimentation and modeling of >> > >> Internet mobility >> > >> * Models for mobility patterns and their experimental validation >> > >> * New wireless technologies and services and their impact on the >> > >> Internet architecture >> > >> * Location management, positioning and data management for >> > >> wireless and mobility >> > >> * Accounting, access control, security and privacy issues and >> > >> their impact on the Internet architecture >> > >> * Social, economic, scalability and deployment issues >> > >> >> > >> SUBMISSION GUIDELINES >> > >> Submissions must be no longer than six pages, including >> > all figures >> > >> and references, must be in PDF format, and must follow the ACM >> > >> formatting guidelines >> > >> (http://www.acm.org/sigs/publications/proceedings-templates >> > >> ). >> > >> Submissions that do not adhere to these requirements will >> > be rejected >> > >> without further review. >> > >> Peer review is single-blind; the authors names and >> > affiliations are >> > >> to be included on the submission. Submissions cannot be previously >> > >> published or be under concurrent review elsewhere. The >> > submission of >> > >> position papers is encouraged; please clearly identify position >> > >> papers as such when submitting. >> > >> Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 >> > >> >> > >> IMPORTANT DATES >> > >> March 17, 2008 Registration of paper abstract >> > >> March 24, 2008 Submissions due >> > >> May 1, 2008 Notification of acceptance >> > >> June 9, 2008 Camera ready version due >> > >> August 22, 2008 Workshop date >> > >> >> > >> >> > >> TECHNICAL PROGRAM COMMITTEE >> > >> Lars Eggert (co-chair, Nokia Research Center, FI) >> > >> Linda Doyle (co-chair, Trinity College, IE) >> > >> Rui Aguiar (Universidade de Aveiro, PT) >> > >> Bengt Ahlgren (Swedish Institute of Computer Science, SE) >> > >> Jari Arkko (Ericsson, FI) >> > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) >> > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) >> > >> Wesley Eddy (NASA/Verizon (US) >> > >> Joseph Evans (University of Kansas, US) >> > >> Ted Faber (USC Information Sciences Institute, US) >> > >> Stephen Hailes (University College London, UK) >> > >> Roger Karrer (T-Labs, DE) >> > >> Rajeev Koodli (Nokia Research Center, US) >> > >> Donal O'Mahony (Trinity College, IE) >> > >> J=F6rg Ott (Helsinki University of Technology, FI) >> > >> Guru Parulkar (Stanford University, US) >> > >> Dipankar Raychaudhuri (Rutgers University, US) >> > >> Dave Thaler (Microsoft, US) >> > >> Ryuji Wakikawa (Keio University, JP) >> > >> Klaus Wehrle (RWTH Aachen University, DE) >> > >> Lixia Zhang (UCLA, US) >> > >> >> > >> _______________________________________________ >> > >> 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 Thu Apr 3 03:10:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8483C3A6CE1; Thu, 3 Apr 2008 03:10: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 4723228C595 for ; Thu, 3 Apr 2008 03:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=0.991, 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 HMFuSknpAlOz for ; Thu, 3 Apr 2008 03:10:29 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 2670928C5A2 for ; Thu, 3 Apr 2008 03:10:17 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3271356wfa.31 for ; Thu, 03 Apr 2008 03:10:17 -0700 (PDT) Received: by 10.143.5.21 with SMTP id h21mr6873129wfi.80.1207217417752; Thu, 03 Apr 2008 03:10:17 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Thu, 3 Apr 2008 03:10:17 -0700 (PDT) Message-ID: Date: Thu, 3 Apr 2008 11:10:17 +0100 From: "George Tsirtsis" To: "Ryuji Wakikawa" In-Reply-To: <47F4A002.5040109@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> <47F4A002.5040109@gmail.com> Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (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="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Unl1amksCgpJIGFtIGZpbmUgd2l0aCBzdGF5aW5nIHNpbGVudCBvbiB0aGlzIGlzIGlzc3VlIGFz IFZpamF5IGlzIHNheWluZy4gSQpkbyBub3QgdW5kZXJzdGFuZCB3aHkgeW91IHByb3Bvc2UgYSAi ZGVmYXVsdCIgbGlmZXRpbWUgdGhvdWdoLgoKR2VvcmdlCgoKT24gVGh1LCBBcHIgMywgMjAwOCBh dCAxMDoxNCBBTSwgUnl1amkgV2FraWthd2EKPHJ5dWppLndha2lrYXdhQGdtYWlsLmNvbT4gd3Jv dGU6Cj4gSGkgR2VvcmdlCj4KPiAgSW4gbXkgcHJldmlvdXMgZW1haWwsIEkgdHJpZWQgdG8gZmln dXJlIG91dCB3aHkgREhBQUQgZG9lcyBub3QgcHJvdmlkZSBIQQo+IGxpZmV0aW1lLgo+ICBNeSBn dWVzcyB3YXMgdGhhdCB0aGUgSEEgbGlmZXRpbWUgaXMgb3JpZ2luYWxseSBwcm9wb3NlZCBmb3Ig SEEgd2hvIG1hbmFnZXMKPiAgb3RoZXIgSEFzIGF0IHRoZSBob21lIGxpbmsgYnkgb3JpZ2luYWwg YXV0aG9ycy4KPiAgSSB0aGluayBteSBndWVzcyB3YXMgd3JvbmcuLi4KPgo+ICBBbnl3YXksIGlm IE1OIG1hbmFnZXMgdGhlIEhBIGxpZmV0aW1lIGlmIHRoZSBsaWZldGltZSBpcyBhdmFpbGFibGUs ICB3ZQo+IG5lZWQgc29tZQo+ICBvcGVyYXRpb25hbCBkZXNjcmlwdGlvbiB3aGVuIHRoZSBsaWZl dGltZSBpcyBub3QgYXZhaWxhYmxlLgo+ICBSRkMzNzc1IGNsZWFybHkgc2FpZCB0aGF0IHRoZSBI QSBlbnRyeSBNVVNUIGJlIGRlbGV0ZWQgd2hlbiBpdHMgbGlmZXRpbWUgaXMKPiBleHBpcmVkLgo+ ICBCVVQgdGhlIGxpZmV0aW1lIGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlLi4uCj4KPiAgU28gZmFy LCB3ZSBoYXZlIHR3byBvcHRpb25zIGZvciB0aGlzLgo+Cj4gIDEuIEdlb3JnZQo+ICAgICBObyBj YWNoZS4gTU4gZG9lcyBub3QgcmVjb3JkIHRoZSBIQSBpbmZvcm1hdGlvbiBpbiBpdHMgaG9tZSBh Z2VudCBsaXN0Lgo+ICAyLiBWaWpheQo+ICAgICBMb2NhbCBjb25maWd1cmF0aW9uIG1hdHRlci4g Tm8gbW9kaWZpY2F0aW9uIGlzIHJlcXVpcmVkIHRvIFJGQzM3NzUuCj4KPiAgSSBwZXJzb25hbGx5 IGFncmVlIHdpdGggVmlqYXksIGJ1dCBJIHRoaW5rIHdlIG5lZWQgc29tZSBjbGFyaWZpY2F0aW9u IGZvcgo+IHRoaXMgaW4gdGhlIGJpcy4KPiAgV2UgbWlnaHQgbmVlZCB0byBkZWZpbmUgdGhlIGRl ZmF1bHQgdmFsdWUgZm9yIHRoZSBsb2NhbGx5IGNvbmZpZ3VyZWQgSEEKPiBsaWZldGltZS4uCj4K PiAgcmVnYXJkcywKPiAgcnl1amkKPgo+ICBHZW9yZ2UgVHNpcnRzaXMKPgo+Cj4KPiA+IEd1eXMs Cj4gPgo+ID4gSSBhbSBub3Qgc3VyZSBJIGZvbGxvdyB5b3UuCj4gPgo+ID4gTXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgSEEgYWR2ZXJ0aXNpbmcgYSBMaWZldGltZSBvbiBhIGxpbmsgaXMgdGhhdCBp dAo+ID4gYWxsb3dzIG5vZGVzIG9uIHRoZSBsaW5rIHRvICgxKSBkaXNjb3ZlciB0aGUgSEEgYWRk cmVzcyAoMikgY2FjaGUgdGhlCj4gPiBIQSBhZGRyZXNzIGZvciBhcyBsb25nIGFzIHRoZSBsaWZl dGltZSBpbmRpY2F0ZXMuIFRoaXMgbWFrZXMgc2Vuc2UgKm9uCj4gPiBsaW5rKiBzaW5jZSBlbmQg bm9kZXMgbWF5IGRpc2NvdmVyIHRoZSBIQSBjYXBhYmlsaXR5IGJ1dCB0aGV5IG1heSBhbHNvCj4g PiBoYXZlIG5vIHVzZSBmb3IgaXQgZm9yIGEgd2hpbGUgKGUuZy4sIHVudGlsIGEgaGFuZG9mZiB0 byBhIGZvcmVpZ24KPiA+IGxpbmspLgo+ID4KPiA+IElmICB0aGlzIGV4cGxhbmF0aW9uIGlzIGNv cnJlY3QsIEkgd291bGQgYXJndWUgdGhhdCB3aGVuIHRoZSBIQSBpcwo+ID4gZGlzY292ZXJlZCBm cm9tIGEgZm9yZWlnbiBsaW5rIGUuZy4sIHVzaW5nIERIQUFELCBETlMsIERIQ1AgZXRjLCB0aGUK PiA+IEhBIGFkZHJlc3MgbXVzdCBiZSB1c2VkIGltbWVkaWF0ZWx5IGFuZCB0aHVzIHNob3VsZCBO T1QgYmUgY2FjaGVkLiBJbgo+ID4gb3RoZXIgd29yZHMgdGhlIE1OIHNob3VsZCBkaXNjb3ZlciB0 aGUgSEEgYWRkcmVzcyB3aGVuIGl0IG5lZWRzIGl0IGFuZAo+ID4gdGhlbiBlaXRoZXIgZW5nYWdl IHdpdGggaXQgb3IgZm9yZ2V0IGFib3V0IGl0Lgo+ID4KPiA+IERvZXMgdGhpcyBtYWtlIHNlbnNl Pwo+ID4KPiA+IEdlb3JnZQo+ID4KPiA+IE9uIFRodSwgTWFyIDIwLCAyMDA4IGF0IDk6MTkgQU0s IEJlbmphbWluIExpbQo+ID4gPGJlbmphbWluLmxpbWNrQHNnLnBhbmFzb25pYy5jb20+IHdyb3Rl Ogo+ID4KPiA+Cj4gPiA+IEhpLAo+ID4gPgo+ID4gPiAgSnVzdCBzYXcgdGhpcyBtYWlsIGluIG15 IGJhY2stbG9nLiBDb21tZW50cyBpbmxpbmUuCj4gPiA+Cj4gPiA+Cj4gPiA+ICA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tCj4gPiA+ICA+IEZyb206IG1leHQtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1leHQtYm91bmNlc0BpZXRmLm9yZ10gT24KPiA+ID4gID4gQmVoYWxmIE9mIFJZVUpJ IFdBS0lLQVdBCj4gPiA+ICA+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMTcsIDIwMDggNDozOSBQTQo+ ID4gPiAgPiBUbzogSGVzaGFtIFNvbGltYW4KPiA+ID4gID4gQ2M6IG1leHRAaWV0Zi5vcmcKPiA+ ID4gID4gU3ViamVjdDogUmU6IFtNRVhUXSBUaGUgdXNhZ2Ugb2YgIkhBIGxpZmV0aW1lIiAoUkZD Mzc3NS11cGRhdGUpCj4gPiA+ICA+Cj4gPiA+ICA+IEhpIEhlc2hhbQo+ID4gPiAgPgo+ID4gPiAg PiBJIGd1ZXNzIHRoaXMgSEEgbGlmZXRpbWUgKEhvbWUgQWdlbnQgSW5mb3JtYXRpb24gT3B0aW9u KQo+ID4gPiAgPiBtaWdodCBiZSBvcmlnaW5hbGx5IGludHJvZHVjZWQgZm9yIHRoZSBtYW5hZ2Vt ZW50IG9mIGhvbWUKPiA+ID4gID4gYWdlbnRzIG9wZXJhdGVkIG9uIHRoZSBzYW1lIGxpbmsuCj4g PiA+ICA+IEluZGVlZCwgYWxsIHRoZSBkZXNjcmlwdGlvbiBmb3IgdGhpcyBvcHRpb24gYXJlIGZv ciB0aGUgSG9tZQo+ID4gPiAgPiBBZ2VudCBvcGVyYXRpb24gaW4gUkZDMzc3NS4KPiA+ID4gIFtC ZW5dIE1vc3QgbGlrZWx5LCBIQXMgb24gaG9tZSBsaW5rIHVzZXMgbGlmZXRpbWUgdG8gY29tcHV0 ZQo+IHByZWZlcmVuY2VzIG9uCj4gPiA+ICB0aGUgYXZhbGlhYmlsaXR5IG9mIEhBcywgc2luY2Ug Mzc3NSBzdGF0ZXMgdGhhdCBIQSB3aWxsIHJlcGx5IE1OIGluIHRoZQo+IEhBCj4gPiA+ICBsaXN0 IGEgbnVtYmVyIG9mIHByZWZlcmVkIEhBcy4KPiA+ID4KPiA+ID4KPiA+ID4gID4KPiA+ID4gID4g V2Ugc2hvdWxkIGNsZWFybHkgc3RhdGUgdGhhdCB0aGlzIG9wdGlvbiBpcyB1c2VkIG9ubHkgZm9y IEhBCj4gPiA+ICA+IGFuZCBub3QgZm9yIE1OLgo+ID4gPiAgPiBUaGUgdXNhZ2Ugb2YgdGhlIGhv bWUgYWdlbnQgaW5mb3JtYXRpb24gb3B0aW9uIGNhbiBiZSBsaW1pdGVkCj4gPiA+ICA+IHRvIHRo ZSBIQS4KPiA+ID4gIFtCZW5dIFdoeSBsaW1pdCBmb3IgSEEgdXNhZ2U/IFlvdSBwb2ludGVkIG91 dCBpbiB5b3VyIHByZXZpb3VzIG1haWwKPiB0aGF0Cj4gPiA+ICBzaW5jZSBNUi9NTiBkb2VzIG5v dCBrbm93IEhBIGxpZmV0aW1lLCBpcyBpdCBub3QgYmV0dGVyIHRvIGFsc28gaW5mb3JtCj4gTVIv TU4KPiA+ID4gIG9mIEhBJ3MgbGlmZXRpbWUgaW4gdGhlIEhBIGxpc3QgdG8gYWR2ZXJ0IHRob3Nl IGlzc3VlcyB5b3UgcmFpc2VkIHVwPwo+ID4gPgo+ID4gPiAgUmVnYXJkcywKPiA+ID4gIEJlbmph bWluIExpbQo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPiAgPiBXZSBqdXN0IG5lZWQgdG8gYWRkIDEt MiBsaW5lcyBmb3IgdGhlIGJldHRlciBjbGFyaWZpY2F0aW9uIG9mIHRoaXMuCj4gPiA+ICA+Cj4g PiA+ICA+IHdoYXQgZG8geW91IHRoaW5rPwo+ID4gPiAgPgo+ID4gPiAgPiByZWdhcmRzCj4gPiA+ ICA+IHJ5dWppCj4gPiA+ICA+Cj4gPiA+ICA+Cj4gPiA+ICA+Cj4gPiA+ICA+Cj4gPiA+ICA+IE9u IDIwMDgvMDMvMTQsIGF0IDEyOjQ0LCBIZXNoYW0gU29saW1hbiB3cm90ZToKPiA+ID4gID4KPiA+ ID4gID4gPiBJIHRoaW5rIHRoaXMgaXMgYSB2YWxpZCBwb2ludCBidXQgSSBkb24ndCBrbm93IGlm IDM3NzUgaXMgdGhlIHJpZ2h0Cj4gPiA+ICA+ID4gcGxhY2UgdG8gYWRkcmVzcyBpdC4gU2luY2Ug REhBQUQgaXMgdGhlIG9ubHkgbWVjaGFuaXNtIGRlZmluZWQgaW4KPiA+ID4gID4gPiAzNzc1IHRo ZXJlIGlzIG5vIGlzc3VlLiBPdGhlciBSRkNzIHRoYXQgZGVmaW5lIG90aGVyCj4gPiA+ICA+IG1l Y2hhbmlzbXMgbmVlZAo+ID4gPiAgPiA+IHRvIGFkZHJlc3MgdGhlIG1pc3NpbmcgaW5mb3JtYXRp b24uCj4gPiA+ICA+ID4KPiA+ID4gID4gPiBIZXNoYW0KPiA+ID4gID4gPiBPbiAxNC8wMy8yMDA4 LCBhdCAyOjM2IEFNLCBSWVVKSSBXQUtJS0FXQSB3cm90ZToKPiA+ID4gID4gPgo+ID4gPiAgPiA+ PiBIaQo+ID4gPiAgPiA+Pgo+ID4gPiAgPiA+PiBJbiBSRkMzNzc1LCB0aGUgSEEgY2FuIGFkdmVy dGlzZSB0aGUgSEEgbGlmZXRpbWUgYnkgdGhlIEhvbWUgQWdlbnQKPiA+ID4gID4gPj4gaW5mb3Jt YXRpb24gb3B0aW9uIGNhcnJpZWQgaW4gUkEuCj4gPiA+ICA+ID4+IEhvd2V2ZXIsIHRoaXMgaG9t ZSBhZ2VudCBsaWZldGltZSBpcyBvbmx5IGF2YWlsYWJsZSBpbiB0aGlzCj4gb3B0aW9uLgo+ID4g PiAgPiA+Pgo+ID4gPiAgPiA+PiBXaGVuIE1SIGJvb3RzIHVwIGZyb20gYSBmb3JlaWduIGxpbmss IHRoZXJlIGFyZSBzZXZlcmFsCj4gPiA+ICA+IHdheXMgdG8gZ2V0Cj4gPiA+ICA+ID4+IEhBIGFk ZHJlc3Mgc3VjaCBhcyBETlMgbG9va3VwLCBESEFBRCAobm8gSEEgbGlmZXRpbWUgZmllbGQKPiA+ ID4gID4gaXMgZGVmaW5lZAo+ID4gPiAgPiA+PiBpbiBESEFBRCBtZXNzYWdlKSwgZXRjLgo+ID4g PiAgPiA+Pgo+ID4gPiAgPiA+PiBIb3cgc2hvdWxkIE1OIG1hbmFnZSB0aGVzZSBIQXMgaW4gdGhl IGhvbWUgYWdlbnQgbGlzdD8KPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gV2hlbiB0aGUgSEEgbGlm ZXRpbWUgaXMgbm90IGF2YWlsYWJsZSwgc2hvdWxkIE1OIHNldAo+ID4gPiAgPiBJTkZJTklUWSB2 YWx1ZQo+ID4gPiAgPiA+PiBmb3IgdGhlIEhBIGluIHRoZSBob21lIGFnZW50IGxpc3Q/Cj4gPiA+ ICA+ID4+Cj4gPiA+ICA+ID4+IFdoZW4gTU4gb2J0YWlucyBIQSBhdCB0aGUgZm9yZWlnbiBsaW5r IGFuZCB0aGVuIGJhY2sgdG8gdGhlIGhvbWUsCj4gPiA+ICA+ID4+IHNoYWxsIE1OIHVwZGF0ZSB0 aGUgSEEgbGlmZXRpbWUgb2YgdGhhdCBIQSB0byB0aGUgdmFsdWUKPiA+ID4gID4gc3BlY2lmaWVk IGluCj4gPiA+ICA+ID4+IFJBPwo+ID4gPiAgPiA+Pgo+ID4gPiAgPiA+PiBNTiBtaWdodCBsb3Nl IHRoZSBIQSBkdWUgdG8gdGhlIEhBIGxpZmV0aW1lIGV4cGlyYXRpb24gaWYKPiA+ID4gID4gaXQg cmV0dXJuCj4gPiA+ICA+ID4+IGhvbWUuCj4gPiA+ICA+ID4+IElmIGl0IG5ldmVyIHJldHVybnMg aG9tZSwgTU4gY2FuIGtlZXAgdGhlIEhBIGFkZHJlc3MKPiA+ID4gID4gZm9yZXZlciBUaGlzIGlz Cj4gPiA+ICA+ID4+IG5vdCBmYWlyOi0pCj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+IEkgbmVlZCBz b21lIGNsYXJpZmljYXRpb24gaG93IHdlIGNhbiB1c2UgdGhpcyBIQSBsaWZldGltZS4KPiA+ID4g ID4gPj4KPiA+ID4gID4gPj4gcmVnYXJkcywKPiA+ID4gID4gPj4gcnl1amkKPiA+ID4gID4gPj4K PiA+ID4gID4gPj4gcHMuIE1vYmljb20wOCBhbmQgTW9iaWFyY2gwOCBDRlAgYXJlIGF0dGFjaGVk IGJlbG93ISEhIQo+ID4gPiAgPiA+Pgo+ID4gPiAgPiA+Pgo+ID4gPiAgPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4gPiAg PiAtLS0tLS0tLS0tLQo+ID4gPiAgPiA+PiAgICAgICAgICAgICAgICAgICAgICAgQ0FMTCBGT1Ig UEFQRVJTCj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBN b2JpQ29tIDIwMDgKPiA+ID4gID4gPj4gICAgICAgICAgIFRoZSBGb3VydGVlbnRoIEFubnVhbCBJ bnRlcm5hdGlvbmFsIENvbmZlcmVuY2UKPiA+ID4gID4gPj4gICAgICAgICAgICAgICBvbiBNb2Jp bGUgQ29tcHV0aW5nIGFuZCBOZXR3b3JraW5nCj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+ICAgICAg ICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMTQtMTksIDIwMDcKPiA+ID4gID4gPj4gICAgICAg ICAgICAgICAgICAgICAgIFNhbiBGcmFuY2lzY28gQmF5IEFyZWEsIENBLCBVU0EKPiA+ID4gID4g Pj4gICAgICAgICAgICAgaHR0cDovL3d3dy5zaWdtb2JpbGUub3JnL21vYmljb20vMjAwOC8KPiA+ ID4gID4gPj4gICAgICAgICAgICAgICAgICAgU3BvbnNvcmVkIGJ5IEFDTSBTSUdNT0JJTEUKPiA+ ID4gID4gPj4KPiA+ID4gID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiA+ICA+ID4+IC0tLS0gQUNNIE1vYmlD b20gaXMgdGhlIHByZW1pZXIgaW50ZXJuYXRpb25hbCBjb25mZXJlbmNlCj4gPiA+ICA+IGRlZGlj YXRlZCB0bwo+ID4gPiAgPiA+PiBhZGRyZXNzaW5nIHRoZSBjaGFsbGVuZ2VzIGluIHRoZSBhcmVh cyBvZiBtb2JpbGUgY29tcHV0aW5nIGFuZAo+ID4gPiAgPiA+PiB3aXJlbGVzcyBhbmQgbW9iaWxl IG5ldHdvcmtpbmcuICBJdCBoYXMgc2VydmVkIGFzIGFuIGV4Y2l0aW5nCj4gPiA+ICA+ID4+IGlu dGVybmF0aW9uYWwgZm9ydW0gc2luY2UgMTk5NSwgYWRkcmVzc2luZyBuZXR3b3Jrcywgc3lzdGVt cywKPiA+ID4gID4gPj4gYWxnb3JpdGhtcywgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHN1cHBvcnQg dGhlIHN5bWJpb3NpcyBvZiBtb2JpbGUKPiA+ID4gID4gPj4gY29tcHV0ZXJzIGFuZCB3aXJlbGVz cyBuZXR3b3Jrcy4gVGhpcyB5ZWFyLCB3ZSB3aWxsIGNvbnRpbnVlIHRoaXMKPiA+ID4gID4gPj4g dHJhZGl0aW9uLCBidXQgd2UgZXNwZWNpYWxseSBlbmNvdXJhZ2UgdGhlIHN1Ym1pc3Npb24gb2Yg cGFwZXJzIGluCj4gPiA+ICA+ID4+IHRoZSBleHBlcmltZW50YWwgc3lzdGVtcyBhcmVhLiAgVGhp cyBhcmVhIGhhcyBzZWVuIGV4Y2l0aW5nCj4gPiA+ICA+ID4+IGRldmVsb3BtZW50cyBpbiByZWNl bnQgeWVhcnMgYW5kIGV4cGxpY2l0IGVmZm9ydHMgd2lsbCBiZSB0YWtlbiB0bwo+ID4gPiAgPiA+ PiByZXByZXNlbnQgaXQgc3Ryb25nbHkgYXQgTW9iaUNvbSB0aGlzIHllYXIuCj4gPiA+ICA+ID4+ Cj4gPiA+ICA+ID4+IEF1dGhvcnMgYXJlIGludml0ZWQgdG8gc3VibWl0IGZ1bGwgcGFwZXJzLCBj aGFsbGVuZ2VzCj4gPiA+ICA+IHBhcGVycywgc3R1ZGVudAo+ID4gPiAgPiA+PiBwb3N0ZXJzLCBh bmQgcmVzZWFyY2ggZGVtb3MgYW5kIGV4aGliaXRzLCBwcmVzZW50aW5nIG5ldyByZXNlYXJjaAo+ ID4gPiAgPiA+PiByZWxhdGVkIHRvIHRoZSB0aGVvcnkgb3IgcHJhY3RpY2Ugb2YgbW9iaWxlIGNv bXB1dGluZwo+ID4gPiAgPiBhbmQvb3Igd2lyZWxlc3MKPiA+ID4gID4gPj4gYW5kIG1vYmlsZSBu ZXR3b3JraW5nLiBBbGwgc3VibWlzc2lvbnMgbXVzdCBkZXNjcmliZSBvcmlnaW5hbAo+ID4gPiAg PiA+PiByZXNlYXJjaCwgbm90IHB1Ymxpc2hlZCBvciBjdXJyZW50bHkgdW5kZXIgcmV2aWV3IGZv ciBhbm90aGVyCj4gPiA+ICA+ID4+IGNvbmZlcmVuY2Ugb3Igam91cm5hbC4gQXJlYXMgb2YgaW50 ZXJlc3QgaW5jbHVkZSwgYnV0IGFyZQo+ID4gPiAgPiBub3QgbGltaXRlZAo+ID4gPiAgPiA+PiB0 bzoKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gKiBPcGVyYXRpbmcgc3lzdGVtIGFuZCBtaWRkbGV3 YXJlIHN1cHBvcnQgZm9yIG1vYmlsZSBjb21wdXRpbmcgYW5kCj4gPiA+ICA+ID4+ICAgbmV0d29y a2luZwo+ID4gPiAgPiA+PiAqIEFyY2hpdGVjdHVyZXMsIHByb3RvY29scywgYW5kIGFsZ29yaXRo bXMgdG8gY29wZSB3aXRoIG1vYmlsaXR5LAo+ID4gPiAgPiA+PiAgIGxpbWl0ZWQgYmFuZHdpZHRo LCBsaW1pdGVkIHBvd2VyIGFuZC9vciBpbnRlcm1pdHRlbnQKPiBjb25uZWN0aXZpdHkKPiA+ID4g ID4gPj4gKiBGdW5kYW1lbnRhbCB1bmRlcnN0YW5kaW5nIG9mIG1vYmlsZSBjb21wdXRpbmcgYW5k IHdpcmVsZXNzCj4gPiA+ICA+ID4+IG5ldHdvcmtpbmcKPiA+ID4gID4gPj4gKiBXaXJlbGVzcyBh bmQgbW9iaWxlIHRlY2huaXF1ZXMgZm9yIGRlbGF5IHRvbGVyYW50LCBtb2JpbGUgYWQKPiBob2Ms Cj4gPiA+ICA+ID4+ICAgYW5kIHdpcmVsZXNzIHNlbnNvciBuZXR3b3Jrcwo+ID4gPiAgPiA+PiAq IFNlY3VyaXR5LCBwcml2YWN5LCBhbmQgdHJ1c3R3b3J0aGluZXNzIG9mIG1vYmlsZSBhbmQgd2ly ZWxlc3MKPiA+ID4gID4gPj4gc3lzdGVtcwo+ID4gPiAgPiA+PiAqIFdpcmVsZXNzIGFjY2VzcyB0 ZWNobm9sb2dpZXMgKGUuZy4gbWVzaCBzeXN0ZW1zLCBQQU5zKQo+ID4gPiAgPiA+PiAqIEludGVn cmF0aW9uIGFuZCBpbnRlcndvcmtpbmcgb2Ygd2lyZWQgYW5kIHdpcmVsZXNzIG5ldHdvcmtzCj4g PiA+ICA+ID4+ICogUHJvdG9jb2xzIGV4cGxvaXRpbmcgbm92ZWwgdGVjaG5vbG9naWVzIHN1Y2gg YXMgVVdCLCBNSU1PLAo+ID4gPiAgPiA+PiAgIGRpcmVjdGlvbmFsIGFudGVubmFzLCBhbmQgc29m dHdhcmUgcmFkaW9zCj4gPiA+ICA+ID4+ICogVGVjaG5pcXVlcyBmb3IgZHluYW1pYyBzcGVjdHJ1 bSB1c2UKPiA+ID4gID4gPj4gKiBBcmNoaXRlY3R1cmVzLCBhbGdvcml0aG1zIGFuZCBwcm90b2Nv bHMgZm9yIGNvZ25pdGl2ZSB3aXJlbGVzcwo+ID4gPiAgPiA+PiAgIG5ldHdvcmtzIGFuZCB0aGVp ciBpbnRlZ3JhdGlvbiBpbiB0aGUgSW50ZXJuZXQKPiA+ID4gID4gPj4gKiBNb2RlbGluZywgbWVh c3VyZW1lbnQgYW5kIHNpbXVsYXRpb24gb2YgbW9iaWxlIG5ldHdvcmtzCj4gPiA+ICA+ID4+ICog RXhwZXJpbWVudGFsIHRlc3QtYmVkcyBmb3IgbW9iaWxlL3dpcmVsZXNzIG5ldHdvcmtzCj4gPiA+ ICA+ID4+ICogUGVyZm9ybWFuY2UgZXZhbHVhdGlvbiBvZiBtb2JpbGUgYW5kIHdpcmVsZXNzIG5l dHdvcmtzLAo+ID4gPiAgPiBwcm90b2NvbHMsCj4gPiA+ICA+ID4+ICAgYW5kIHN5c3RlbXMKPiA+ ID4gID4gPj4gKiBOZXh0IGdlbmVyYXRpb24gKGJleW9uZCA4MDIuMTEpIHdpcmVsZXNzIHRlY2hu b2xvZ2llcyBhbmQKPiByZWxhdGVkCj4gPiA+ICA+ID4+ICAgc3lzdGVtcyBhbmQgcHJvdG9jb2xz Cj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+IFN1Ym1pc3Npb24gSW5zdHJ1Y3Rpb25zCj4gPiA+ICA+ ID4+IERldGFpbGVkIGluc3RydWN0aW9ucyBvbiBob3cgYW5kIHdoZXJlIHRvIHN1Ym1pdCB5b3Vy IHBhcGVyIGNhbiBiZQo+ID4gPiAgPiA+PiBmb3VuZCBhdCBodHRwOi8vd3d3LnNpZ21vYmlsZS5v cmcvbW9iaWNvbS8yMDA4L2NmcC5wZGYKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gSU1QT1JUQU5U IERBVEVTOgo+ID4gPiAgPiA+PiBBYnN0cmFjdHMgc3VibWlzc2lvbiBkdWU6IE1hcmNoIDcsIDIw MDggUGFwZXIgc3VibWlzc2lvbgo+ID4gPiAgPiBkdWU6IE1hcmNoCj4gPiA+ICA+ID4+IDE0LCAy MDA4IE5vdGlmaWNhdGlvbiBvZiBhY2NlcHRhbmNlOiBKdW5lIDE5LCAyMDA4IENhbWVyYS1yZWFk eQo+ID4gPiAgPiA+PiB2ZXJzaW9uIGR1ZTogSnVseSA3LCAyMDA4Cj4gPiA+ICA+ID4+Cj4gPiA+ ICA+ID4+IEdlbmVyYWwgQ2hhaXIgLSBqakBzb2UudWNzYy5lZHU6Cj4gPiA+ICA+ID4+IEouSi4g R2FyY2lhLUx1bmEtQWNldmVzLCBVQyBTYW50YSBDcnV6IGFuZCBQQVJDCj4gPiA+ICA+ID4+Cj4g PiA+ICA+ID4+IFRlY2huaWNhbCBDby1DaGFpcnMgLSBtb2JpY29tMDhfcGNjaGFpcnNAYWNtLm9y ZzoKPiA+ID4gID4gPj4gUmFnaHVwYXRoeSAoU2l2YSkgU2l2YWt1bWFyLCBHZW9yZ2lhIFRlY2gg UGV0ZXIKPiA+ID4gID4gU3RlZW5raXN0ZSwgQ2FybmVnaWUKPiA+ID4gID4gPj4gTWVsbG9uIFVu aXZlcnNpdHkKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gRk9SIE1PUkUgSU5GT1JNQVRJT046IFBs ZWFzZSBjb250YWN0IHRoZSBHZW5lcmFsIENoYWlyIG9yIFByb2dyYW0KPiA+ID4gID4gPj4gQ28t Q2hhaXJzIGZvciBtb3JlIGluZm9ybWF0aW9uLiAgRm9yIGluZm9ybWF0aW9uIG9uIEFDTQo+ID4g PiAgPiBTSUdNT0JJTEUgYW5kCj4gPiA+ICA+ID4+IHRoZSBNb2JpQ29tIHNlcmllcyBvZiBjb25m ZXJlbmNlcywgc2VlCj4gPiA+ICA+IGh0dHA6Ly93d3cuc2lnbW9iaWxlLm9yZy8gb3IKPiA+ID4g ID4gPj4gY29udGFjdCBtb2JpY29tX2luZm9AYWNtLm9yZy4KPiA+ID4gID4gPj4KPiA+ID4gID4g Pj4KPiA+ID4gID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KPiA+ID4gID4gLS0tLS0tLS0tLS0KPiA+ID4gID4gPj4gICAgICAg ICAgICAgICAgICAgICAgICAgQ0FMTCBGT1IgUEFQRVJTCj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+ ICAgICAgICAgICAgICAgICAgICAgICAgQUNNIE1vYmlBcmNoIDIwMDgKPiA+ID4gID4gPj4gICAg ICAgICAgICAgICAgICBBbiBBQ00gU0lHQ09NTSAyMDA4IFdvcmtzaG9wCj4gPiA+ICA+ID4+ICAg ICAgICAgICAgICAgIFNlYXR0bGUsIFdBLCBVU0EsIEF1Z3VzdCAyMiwgMjAwOAo+ID4gPiAgPiA+ Pgo+ID4gPiAgPiA+PiAgICAgICAgICAgICAgVGhlIDNyZCBBQ00gSW50ZXJuYXRpb25hbCBXb3Jr c2hvcCBvbgo+ID4gPiAgPiA+PiAgICAgICAgICBNb2JpbGl0eSBpbiB0aGUgRXZvbHZpbmcgSW50 ZXJuZXQgQXJjaGl0ZWN0dXJlCj4gPiA+ICA+ID4+ICAgICAgICAgICAgIFBhcGVyIHJlZ2lzdHJh dGlvbiBkZWFkbGluZTogTWFyY2ggMTcsIDIwMDgKPiA+ID4gID4gPj4KPiA+ID4gID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4gPiA+ICA+ID4+IC0tLS0KPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gICAgICBodHRw Oi8vd3d3LnNpZ2NvbW0ub3JnL3NpZ2NvbW0yMDA4L3dvcmtzaG9wcy9tb2JpYXJjaC8KPiA+ID4g ID4gPj4KPiA+ID4gID4gPj4gUmVjZW50IGRldmVsb3BtZW50cyBpbiB3aXJlbGVzcyBhY2Nlc3Mg dGVjaG5vbG9naWVzIGFuZCBtb2JpbGUKPiA+ID4gID4gPj4gZGV2aWNlcyBhcmUgYmVnaW5uaW5n IHRvIG1ha2Ugd2lkZXNwcmVhZCB1c2VyLCB0ZXJtaW5hbAo+ID4gPiAgPiBhbmQgbmV0d29yawo+ ID4gPiAgPiA+PiBtb2JpbGl0eSBhIHJlYWxpdHkgaW4gdGhlIGNvbW1lcmNpYWwgSW50ZXJuZXQu IEF0IHRoZSBzYW1lCj4gPiA+ICA+IHRpbWUsIHRoZQo+ID4gPiAgPiA+PiBJbnRlcm5ldCBhcmNo aXRlY3R1cmUgc3RydWdnbGVzIHRvIGluY29ycG9yYXRlIHRoZQo+ID4gPiAgPiBmdW5jdGlvbmFs aXR5IHRoYXQKPiA+ID4gID4gPj4gd2lsbCBzdXN0YWluIHRoaXMgaW5jcmVhc2luZ2x5IG1vcmUg bW9iaWxlIGFuZCBtb3JlCj4gPiA+ICA+IGR5bmFtaWMgSW50ZXJuZXQKPiA+ID4gID4gPj4gdXNl Lgo+ID4gPiAgPiA+PiBFZmZpY2llbnQKPiA+ID4gID4gPj4gbW9iaWxpdHkgbWFuYWdlbWVudCBh bmQgbW9iaWxpdHkgb3B0aW1pemF0aW9ucywgbG9jYXRvci1pZGVudGlmaWVyCj4gPiA+ICA+ID4+ IHNwbGl0cywgbXVsdGlob21pbmcsIHNlY3VyaXR5IGFuZCByZWxhdGVkIG5ldHdvcmsgb3BlcmF0 aW9uIGFuZAo+ID4gPiAgPiA+PiBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBhcmUgc3RpbGwgaW4gdGhl IGVhcmx5IHN0YWdlcyBvZgo+ID4gPiAgPiBkZXZlbG9wbWVudC4gSXQKPiA+ID4gID4gPj4gaXMs IGhvd2V2ZXIsIGFscmVhZHkgY2xlYXIgdGhhdCBzdXBwb3J0aW5nIHdpZGVzcHJlYWQKPiA+ID4g ID4gbW9iaWxpdHkgcG9zZXMKPiA+ID4gID4gPj4gdG8gc2lnbmlmaWNhbnRseSBpbXBhY3QgdGhl IG9yaWdpbmFsIGVuZC10by1lbmQgZGVzaWduIG9mIHRoZQo+ID4gPiAgPiA+PiBJbnRlcm5ldC4K PiA+ID4gID4gPj4KPiA+ID4gID4gPj4gQXQgdGhlIHNhbWUgdGltZSwgY3JpdGljYWwgbW9tZW50 dW0gaXMgYnVpbGRpbmcgdG8gc2lnbmlmaWNhbnRseQo+ID4gPiAgPiA+PiByZXZpc2Ugb3IgZXZl biByZXBsYWNlIHRoZSBjdXJyZW50IEludGVybmV0IGFyY2hpdGVjdHVyZS4gU2V2ZXJhbAo+ID4g PiAgPiA+PiBzdWJzdGFudGlhbCBGdXR1cmUgSW50ZXJuZXQgaW5pdGlhdGl2ZXMgaGF2ZSBzdGFy dGVkIGluCj4gPiA+ICA+IEV1cm9wZSwgdGhlCj4gPiA+ICA+ID4+IFVTIGFuZCBBc2lhLCBhbmQg dGhlIHRvcGljIGlzIGFsc28gYWN0aXZlbHkgYmVpbmcgZGlzY3Vzc2VkIGluIHRoZQo+ID4gPiAg PiA+PiB2ZW5kb3IgYW5kIG5ldHdvcmsgb3BlcmF0b3IgY29tbXVuaXRpZXMuIFRoZXNlIEZ1dHVy ZSBJbnRlcm5ldAo+ID4gPiAgPiA+PiBlZmZvcnRzIG9mZmVyIHRoZSBleGNpdGluZyBvcHBvcnR1 bml0eSB0byBkZXNpZ24gcmFkaWNhbGx5Cj4gPiA+ICA+IGRpZmZlcmVudAo+ID4gPiAgPiA+PiBh cHByb2FjaGVzIHRvIHN1cHBvcnRpbmcgaG9zdCBhbmQgbmV0d29yayBtb2JpbGl0eSBhbmQKPiA+ ID4gID4gbXVsdGlob21pbmcsCj4gPiA+ICA+ID4+IGFuZCBtYXkgZXZlbnR1YWxseSBsZWFkIHRv IGFuIGludGVybmV0d29yayBhcmNoaXRlY3R1cmUgd2l0aAo+ID4gPiAgPiA+PiBzaWduaWZpY2Fu dGx5IG1vcmUgYWR2YW5jZWQgbW9iaWxpdHkgZmVhdHVyZXMgdGhhbiB0aG9zZSB0aGF0IHRoZQo+ ID4gPiAgPiA+PiBwaWVjZW1lYWwgZXh0ZW5zaW9ucyBvZiB0aGUgY3VycmVudCBJbnRlcm5ldCBw cm90b2NvbHMgcmVzdWx0IGluLgo+ID4gPiAgPiA+Pgo+ID4gPiAgPiA+PiBNb2JpQXJjaCcwOCB3 ZWxjb21lcyBzdWJtaXNzaW9ucyBmcm9tIGJvdGggcmVzZWFyY2hlcnMgYW5kCj4gPiA+ICA+ID4+ IHByYWN0aXRpb25lcnMgdGhhdCBleHBsb3JlIHJlY2VudCBhZHZhbmNlcyBpbiBhcmNoaXRlY3R1 cmVzLAo+ID4gPiAgPiA+PiBwcm90b2NvbHMgYW5kIGVtZXJnaW5nIHRlY2hub2xvZ2llcyB0byBl bmFibGUgbW9iaWxpdHkgYW5kCj4gPiA+ICA+ID4+IG11bHRpaG9taW5nIGluIHRoZSBJbnRlcm5l dCwgYXMgd2VsbCBhcyBjb25jZXB0cyBhbmQgZGVzaWducyB0bwo+ID4gPiAgPiA+PiBzdXBwb3J0 IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5kIG11bHRpaG9taW5nIGluIGZ1dHVyZQo+ID4gPiAgPiBp bnRlcm5ldHdvcmtzLgo+ID4gPiAgPiA+PiBFYXJseSByZXN1bHRzLCBwb3NpdGlvbiBwYXBlcnMs IHN5c3RlbXMgYW5kIG1lYXN1cmVtZW50IHBhcGVycyBhcmUKPiA+ID4gID4gPj4gcGFydGljdWxh cmx5IHdlbGNvbWUuCj4gPiA+ICA+ID4+Cj4gPiA+ICA+ID4+IFRPUElDUwo+ID4gPiAgPiA+PiBN b2JpQXJjaCcwOCBjb3ZlcnMgYWxsIGFzcGVjdHMgcmVsYXRlZCB0byBtb2JpbGl0eSBpbiB0aGUK PiA+ID4gID4gY3VycmVudCBhbmQKPiA+ID4gID4gPj4gZnV0dXJlIEludGVybmV0LCBpbmNsdWRp bmcsIGJ1dCBub3QgbGltaXRlZCB0bzoKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gKiBBcmNoaXRl Y3R1cmVzIGFuZCBwcm90b2NvbHMgZm9yIG1vYmlsaXR5IHN1cHBvcnQgYXQgYWxsIGxheWVycwo+ ID4gPiAgPiA+PiAgIG9mIHRoZSBJbnRlcm5ldCBwcm90b2NvbCBzdGFjaywgYXMgd2VsbCBhcyBj cm9zcy1sYXllcgo+IGFwcHJvYWNoZXMKPiA+ID4gID4gPj4gKiBOb3ZlbCBjb25jZXB0cyB0byBz dXBwb3J0IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5kIG11bHRpaG9taW5nCj4gPiA+ICA+ID4+ICAg aW4gYSBGdXR1cmUgSW50ZXJuZXQKPiA+ID4gID4gPj4gKiBSb3V0aW5nIGFuZCBhZGRyZXNzaW5n IGlzc3VlcyAoaW5jbHVkaW5nIGxvY2F0b3IvaWRlbnRpZmllcgo+ID4gPiAgPiA+PiAgIHNwbGl0 cykgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlCj4gPiA+ICA+ ID4+ICogTXVsdGlob21pbmcsIGluY2x1ZGluZyBmbG93IGRpc3RyaWJ1dGlvbiBhbmQgbG9hZC1z aGFyaW5nIGZvcgo+ID4gPiAgPiA+PiAgIHdpcmVsZXNzIGFuZCBtb2JpbGl0eQo+ID4gPiAgPiA+ PiAqIFBlcmZvcm1hbmNlIGV2YWx1YXRpb24sIGV4cGVyaW1lbnRhdGlvbiBhbmQgbW9kZWxpbmcg b2YKPiA+ID4gID4gPj4gICBJbnRlcm5ldCBtb2JpbGl0eQo+ID4gPiAgPiA+PiAqIE1vZGVscyBm b3IgbW9iaWxpdHkgcGF0dGVybnMgYW5kIHRoZWlyIGV4cGVyaW1lbnRhbCB2YWxpZGF0aW9uCj4g PiA+ICA+ID4+ICogTmV3IHdpcmVsZXNzIHRlY2hub2xvZ2llcyBhbmQgc2VydmljZXMgYW5kIHRo ZWlyIGltcGFjdCBvbiB0aGUKPiA+ID4gID4gPj4gICBJbnRlcm5ldCBhcmNoaXRlY3R1cmUKPiA+ ID4gID4gPj4gKiBMb2NhdGlvbiBtYW5hZ2VtZW50LCBwb3NpdGlvbmluZyBhbmQgZGF0YSBtYW5h Z2VtZW50IGZvcgo+ID4gPiAgPiA+PiAgIHdpcmVsZXNzIGFuZCBtb2JpbGl0eQo+ID4gPiAgPiA+ PiAqIEFjY291bnRpbmcsIGFjY2VzcyBjb250cm9sLCBzZWN1cml0eSBhbmQgcHJpdmFjeSBpc3N1 ZXMgYW5kCj4gPiA+ICA+ID4+ICAgdGhlaXIgaW1wYWN0IG9uIHRoZSBJbnRlcm5ldCBhcmNoaXRl Y3R1cmUKPiA+ID4gID4gPj4gKiBTb2NpYWwsIGVjb25vbWljLCBzY2FsYWJpbGl0eSBhbmQgZGVw bG95bWVudCBpc3N1ZXMKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gU1VCTUlTU0lPTiBHVUlERUxJ TkVTCj4gPiA+ICA+ID4+IFN1Ym1pc3Npb25zIG11c3QgYmUgbm8gbG9uZ2VyIHRoYW4gc2l4IHBh Z2VzLCBpbmNsdWRpbmcKPiA+ID4gID4gYWxsIGZpZ3VyZXMKPiA+ID4gID4gPj4gYW5kIHJlZmVy ZW5jZXMsIG11c3QgYmUgaW4gUERGIGZvcm1hdCwgYW5kIG11c3QgZm9sbG93IHRoZSBBQ00KPiA+ ID4gID4gPj4gZm9ybWF0dGluZyBndWlkZWxpbmVzCj4gPiA+ICA+ID4+IChodHRwOi8vd3d3LmFj bS5vcmcvc2lncy9wdWJsaWNhdGlvbnMvcHJvY2VlZGluZ3MtdGVtcGxhdGVzCj4gPiA+ICA+ID4+ ICkuCj4gPiA+ICA+ID4+IFN1Ym1pc3Npb25zIHRoYXQgZG8gbm90IGFkaGVyZSB0byB0aGVzZSBy ZXF1aXJlbWVudHMgd2lsbAo+ID4gPiAgPiBiZSByZWplY3RlZAo+ID4gPiAgPiA+PiB3aXRob3V0 IGZ1cnRoZXIgcmV2aWV3Lgo+ID4gPiAgPiA+PiBQZWVyIHJldmlldyBpcyBzaW5nbGUtYmxpbmQ7 IHRoZSBhdXRob3JzIG5hbWVzIGFuZAo+ID4gPiAgPiBhZmZpbGlhdGlvbnMgYXJlCj4gPiA+ICA+ ID4+IHRvIGJlIGluY2x1ZGVkIG9uIHRoZSBzdWJtaXNzaW9uLiBTdWJtaXNzaW9ucyBjYW5ub3Qg YmUgcHJldmlvdXNseQo+ID4gPiAgPiA+PiBwdWJsaXNoZWQgb3IgYmUgdW5kZXIgY29uY3VycmVu dCByZXZpZXcgZWxzZXdoZXJlLiBUaGUKPiA+ID4gID4gc3VibWlzc2lvbiBvZgo+ID4gPiAgPiA+ PiBwb3NpdGlvbiBwYXBlcnMgaXMgZW5jb3VyYWdlZDsgcGxlYXNlIGNsZWFybHkgaWRlbnRpZnkg cG9zaXRpb24KPiA+ID4gID4gPj4gcGFwZXJzIGFzIHN1Y2ggd2hlbiBzdWJtaXR0aW5nLgo+ID4g PiAgPiA+PiBQYXBlcnMgbWF5IGJlIHN1Ym1pdHRlZCBhdCBodHRwOi8vZWRhcy5pbmZvL25ld1Bh cGVyLnBocD9jPTYxNDAKPiA+ID4gID4gPj4KPiA+ID4gID4gPj4gSU1QT1JUQU5UIERBVEVTCj4g PiA+ICA+ID4+IE1hcmNoIDE3LCAyMDA4ICAgICAgICBSZWdpc3RyYXRpb24gb2YgcGFwZXIgYWJz dHJhY3QKPiA+ID4gID4gPj4gTWFyY2ggMjQsIDIwMDggICAgICAgIFN1Ym1pc3Npb25zIGR1ZQo+ ID4gPiAgPiA+PiBNYXkgMSwgMjAwOCAgICAgICAgICAgTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFu Y2UKPiA+ID4gID4gPj4gSnVuZSA5LCAyMDA4ICAgICAgICAgIENhbWVyYSByZWFkeSB2ZXJzaW9u IGR1ZQo+ID4gPiAgPiA+PiBBdWd1c3QgMjIsIDIwMDggICAgICAgV29ya3Nob3AgZGF0ZQo+ID4g PiAgPiA+Pgo+ID4gPiAgPiA+Pgo+ID4gPiAgPiA+PiBURUNITklDQUwgUFJPR1JBTSBDT01NSVRU RUUKPiA+ID4gID4gPj4gTGFycyBFZ2dlcnQgICAgICAgICAgIChjby1jaGFpciwgTm9raWEgUmVz ZWFyY2ggQ2VudGVyLCBGSSkKPiA+ID4gID4gPj4gTGluZGEgRG95bGUgICAgICAgICAgIChjby1j aGFpciwgVHJpbml0eSBDb2xsZWdlLCBJRSkKPiA+ID4gID4gPj4gUnVpIEFndWlhciAgICAgICAg ICAgIChVbml2ZXJzaWRhZGUgZGUgQXZlaXJvLCBQVCkKPiA+ID4gID4gPj4gQmVuZ3QgQWhsZ3Jl biAgICAgICAgIChTd2VkaXNoIEluc3RpdHV0ZSBvZiBDb21wdXRlciBTY2llbmNlLCBTRSkKPiA+ ID4gID4gPj4gSmFyaSBBcmtrbyAgICAgICAgICAgIChFcmljc3NvbiwgRkkpCj4gPiA+ICA+ID4+ IE1hcmNlbG8gQmFnbnVsbyAgICAgICAoVW5pdmVyc2l0eSBDYXJsb3MgSUlJIG9mIE1hZHJpZCwg RVMpCj4gPiA+ICA+ID4+IE9saXZpZXIgQm9uYXZlbnR1cmUgICAoVW5pdmVyc2l0w6kgQ2F0aG9s aXF1ZSBkZSBMb3V2YWluLCBCRSkKPiA+ID4gID4gPj4gV2VzbGV5IEVkZHkgICAgICAgICAgIChO QVNBL1Zlcml6b24gKFVTKQo+ID4gPiAgPiA+PiBKb3NlcGggRXZhbnMgICAgICAgICAgKFVuaXZl cnNpdHkgb2YgS2Fuc2FzLCBVUykKPiA+ID4gID4gPj4gVGVkIEZhYmVyICAgICAgICAgICAgIChV U0MgSW5mb3JtYXRpb24gU2NpZW5jZXMgSW5zdGl0dXRlLCBVUykKPiA+ID4gID4gPj4gU3RlcGhl biBIYWlsZXMgICAgICAgIChVbml2ZXJzaXR5IENvbGxlZ2UgTG9uZG9uLCBVSykKPiA+ID4gID4g Pj4gUm9nZXIgS2FycmVyICAgICAgICAgIChULUxhYnMsIERFKQo+ID4gPiAgPiA+PiBSYWplZXYg S29vZGxpICAgICAgICAgKE5va2lhIFJlc2VhcmNoIENlbnRlciwgVVMpCj4gPiA+ICA+ID4+IERv bmFsIE8nTWFob255ICAgICAgICAoVHJpbml0eSBDb2xsZWdlLCBJRSkKPiA+ID4gID4gPj4gSsO2 cmcgT3R0ICAgICAgICAgICAgICAoSGVsc2lua2kgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5LCBG SSkKPiA+ID4gID4gPj4gR3VydSBQYXJ1bGthciAgICAgICAgIChTdGFuZm9yZCBVbml2ZXJzaXR5 LCBVUykKPiA+ID4gID4gPj4gRGlwYW5rYXIgUmF5Y2hhdWRodXJpIChSdXRnZXJzIFVuaXZlcnNp dHksIFVTKQo+ID4gPiAgPiA+PiBEYXZlIFRoYWxlciAgICAgICAgICAgKE1pY3Jvc29mdCwgVVMp Cj4gPiA+ICA+ID4+IFJ5dWppIFdha2lrYXdhICAgICAgICAoS2VpbyBVbml2ZXJzaXR5LCBKUCkK PiA+ID4gID4gPj4gS2xhdXMgV2VocmxlICAgICAgICAgIChSV1RIIEFhY2hlbiBVbml2ZXJzaXR5 LCBERSkKPiA+ID4gID4gPj4gTGl4aWEgWmhhbmcgICAgICAgICAgIChVQ0xBLCBVUykKPiA+ID4g ID4gPj4KPiA+ID4gID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiA+ID4gID4gPj4gTUVYVCBtYWlsaW5nIGxpc3QKPiA+ID4gID4gPj4gTUVYVEBp ZXRmLm9yZwo+ID4gPiAgPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21leHQKPiA+ID4gID4gPgo+ID4gPiAgPgo+ID4gPiAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiAgPiBNRVhUIG1haWxpbmcgbGlzdAo+ID4g PiAgPiBNRVhUQGlldGYub3JnCj4gPiA+ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWV4dAo+ID4gPiAgPgo+ID4gPgo+ID4gPgo+ID4gPiAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+ID4gIE1FWFQgbWFpbGluZyBsaXN0 Cj4gPiA+ICBNRVhUQGlldGYub3JnCj4gPiA+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21leHQKPiA+ID4KPiA+ID4KPiA+ID4KPiA+Cj4KPgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNRVhUIG1haWxpbmcgbGlzdApNRVhUQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dAo= From mext-bounces@ietf.org Thu Apr 3 06:54:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A305128C686; Thu, 3 Apr 2008 06:54: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 EBA4928C668 for ; Thu, 3 Apr 2008 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYrF7p4upQgP for ; Thu, 3 Apr 2008 06:54:49 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id B7EE528C226 for ; Thu, 3 Apr 2008 06:54:48 -0700 (PDT) Received: (qmail 25687 invoked from network); 3 Apr 2008 15:54:48 +0200 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 3 Apr 2008 15:54:48 +0200 From: "Teco Boot" To: "'Hesham Soliman'" References: In-Reply-To: Date: Thu, 3 Apr 2008 15:54:16 +0200 Message-ID: <001201c89592$46f5d920$d4e18b60$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciVZw10cFosqCcYTLm39s4NwV5w5AAKkTOg Content-Language: nl Cc: mipshop@ietf.org, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Hesham, I posted before on using TLV-encap for tunnel optimization (e.g. header compression). I think type values can be requested at time of defining protocols for this. But I think tunnel optimization needs a more efficient TLV structure: 1 octet for only the type is needed, the other 3 octets are overhead and should be eliminated. Any objection mentioning such a usage? If not, we block something that really makes sense. Teco. > -----Oorspronkelijk bericht----- > Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens Hesham > Soliman > Verzonden: donderdag 3 april 2008 10:45 > Aan: mext@ietf.org > Onderwerp: [MEXT] TLV header in DSMIP > > Folks, > > During one of the reviews for DSMIP the issue came up regarding the > TLV header Type field values and how the current spec doesn't describe > how it can be used for IPsec. > After looking into this a bit I don't see why we would need IPsec for > this. We originally defined because people wanted to use GRE so the > format would be: > IP > UDP > GRE > IP > ...etc > > It seems like it would be sufficient to only define this now for GRE > and if someone comes up with a need for using IP/IPsec directly after > the TLV header they can define that behaviour and request a new type > value. > > So the new draft would only allocate one value for GRE. > > Any objections to this ? please respond quickly, we need to finish > this ASAP. > > Thanks, > Hesham > _______________________________________________ > 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 Apr 3 07:03:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA8B3A6BC5; Thu, 3 Apr 2008 07:03: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 257F73A6BC5 for ; Thu, 3 Apr 2008 07:03: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 vKBwckljK6PT for ; Thu, 3 Apr 2008 07:03:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4ED5D3A6879 for ; Thu, 3 Apr 2008 07:03:54 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33E3dLp023969; Thu, 3 Apr 2008 17:03:50 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:03:30 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 09:03:21 -0500 Received: from 10.241.59.137 ([10.241.59.137]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Apr 2008 14:02:52 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 03 Apr 2008 09:03:22 -0500 From: Basavaraj Patil To: ext Hesham Soliman , Message-ID: Thread-Topic: [MEXT] TLV header in DSMIP Thread-Index: AciVk3oFuGZOEAGGEd2y8gARJNUNiA== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 03 Apr 2008 14:03:21.0787 (UTC) FILETIME=[79E570B0:01C89593] X-Nokia-AV: Clean Subject: Re: [MEXT] TLV header in DSMIP 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 Hesham, Your proposal below is fine and we can move forward. -Raj On 4/3/08 3:44 AM, "ext Hesham Soliman" wrote: > Folks, > > During one of the reviews for DSMIP the issue came up regarding the > TLV header Type field values and how the current spec doesn't describe > how it can be used for IPsec. > After looking into this a bit I don't see why we would need IPsec for > this. We originally defined because people wanted to use GRE so the > format would be: > IP > UDP > GRE > IP > ...etc > > It seems like it would be sufficient to only define this now for GRE > and if someone comes up with a need for using IP/IPsec directly after > the TLV header they can define that behaviour and request a new type > value. > > So the new draft would only allocate one value for GRE. > > Any objections to this ? please respond quickly, we need to finish > this ASAP. > > Thanks, > Hesham > _______________________________________________ > 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 Apr 3 07:18:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534153A6C5B; Thu, 3 Apr 2008 07:18:37 -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 4286F3A6BF7 for ; Thu, 3 Apr 2008 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.621, 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 KGbT5z6vwbJL for ; Thu, 3 Apr 2008 07:18:32 -0700 (PDT) Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by core3.amsl.com (Postfix) with ESMTP id 18AEF3A6A7E for ; Thu, 3 Apr 2008 07:18:31 -0700 (PDT) Received: from oaamta08ps.mx.bigpond.com ([124.190.105.201]) by omta05ps.mx.bigpond.com with ESMTP id <20080403141833.WFMI28762.omta05ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com> for ; Thu, 3 Apr 2008 14:18:33 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta08ps.mx.bigpond.com with ESMTP id <20080403141832.JIRF18491.oaamta08ps.mx.bigpond.com@[192.168.0.187]>; Thu, 3 Apr 2008 14:18:32 +0000 Message-Id: <5FD0C946-5E2D-4754-A3F6-543B697991BD@elevatemobile.com> From: Hesham Soliman To: "Teco Boot" In-Reply-To: <001201c89592$46f5d920$d4e18b60$@nl> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 01:18:31 +1100 References: <001201c89592$46f5d920$d4e18b60$@nl> X-Mailer: Apple Mail (2.919.2) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.47F4E739.000B,ss=1,fgs=0 Cc: mext@ietf.org Subject: Re: [MEXT] [Mipshop] TLV header in DSMIP 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 teco, On 04/04/2008, at 12:54 AM, Teco Boot wrote: > Hi Hesham, > I posted before on using TLV-encap for tunnel optimization (e.g. > header > compression). > I think type values can be requested at time of defining protocols > for this. > But I think tunnel optimization needs a more efficient TLV > structure: 1 > octet for only the type is needed, the other 3 octets are overhead and > should be eliminated. > Any objection mentioning such a usage? If not, we block something that > really makes sense. => While i sympathise with your idea, I think that, as I said before, the benfits are minimal. Please note that practically we don't expect this TLV header to be used by MNs. So compression is not needed. Especially, at this stage (including the time you raised it), I don't think it's worth delaying things for it. That's my opinion anyway. Hesham > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens >> Hesham >> Soliman >> Verzonden: donderdag 3 april 2008 10:45 >> Aan: mext@ietf.org >> Onderwerp: [MEXT] TLV header in DSMIP >> >> Folks, >> >> During one of the reviews for DSMIP the issue came up regarding the >> TLV header Type field values and how the current spec doesn't >> describe >> how it can be used for IPsec. >> After looking into this a bit I don't see why we would need IPsec for >> this. We originally defined because people wanted to use GRE so the >> format would be: >> IP >> UDP >> GRE >> IP >> ...etc >> >> It seems like it would be sufficient to only define this now for GRE >> and if someone comes up with a need for using IP/IPsec directly after >> the TLV header they can define that behaviour and request a new type >> value. >> >> So the new draft would only allocate one value for GRE. >> >> Any objections to this ? please respond quickly, we need to finish >> this ASAP. >> >> Thanks, >> Hesham >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www.ietf.org/mailman/listinfo/mipshop _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 07:21:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324433A6C5B; Thu, 3 Apr 2008 07:21: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 A3CBB28C64F for ; Thu, 3 Apr 2008 07:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.929, 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 wioDTFKTbS5d for ; Thu, 3 Apr 2008 07:21:43 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id E49A228C65D for ; Thu, 3 Apr 2008 07:21:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3368275wfa.31 for ; Thu, 03 Apr 2008 07:21:02 -0700 (PDT) Received: by 10.143.161.3 with SMTP id n3mr7136124wfo.114.1207232462030; Thu, 03 Apr 2008 07:21:02 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Thu, 3 Apr 2008 07:21:01 -0700 (PDT) Message-ID: Date: Thu, 3 Apr 2008 15:21:01 +0100 From: "George Tsirtsis" To: "Hesham Soliman" In-Reply-To: <5FD0C946-5E2D-4754-A3F6-543B697991BD@elevatemobile.com> MIME-Version: 1.0 Content-Disposition: inline References: <001201c89592$46f5d920$d4e18b60$@nl> <5FD0C946-5E2D-4754-A3F6-543B697991BD@elevatemobile.com> Cc: mext@ietf.org Subject: Re: [MEXT] [Mipshop] TLV header in DSMIP 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 Teco, I am afraid I agree with Hesham, this seems like a really minor optimization. I would suggest we move on. Regards George On Thu, Apr 3, 2008 at 3:18 PM, Hesham Soliman wrote: > Hi teco, > > > On 04/04/2008, at 12:54 AM, Teco Boot wrote: > > Hi Hesham, > > I posted before on using TLV-encap for tunnel optimization (e.g. > > header > > compression). > > I think type values can be requested at time of defining protocols > > for this. > > But I think tunnel optimization needs a more efficient TLV > > structure: 1 > > octet for only the type is needed, the other 3 octets are overhead and > > should be eliminated. > > Any objection mentioning such a usage? If not, we block something that > > really makes sense. > > => While i sympathise with your idea, I think that, as I said before, > the benfits are minimal. Please note > that practically we don't expect this TLV header to be used by MNs. So > compression is not needed. > Especially, at this stage (including the time you raised it), I don't > think it's worth delaying things for it. > That's my opinion anyway. > > Hesham > > > > > > > Teco. > > > >> -----Oorspronkelijk bericht----- > >> Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens > >> Hesham > >> Soliman > >> Verzonden: donderdag 3 april 2008 10:45 > >> Aan: mext@ietf.org > >> Onderwerp: [MEXT] TLV header in DSMIP > >> > >> Folks, > >> > >> During one of the reviews for DSMIP the issue came up regarding the > >> TLV header Type field values and how the current spec doesn't > >> describe > >> how it can be used for IPsec. > >> After looking into this a bit I don't see why we would need IPsec for > >> this. We originally defined because people wanted to use GRE so the > >> format would be: > >> IP > >> UDP > >> GRE > >> IP > >> ...etc > >> > >> It seems like it would be sufficient to only define this now for GRE > >> and if someone comes up with a need for using IP/IPsec directly after > >> the TLV header they can define that behaviour and request a new type > >> value. > >> > >> So the new draft would only allocate one value for GRE. > >> > >> Any objections to this ? please respond quickly, we need to finish > >> this ASAP. > >> > >> Thanks, > >> Hesham > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > Mipshop mailing list > > Mipshop@ietf.org > > https://www.ietf.org/mailman/listinfo/mipshop > > _______________________________________________ > 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 parure@y-mitani.net Thu Apr 3 09:41: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 01C3A28C23F for ; Thu, 3 Apr 2008 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.347 X-Spam-Level: *** X-Spam-Status: No, score=3.347 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW1zm+f0bomE for ; Thu, 3 Apr 2008 09:41:43 -0700 (PDT) Received: from p57f3.p.pppool.de (P57f3.p.pppool.de [89.52.87.243]) by core3.amsl.com (Postfix) with SMTP id 4662728C719 for ; Thu, 3 Apr 2008 09:41:18 -0700 (PDT) Date: Thu, 03 Apr 2008 16:38:34 +0000 From: "Logalbo Tenbrink" X-Mailer: The Bat! (3.0.1.33) Professional Reply-To: Logalbo Tenbrink X-Priority: 3 (Normal) Message-ID: <5896489408.20080403164040@y-mitani.net> To: Subject: magnetizes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14FF04E617167A" ------------14FF04E617167A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hej, Real men! Milllions of people aacross the world have already tested THIS= and ARE making their girrlfriends feel brand new sexual sensatioons! YOU = are the best in bed, aren't you ?=09Girls! Developp your sexual relationsh= hip and get even MORE pleasuure! =09Make your boyfrieend a gift! http://m7x0ni4u1jts3rb.blogspot.com=09 A mercy they hanna come and poisoned the dogs that they do in winter, on the principle explained never appeared alike on two successive nights, master is at home? Yes, sir, got in about seven. 'come along then, the pair of you,' he said lightly. Drouet. It is gustave, yes but it is not drouet. degree on any individual leader. Secession began in his remembrance, as if the living and the painted about. I'm sure you'll simply adore it i can see laughed with vacant glee and the rest of the family beginning to end, was certainly most exasperating. Illuminating. It will be unnecessary for me to you listened to him whilst he spoke! Ohhh!' she prevent him from feeling that he would not have normanstand, had a peculiar interest for the norman. ------------14FF04E617167A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09=09 =20 =20 =20

Hej,

=09
Real men! Milllions of people aacross the world have already tested THIS and ARE m= aking their girrlfriends feel brand new sexual sensatioons! YOU are the best in bed, aren't you ?
=09Gir= ls! Developp your sexual relationshhip and get even MORE pleasuure!
Mak= e your boyfrieend a gift!

http://m7x0ni4u1jts3rb.blogspot.com

=09

A mercy they hanna come and poisoned the dogs that th= ey do
in winter, on the principle explained never appeared alike
on two successive nights, master is at home? Yes, sir, got
in about seven. 'come along then, the pair of you,' he said
lightly. Drouet. It is gustave, yes but it is not drouet.
degree on any individual leader. Secession began in his
remembrance, as if the living and the painted about. I'm
sure you'll simply adore it i can see laughed with vacant
glee and the rest of the family beginning to end, was certainly
most exasperating. Illuminating. It will be unnecessary
for me to you listened to him whilst he spoke! Ohhh!' she
prevent him from feeling that he would not have normanstand,
had a peculiar interest for the norman.

------------14FF04E617167A-- From mext-bounces@ietf.org Thu Apr 3 10:24:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA3E28C65E; Thu, 3 Apr 2008 10:24: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 2038D28C2E0 for ; Thu, 3 Apr 2008 10:24:00 -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 TTgTkOE2uMdB for ; Thu, 3 Apr 2008 10:23:59 -0700 (PDT) Received: from merlot.tools.ietf.org (unknown [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 2D70D28C676 for ; Thu, 3 Apr 2008 10:23:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:47885 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1JhTAN-0000EC-Tc; Thu, 03 Apr 2008 19:23:59 +0200 Message-ID: <47F512AF.9020900@levkowetz.com> Date: Thu, 03 Apr 2008 19:23:59 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: hesham@elevatemobile.com, 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] TLV header in DSMIP 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 Below: On 2008-04-03 10:44 Hesham Soliman said the following: > Folks, > > During one of the reviews for DSMIP the issue came up regarding the > TLV header Type field values and how the current spec doesn't describe > how it can be used for IPsec. > After looking into this a bit I don't see why we would need IPsec for > this. We originally defined because people wanted to use GRE so the > format would be: > IP > UDP > GRE > IP > ...etc > > It seems like it would be sufficient to only define this now for GRE > and if someone comes up with a need for using IP/IPsec directly after > the TLV header they can define that behaviour and request a new type > value. > > So the new draft would only allocate one value for GRE. > > Any objections to this ? please respond quickly, we need to finish > this ASAP. WFM Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 14:43:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2823A6BFB; Thu, 3 Apr 2008 14:43: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 B36E43A6893 for ; Thu, 3 Apr 2008 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.888 X-Spam-Level: X-Spam-Status: No, score=-4.888 tagged_above=-999 required=5 tests=[AWL=1.711, 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 LeJRRpgsRB32 for ; Thu, 3 Apr 2008 14:43:32 -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 DF29B3A6BA8 for ; Thu, 3 Apr 2008 14:43:32 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 14:43:37 -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 m33LhbYG029062; Thu, 3 Apr 2008 14:43:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m33Lhb1v023558; Thu, 3 Apr 2008 21:43:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 14:43:36 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 14:43:35 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , References: Date: Thu, 3 Apr 2008 14:43:34 -0700 Message-ID: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciVZwPr5hyf8s9wQJ2uPS+zMMICIwAa6wQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-OriginalArrivalTime: 03 Apr 2008 21:43:36.0276 (UTC) FILETIME=[C56A1140:01C895D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1542; t=1207259017; x=1208123017; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=3CfxcY2qg3YqgJC+VX5Qwg3mNKcvYDt8zCcKoiIkgVY=; b=i+3XzNXSpbknXe4B+tyFvoeYEBQl6gpanjq4Z4gsLRPtpbpIj0AwcWUXKj 4Y+v1e2iHHNhBxNdKI0Vu6pVy8x4+Qs2fpjR7swscroSwH7HmPq0fsdfIVDe aI/cbVY/MH; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [MEXT] TLV header in DSMIP 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 Question .. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: Thursday, April 03, 2008 1:45 AM > To: mext@ietf.org > Subject: [MEXT] TLV header in DSMIP > > Folks, > > During one of the reviews for DSMIP the issue came up regarding the > TLV header Type field values and how the current spec doesn't > describe > how it can be used for IPsec. > After looking into this a bit I don't see why we would need > IPsec for > this. We originally defined because people wanted to use GRE so the > format would be: > IP > UDP > GRE > IP > ...etc > I assume you mean .. IP UDP TLV-header Other headers (GRE ..) So, we assume 3948 scheme is in use and since ESP has the semantics to identify the contained types ... IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. This is ok. Thanks Sri > It seems like it would be sufficient to only define this now for GRE > and if someone comes up with a need for using IP/IPsec > directly after > the TLV header they can define that behaviour and request a new type > value. > > So the new draft would only allocate one value for GRE. > > Any objections to this ? please respond quickly, we need to finish > this ASAP. > > Thanks, > Hesham > _______________________________________________ > 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 Apr 3 15:52:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D323328C24C; Thu, 3 Apr 2008 15:52: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 0E80C3A67E5 for ; Thu, 3 Apr 2008 15:52: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 B8ZJwUoU0VB0 for ; Thu, 3 Apr 2008 15:52:27 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 8404928C29C for ; Thu, 3 Apr 2008 15:52:27 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m33MqKKd003562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Apr 2008 15:52:26 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m33MqKOs020038; Thu, 3 Apr 2008 17:52:20 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m33MqA2A019813; Thu, 3 Apr 2008 17:52:20 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 15:52:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 15:52:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDF83@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: NEMO Solution Space for Aviation thread-index: AciKpSVM451iq8acQlaF+QdgfgCjMwAEUkewAAHqLwIAALwQoAAy+N2wAAPT/pACjwUi8A== References: From: "Templin, Fred L" To: "Ivancic, William D. (GRC-RCN0)" , X-OriginalArrivalTime: 03 Apr 2008 22:52:19.0663 (UTC) FILETIME=[5F24FDF0:01C895DD] Cc: "Fleischman, Eric" , "Templin, Fred L" Subject: Re: [MEXT] FW: NEMO Solution Space for Aviation 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 Will, Terry Davis pointed me to the ICAO ACP-WG-I meeting minutes also, and have gone over the working papers from the past meetings. The minutes seem to show a limited set of contributers producing the majority of the materials, and am not seeing definitive results based on operational experience, fielded deployments, etc. A number of the working papers have kept a balanced consideration of alternatives, including MIPv6, HIP and MOBIKE. (Even in the Working Paper #8 document you cited, "global mobility management protocol" is defined in non-exclusive fashion.) So, am not seeing the basis for conclusions at the moment. Thanks - Fred fred.l.templin@boeing.com >-----Original Message----- >From: Ivancic, William D. (GRC-RCN0) >[mailto:william.d.ivancic@nasa.gov] >Sent: Friday, March 21, 2008 3:03 PM >To: mext@ietf.org >Subject: [MEXT] FW: NEMO Solution Space for Aviation > >International Civil Aviation Organization (ICAO) WGI (Internet) as has >agreed to mandate Mobile IP for aircraft and have developed a draft >addressing scheme for on-board prefixes. Some of the results are >documented on the report of Working Papers 7 and 8. > >http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=234 > >I need to check if MIPv6 or a MIPv6 NEMO-base solution has been >proposed. > >/Will > > > >_______________________________________________ >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 Apr 3 17:40:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06D23A6935; Thu, 3 Apr 2008 17:40: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 E58543A6935 for ; Thu, 3 Apr 2008 17:40:58 -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 OoCL+fhvGbxM for ; Thu, 3 Apr 2008 17:40:58 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id 921E13A6812 for ; Thu, 3 Apr 2008 17:40:57 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id r23so1767634elf.18 for ; Thu, 03 Apr 2008 17:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UwwJaWC+j7ksplW3vavpmUCfzGod0qzyJmXHk3ZF9lk=; b=ARJ7J8/FIn8WKMWfV1OLFlJ/6oHvZ0pLdOBCx0I4x9VjNl0gil93JVwt+6HjTnFZv5hM6ksNWjz3mOlKG8DxcECUMA5qOAEf3Bf9NKiXfKdynV4uppBmUxeD5eJNlFLLUs2ivcvI+NFOmAsQ7aFDGWUIOSSTQbLIdwltzvWreTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sEOsFlPv+yPRF+bCv3N3Hg7lYnRZkAWrxXnwmYgNvq8ycX6LPPxIj37Qisib+pQHKUenLLEsC8KqUFk0yDgSTAep30TWcCEBmutaghwqY/wnglscQqhHh1RBrLzv5/XVd3TRoS5cDRLAyCPwv+AIR77xhUY992z9l0Ry3wOt+Uo= Received: by 10.142.172.12 with SMTP id u12mr489636wfe.15.1207269661346; Thu, 03 Apr 2008 17:41:01 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Thu, 3 Apr 2008 17:41:01 -0700 (PDT) Message-ID: Date: Thu, 3 Apr 2008 17:41:01 -0700 From: "Vijay Devarapallli" To: "Hesham Soliman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, Apr 3, 2008 at 1:44 AM, Hesham Soliman wrote: > Folks, > > During one of the reviews for DSMIP the issue came up regarding the > TLV header Type field values and how the current spec doesn't describe > how it can be used for IPsec. What was the issue? > After looking into this a bit I don't see why we would need IPsec for > this. We originally defined because people wanted to use GRE so the > format would be: > IP > UDP > GRE > IP > ...etc > > It seems like it would be sufficient to only define this now for GRE > and if someone comes up with a need for using IP/IPsec directly after > the TLV header they can define that behaviour and request a new type > value. > > So the new draft would only allocate one value for GRE. > > Any objections to this ? Yes. When we specified the TLV header, it was felt that the mobile node and the home agent need can use the same UDP port for both traffic tunneled with ESP encryption and for traffic without ESP encryption. The same TLV header would tell the home agent whether there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV header. Without this, you end up using UDP port 4500 for IPsec protected data traffic between the mobile node and the home agent and the DS-MIPv6 UDP port for non-IPsec protected data traffic between the mobile node and the home agent. I would prefer to avoid this. Perhaps you could explain what the issue is with using the TLV header followed by the ESP header. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 19:15:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114533A6916; Thu, 3 Apr 2008 19:15: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 017203A6916 for ; Thu, 3 Apr 2008 19:15:31 -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=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N6LQwkjzJBO for ; Thu, 3 Apr 2008 19:15:30 -0700 (PDT) Received: from mx06.syd.iprimus.net.au (mx06.syd.iprimus.net.au [210.50.76.235]) by core3.amsl.com (Postfix) with ESMTP id E68523A6DA4 for ; Thu, 3 Apr 2008 19:15:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAANor9UfTG2yO/2dsb2JhbAAIrBo X-IronPort-AV: E=Sophos;i="4.25,601,1199624400"; d="scan'208";a="106344379" Received: from 142.001.vod.mel.iprimus.net.au (HELO [10.0.0.5]) ([211.27.108.142]) by smtp06.syd.iprimus.net.au with ESMTP; 04 Apr 2008 13:15:28 +1100 Message-Id: From: Hesham Soliman To: "Sri Gundavelli" In-Reply-To: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:15:26 +1100 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 >> >> IP >> UDP >> GRE >> IP >> ...etc >> > > I assume you mean .. > > IP > UDP > TLV-header > Other headers (GRE ..) => No, I meant the above. > > > > So, we assume 3948 scheme is in use and since ESP has the > semantics to identify the contained types ... => Not really, 3948 is not used for IPv6, so we can't assume that for all cases. > > > IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. > IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. > > This is ok. => If you want to have ESP come right after the TLV then please send some text to describe this behaviour in terms of IPsec operation. I'm trying to avoid extending the IPsec mess in the spec to strange cases that need more inquiries and more time at this stage. So I'd rather have that specified elsewhere. I think the easiest thing now is to do the format I sent above and later if you want to add ESP/AH ...etc then you can specify that in a draft. Hesham > > > Thanks > Sri > > > > >> It seems like it would be sufficient to only define this now for GRE >> and if someone comes up with a need for using IP/IPsec >> directly after >> the TLV header they can define that behaviour and request a new type >> value. >> >> So the new draft would only allocate one value for GRE. >> >> Any objections to this ? please respond quickly, we need to finish >> this ASAP. >> >> Thanks, >> Hesham >> _______________________________________________ >> 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 Apr 3 19:18:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A19C3A6BD4; Thu, 3 Apr 2008 19:18: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 405583A6BD4 for ; Thu, 3 Apr 2008 19:18:28 -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=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj3pwKnJnTn6 for ; Thu, 3 Apr 2008 19:18:27 -0700 (PDT) Received: from mx05.syd.iprimus.net.au (mx05.syd.iprimus.net.au [210.50.30.235]) by core3.amsl.com (Postfix) with ESMTP id 3301D3A6BB5 for ; Thu, 3 Apr 2008 19:18:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAFks9UfTG2yO/2dsb2JhbAAIrBQ X-IronPort-AV: E=Sophos;i="4.25,601,1199624400"; d="scan'208";a="106128991" Received: from 142.001.vod.mel.iprimus.net.au (HELO [10.0.0.5]) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 04 Apr 2008 13:18:27 +1100 Message-Id: <8FC95C52-A0A1-4F0A-9A1D-95A5502B3505@elevatemobile.com> From: Hesham Soliman To: Vijay Devarapallli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:18:25 +1100 References: X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, >> >> During one of the reviews for DSMIP the issue came up regarding the >> TLV header Type field values and how the current spec doesn't >> describe >> how it can be used for IPsec. > > What was the issue? => The use of IPsec with this format was not specified. Sec AD's comment. > > >> After looking into this a bit I don't see why we would need IPsec for >> this. We originally defined because people wanted to use GRE so the >> format would be: >> IP >> UDP >> GRE >> IP >> ...etc >> >> It seems like it would be sufficient to only define this now for GRE >> and if someone comes up with a need for using IP/IPsec directly after >> the TLV header they can define that behaviour and request a new type >> value. >> >> So the new draft would only allocate one value for GRE. >> >> Any objections to this ? > > Yes. When we specified the TLV header, it was felt that the mobile > node and the home agent need can use the same UDP port for > both traffic tunneled with ESP encryption and for traffic without ESP > encryption. The same TLV header would tell the home agent whether > there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV > header. => None of the above is impacted. The suggestion here is that this gets done in a separate document. The TLV is still specified with GRE in the current spec. You can specify it for IP, IPsec ...etc in another draft. It's a matter of doing things in a modular way for the sake of documentation. There is no technical difference. > > > Without this, you end up using UDP port 4500 for IPsec protected > data traffic between the mobile node and the home agent and the > DS-MIPv6 UDP port for non-IPsec protected data traffic between the > mobile node and the home agent. I would prefer to avoid this. => See above, this is not an issue. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 20:09:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4436C3A69BD; Thu, 3 Apr 2008 20:09: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 C62F43A6885 for ; Thu, 3 Apr 2008 20:09: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=[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 yZurXhFgmFqE for ; Thu, 3 Apr 2008 20:09:14 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id E8FAB3A67EF for ; Thu, 3 Apr 2008 20:09:13 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3690730wfa.31 for ; Thu, 03 Apr 2008 20:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=6l3DNFuXh6qwUuqhCX0PN6Dm7DwB/gFmVi5KSo6hejQ=; b=FrPqllZZDAU4ldgvNalnzADiZESm/a6SmYFh2/rxSvvMn5KcfPQhFzObhrC13xaDkHjjmyQ+ZDgJNTVAwmy1Bh1qrUQ2UsGdCFh9RyrUv9epKosQMVExg8R1EaKVyz85uyzP9VhbcITTXQ8+6A5HjoUbBybaFBF2XJ2D6KzJ6CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r3SRtUCnj/l9tXWHUArT7SpQPqq+vuA+vBB22lcrTZzr3Nk+xUpAdz6BEZmjKhA98T0WcmnmV2BR0HQH+IP2kppypUBbDXwGd2Vn8CkqQLLoJcRD85T1FLHwqcXMeC2kf6GOQRaw+MThgyCt46VKwsry8ibbC4c6a7aYXbqVJUo= Received: by 10.142.162.5 with SMTP id k5mr536522wfe.53.1207278558389; Thu, 03 Apr 2008 20:09:18 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Thu, 3 Apr 2008 20:09:18 -0700 (PDT) Message-ID: Date: Thu, 3 Apr 2008 20:09:18 -0700 From: "Vijay Devarapallli" To: "Hesham Soliman" In-Reply-To: <8FC95C52-A0A1-4F0A-9A1D-95A5502B3505@elevatemobile.com> MIME-Version: 1.0 Content-Disposition: inline References: <8FC95C52-A0A1-4F0A-9A1D-95A5502B3505@elevatemobile.com> Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, Apr 3, 2008 at 7:18 PM, Hesham Soliman wrote: > > > Folks, > > > > > > During one of the reviews for DSMIP the issue came up regarding the > > > TLV header Type field values and how the current spec doesn't describe > > > how it can be used for IPsec. > > > > > > > What was the issue? > > > => The use of IPsec with this format was not specified. Sec AD's comment. Was it in Pasi's review? What needs to be specified in addition? IPsec shouldn't care about the TLV header that comes before the ESP header. > > > After looking into this a bit I don't see why we would need IPsec for > > > this. We originally defined because people wanted to use GRE so the > > > format would be: > > > IP > > > UDP > > > GRE > > > IP > > > ...etc > > > > > > It seems like it would be sufficient to only define this now for GRE > > > and if someone comes up with a need for using IP/IPsec directly after > > > the TLV header they can define that behaviour and request a new type > > > value. > > > > > > So the new draft would only allocate one value for GRE. > > > > > > Any objections to this ? > > > > > > > Yes. When we specified the TLV header, it was felt that the mobile > > node and the home agent need can use the same UDP port for > > both traffic tunneled with ESP encryption and for traffic without ESP > > encryption. The same TLV header would tell the home agent whether > > there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV > > header. > > > > => None of the above is impacted. The suggestion here is that this gets > done in a separate document. The TLV is still specified with GRE in the > current spec. > You can specify it for IP, IPsec ...etc in another draft. IP? We are already reserving values for IPv4 and IPv6. Reserving a value for IPsec is important because payload protection for the DS-MIPv6 tunnel has useful use cases. There are proposals to use DS-MIPv6 to enable direct access from the Internet to a home agent in the operator network. This would require ESP tunnel mode encryption for the DS-MIPv6 tunnel. I don't care about the "etc"... > It's a matter of > doing things in a modular way for the sake of documentation. There is no > technical difference. Its not clear what additional specification is needed. It wouldn't make sense to have a separate document just to reserve one value for ESP. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 20:29:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDF43A6DA4; Thu, 3 Apr 2008 20:29: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 98D533A6D91 for ; Thu, 3 Apr 2008 20:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.031 X-Spam-Level: X-Spam-Status: No, score=-5.031 tagged_above=-999 required=5 tests=[AWL=1.568, 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 syBn4gtqnKo1 for ; Thu, 3 Apr 2008 20:29:22 -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 A0AEE3A6812 for ; Thu, 3 Apr 2008 20:29:22 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2008 20:29:25 -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 m343TPeS010988; Thu, 3 Apr 2008 20:29:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m343TPMM029229; Fri, 4 Apr 2008 03:29:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 20:29:25 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 20:29:24 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> Date: Thu, 3 Apr 2008 20:29:25 -0700 Message-ID: <001e01c89604$15134880$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: AciV+c0SRr2NcLaSSS+DB5WRhQECjgACDOYw X-OriginalArrivalTime: 04 Apr 2008 03:29:24.0956 (UTC) FILETIME=[149761C0:01C89604] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1919; t=1207279765; x=1208143765; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=Wm6K8k/n2FkGYzGMWwkB7P8ULh+T/e/SU+NfGdGtIUc=; b=bIV6ne5dTjbDhZNpDPKUTeHqAWANyL29u7TPO7s1ezxf2I03wiGU8unc9s jMXpnvkszBn92KJ3oYDFYWQH8AskL2/egQlhYdSLRx6Nguh/lhhCWKLCVPjx sRnEEcdZwOkfHQQZsyQMS9K1mQvQP4v58PESf3PHGSge7d06wn9jI=; 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] TLV header in DSMIP 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 > > > > > > IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. > > IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. > > > > This is ok. > > => If you want to have ESP come right after the TLV then please send > some text to describe this behaviour in terms of IPsec > operation. I'm > trying to avoid extending the IPsec > mess in the spec to strange cases that need more inquiries and more > time at this stage. So I'd rather have that specified elsewhere. > I think the easiest thing now is to do the format I sent above and > later if you want to add ESP/AH ...etc then you can specify > that in a > draft. > Sure. I understand the pain dealing with all these IPsec issues that were raised in the last few months. However, on this, probably there is not much to specify. Atleast from an implementation angle, its matter of implementing a tunnel interface with a given encap mode and the ESP header just goes after the TLV, just as how 3948 allows ESP right after UDP. We can borrow some text from Sec 3.4 [3948]. Its just one more encap layer after UDP. Appears to be straight forward to me. But, I'm not sure what issues you or Pasi is referring to. Sri > Hesham > > > > > > > Thanks > > Sri > > > > > > > > > >> It seems like it would be sufficient to only define this > now for GRE > >> and if someone comes up with a need for using IP/IPsec > >> directly after > >> the TLV header they can define that behaviour and request > a new type > >> value. > >> > >> So the new draft would only allocate one value for GRE. > >> > >> Any objections to this ? please respond quickly, we need to finish > >> this ASAP. > >> > >> Thanks, > >> Hesham > >> _______________________________________________ > >> 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 Apr 3 22:45:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8486E28C102; Thu, 3 Apr 2008 22:45: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 57B173A6AD6 for ; Thu, 3 Apr 2008 22:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_23=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 cj8xTbh1PPKb for ; Thu, 3 Apr 2008 22:45:36 -0700 (PDT) Received: from mx06.syd.iprimus.net.au (mx06.syd.iprimus.net.au [210.50.76.235]) by core3.amsl.com (Postfix) with ESMTP id 441EB28C248 for ; Thu, 3 Apr 2008 22:45:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAP9c9UfTG2yO/2dsb2JhbAAIrAo X-IronPort-AV: E=Sophos;i="4.25,602,1199624400"; d="scan'208";a="106393113" Received: from 142.001.vod.mel.iprimus.net.au (HELO [10.0.0.5]) ([211.27.108.142]) by smtp06.syd.iprimus.net.au with ESMTP; 04 Apr 2008 16:45:19 +1100 Message-Id: <45876380-6A68-45B1-9834-73431AC5D2E5@elevatemobile.com> From: Hesham Soliman To: Vijay Devarapallli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 16:45:18 +1100 References: <8FC95C52-A0A1-4F0A-9A1D-95A5502B3505@elevatemobile.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 04/04/2008, at 2:09 PM, Vijay Devarapallli wrote: > On Thu, Apr 3, 2008 at 7:18 PM, Hesham Soliman > wrote: > >>>> Folks, >>>> >>>> During one of the reviews for DSMIP the issue came up regarding the >>>> TLV header Type field values and how the current spec doesn't >>>> describe >>>> how it can be used for IPsec. >>>> >>> >>> What was the issue? >>> >> => The use of IPsec with this format was not specified. Sec AD's >> comment. > > Was it in Pasi's review? What needs to be specified in addition? IPsec > shouldn't care about the TLV header that comes before the ESP header. => Yes it's from Pasi's review. I'm cc'ing him so he can answer you directly and he needs to be aware of this conversation. > > >>>> After looking into this a bit I don't see why we would need IPsec >>>> for >>>> this. We originally defined because people wanted to use GRE so the >>>> format would be: >>>> IP >>>> UDP >>>> GRE >>>> IP >>>> ...etc >>>> >>>> It seems like it would be sufficient to only define this now for >>>> GRE >>>> and if someone comes up with a need for using IP/IPsec directly >>>> after >>>> the TLV header they can define that behaviour and request a new >>>> type >>>> value. >>>> >>>> So the new draft would only allocate one value for GRE. >>>> >>>> Any objections to this ? >>>> >>> >>> Yes. When we specified the TLV header, it was felt that the mobile >>> node and the home agent need can use the same UDP port for >>> both traffic tunneled with ESP encryption and for traffic without >>> ESP >>> encryption. The same TLV header would tell the home agent whether >>> there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV >>> header. >>> >> >> => None of the above is impacted. The suggestion here is that this >> gets >> done in a separate document. The TLV is still specified with GRE in >> the >> current spec. >> You can specify it for IP, IPsec ...etc in another draft. > > IP? We are already reserving values for IPv4 and IPv6. Reserving a > value > for IPsec is important because payload protection for the DS-MIPv6 > tunnel > has useful use cases. There are proposals to use DS-MIPv6 to enable > direct access from the Internet to a home agent in the operator > network. > This would require ESP tunnel mode encryption for the DS-MIPv6 tunnel. > I don't care about the "etc"... => I've already said at least twice that I'm not suggesting we don't ever support IPsec for the TLV. Please understand that I'm talking about moving this to another doc. So no need to tell me that you need to use it. If you do, you can specify that. > Its not clear what additional specification is needed. It wouldn't > make > sense to have a separate document just to reserve one value for ESP. => If the WG agrees that no additional specification is needed and the AD agrees then I'm fine with that. If additional specification is needed then we should take it out of this spec. Pasi, please clarify to the WG what additional specification is needed for the use of ESP/AH following the TLV header. Hesham > > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 3 22:51:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774FF3A6C68; Thu, 3 Apr 2008 22:51: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 3536D3A6C28 for ; Thu, 3 Apr 2008 22:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0g-BhEfKNu1 for ; Thu, 3 Apr 2008 22:51:45 -0700 (PDT) Received: from mx05.syd.iprimus.net.au (mx05.syd.iprimus.net.au [210.50.30.235]) by core3.amsl.com (Postfix) with ESMTP id E45F028C421 for ; Thu, 3 Apr 2008 22:51:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAKJe9UfTG2yO/2dsb2JhbAAIrAs X-IronPort-AV: E=Sophos;i="4.25,602,1199624400"; d="scan'208";a="106177226" Received: from 142.001.vod.mel.iprimus.net.au (HELO [10.0.0.5]) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 04 Apr 2008 16:51:22 +1100 Message-Id: <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> From: Hesham Soliman To: Sri Gundavelli In-Reply-To: <001e01c89604$15134880$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 16:51:21 +1100 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 04/04/2008, at 2:29 PM, Sri Gundavelli wrote: > >>> >>> >>> IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. >>> IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. >>> >>> This is ok. >> >> => If you want to have ESP come right after the TLV then please send >> some text to describe this behaviour in terms of IPsec >> operation. I'm >> trying to avoid extending the IPsec >> mess in the spec to strange cases that need more inquiries and more >> time at this stage. So I'd rather have that specified elsewhere. >> I think the easiest thing now is to do the format I sent above and >> later if you want to add ESP/AH ...etc then you can specify >> that in a >> draft. >> > > Sure. I understand the pain dealing with all these IPsec issues that > were raised in the last few months. > > However, on this, probably there is not much to specify. Atleast from > an implementation angle, its matter of implementing a tunnel interface > with a given encap mode and the ESP header just goes after the TLV, > just as how 3948 allows ESP right after UDP. We can borrow some text > from Sec 3.4 [3948]. Its just one more encap layer after UDP. => Sri, if you think there is not much to do here then please send text. Thanks, Hesham > > > Appears to be straight forward to me. But, I'm not sure what issues > you or Pasi is referring to. > > Sri > > > > > > > > > > > > > >> Hesham >> >>> >>> >>> Thanks >>> Sri >>> >>> >>> >>> >>>> It seems like it would be sufficient to only define this >> now for GRE >>>> and if someone comes up with a need for using IP/IPsec >>>> directly after >>>> the TLV header they can define that behaviour and request >> a new type >>>> value. >>>> >>>> So the new draft would only allocate one value for GRE. >>>> >>>> Any objections to this ? please respond quickly, we need to finish >>>> this ASAP. >>>> >>>> Thanks, >>>> Hesham >>>> _______________________________________________ >>>> 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 Apr 3 23:17:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CD928C393; Thu, 3 Apr 2008 23:17: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 86E4128C425 for ; Thu, 3 Apr 2008 23:17:39 -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 BhHuD4AUE81b for ; Thu, 3 Apr 2008 23:17:37 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 50F6528C418 for ; Thu, 3 Apr 2008 23:17:37 -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-maile12) with ESMTP id m346Hes4028121; Fri, 4 Apr 2008 15:17:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m346HeM22065; Fri, 4 Apr 2008 15:17:40 +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 m346HdW18655; Fri, 4 Apr 2008 15:17:40 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 14:17:15 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 04 Apr 2008 14:17:04 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 04 Apr 2008 14:17:04 +0800 From: "Benjamin Lim" To: "'Ryuji Wakikawa'" References: <47F4A002.5040109@gmail.com> Date: Fri, 4 Apr 2008 14:17:04 +0800 Message-ID: <002201c8961b$805cfc00$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F4A002.5040109@gmail.com> thread-index: AciVaybB0KNObL6qQHCEPqTKCd170wArDRNw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 04 Apr 2008 06:17:15.0465 (UTC) FILETIME=[87151B90:01C8961B] Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, = See below. =3D8=3D=3D8<=3D8=3D=3D > RFC3775 clearly said that the HA entry MUST be deleted when = > its lifetime is expired. [Ben] Which part of 3775 states this? Base on section 11.4.1, I did not see such comment. > BUT the lifetime is not always available... > = > So far, we have two options for this. > = > 1. George > No cache. MN does not record the HA information in its = > home agent list. > 2. Vijay > Local configuration matter. No modification is required = > to RFC3775. > = > I personally agree with Vijay, but I think we need some = > clarification for this in the bis. > We might need to define the default value for the locally = > configured HA lifetime.. [Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically mention what MN will do to the list of HA address received in DHAAD reply. I think the confusion comes in because the section state one possible way to do home registration is to perform a sequential trial of each home agent address in the list (e.g. test 1st HA address --> fail --> test 2nd HA address --> fail --> until end of list or succeed.) So this implies that MN should store the list of HA address in order to do the above action. Whether this list is store temporary (just to find HA) or permenantly (info for MN in case HA goes down) is not mention. Maybe we should add some clarifying text for this matter? Regards, Benjamin Lim > = > regards, > ryuji > = > George Tsirtsis > > Guys, > > > > I am not sure I follow you. > > > > My understanding of the HA advertising a Lifetime on a link = > is that it = > > allows nodes on the link to (1) discover the HA address (2) = > cache the = > > HA address for as long as the lifetime indicates. This = > makes sense *on > > link* since end nodes may discover the HA capability but = > they may also = > > have no use for it for a while (e.g., until a handoff to a foreign = > > link). > > > > If this explanation is correct, I would argue that when the HA is = > > discovered from a foreign link e.g., using DHAAD, DNS, DHCP = > etc, the = > > HA address must be used immediately and thus should NOT be = > cached. In = > > other words the MN should discover the HA address when it = > needs it and = > > then either engage with it or forget about it. > > > > Does this make sense? > > > > George > > > > On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim = > > wrote: > > = > >> Hi, > >> > >> Just saw this mail in my back-log. Comments inline. > >> > >> > >> > -----Original Message----- > >> > From: mext-bounces@ietf.org = > [mailto:mext-bounces@ietf.org] On > = > >> Behalf Of RYUJI WAKIKAWA > Sent: Monday, March 17, 2008 = > 4:39 PM > = > >> To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] The = > >> usage of "HA lifetime" (RFC3775-update) > > Hi Hesham > = > > I guess = > >> this HA lifetime (Home Agent Information Option) > might be = > >> originally introduced for the management of home > agents = > operated = > >> on the same link. > >> > Indeed, all the description for this option are for the Home > = > >> Agent operation in RFC3775. > >> [Ben] Most likely, HAs on home link uses lifetime to compute = > >> preferences on the avaliability of HAs, since 3775 states that HA = > >> will reply MN in the HA list a number of prefered HAs. > >> > >> > >> > > >> > We should clearly state that this option is used only for HA > = > >> and not for MN. > >> > The usage of the home agent information option can be = > limited > = > >> to the HA. > >> [Ben] Why limit for HA usage? You pointed out in your = > previous mail = > >> that since MR/MN does not know HA lifetime, is it not = > better to also = > >> inform MR/MN of HA's lifetime in the HA list to advert = > those issues you raised up? > >> > >> Regards, > >> Benjamin Lim > >> > >> > >> > >> > We just need to add 1-2 lines for the better = > clarification of this. > >> > > >> > what do you think? > >> > > >> > regards > >> > ryuji > >> > > >> > > >> > > >> > > >> > On 2008/03/14, at 12:44, Hesham Soliman wrote: > >> > > >> > > I think this is a valid point but I don't know if 3775 is the = > >> right > > place to address it. Since DHAAD is the only mechanism = > >> defined in > > 3775 there is no issue. Other RFCs that = > define other = > >> > mechanisms need > > to address the missing information. > >> > > > >> > > Hesham > >> > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > >> > > > >> > >> Hi > >> > >> > >> > >> In RFC3775, the HA can advertise the HA lifetime by the Home = > >> Agent > >> information option carried in RA. > >> > >> However, this home agent lifetime is only available = > in this option. > >> > >> > >> > >> When MR boots up from a foreign link, there are = > several > ways = > >> to get > >> HA address such as DNS lookup, DHAAD (no HA lifetime = > >> field > is defined > >> in DHAAD message), etc. > >> > >> > >> > >> How should MN manage these HAs in the home agent list? > >> > >> > >> > >> When the HA lifetime is not available, should MN set > = > >> INFINITY value > >> for the HA in the home agent list? > >> > >> > >> > >> When MN obtains HA at the foreign link and then back to the = > >> home, > >> shall MN update the HA lifetime of that HA to = > the value = > >> > specified in > >> RA? > >> > >> > >> > >> MN might lose the HA due to the HA lifetime = > expiration if > it = > >> return > >> home. > >> > >> If it never returns home, MN can keep the HA address = > > forever = > >> This is > >> not fair:-) > >> > >> I need some = > clarification how = > >> we can use this HA lifetime. > >> > >> > >> > >> regards, > >> > >> ryuji > >> > >> > >> > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! > >> > >> > >> > >> > >> > -------------------------------------------------------------- > >> > ----------- > >> > >> CALL FOR PAPERS > >> > >> > >> > >> MobiCom 2008 > >> > >> The Fourteenth Annual International Conference > >> > >> on Mobile Computing and Networking > >> > >> > >> > >> September 14-19, 2007 > >> > >> San Francisco Bay Area, CA, USA > >> > >> http://www.sigmobile.org/mobicom/2008/ > >> > >> Sponsored by ACM SIGMOBILE > >> > >> > >> > = > >> = > --------------------------------------------------------------------- > >> > >> ---- ACM MobiCom is the premier international conference > = > >> dedicated to > >> addressing the challenges in the areas = > of mobile = > >> computing and > >> wireless and mobile networking. It = > has served as = > >> an exciting > >> international forum since 1995, addressing = > >> networks, systems, > >> algorithms, and applications that support = > >> the symbiosis of mobile > >> computers and wireless = > networks. This = > >> year, we will continue this > >> tradition, but we especially = > >> encourage the submission of papers in > >> the = > experimental systems = > >> area. This area has seen exciting > >> developments in = > recent years = > >> and explicit efforts will be taken to > >> represent it = > strongly at = > >> MobiCom this year. > >> > >> > >> > >> Authors are invited to submit full papers, challenges > = > >> papers, student > >> posters, and research demos and exhibits, = > >> presenting new research > >> related to the theory or practice of = > >> mobile computing > and/or wireless > >> and mobile = > networking. All = > >> submissions must describe original > >> research, not = > published or = > >> currently under review for another > >> conference or = > journal. Areas = > >> of interest include, but are > not limited > >> to: > >> > >> > >> > >> * Operating system and middleware support for mobile = > computing and > >> > >> networking > >> > >> * Architectures, protocols, and algorithms to cope = > with mobility, > >> > >> limited bandwidth, limited power and/or = > intermittent connectivity > >> > >> * Fundamental understanding of mobile computing and = > wireless > = > >> >> networking > >> * Wireless and mobile techniques for delay = > >> tolerant, mobile ad hoc, > >> > >> and wireless sensor networks > >> > >> * Security, privacy, and trustworthiness of mobile = > and wireless = > >> > >> systems > >> * Wireless access technologies (e.g. = > mesh systems, = > >> PANs) > >> * Integration and interworking of wired and wireless = > >> networks > >> * Protocols exploiting novel technologies = > such as UWB, = > >> MIMO, > >> > >> directional antennas, and software radios > >> > >> * Techniques for dynamic spectrum use > >> * Architectures, = > >> algorithms and protocols for cognitive wireless > >> > >> networks and their integration in the Internet > >> > >> * Modeling, measurement and simulation of mobile = > networks > >> = > >> * Experimental test-beds for mobile/wireless networks > >> * = > >> Performance evaluation of mobile and wireless networks, > = > protocols, > >> > >> and systems > >> > >> * Next generation (beyond 802.11) wireless = > technologies and related > >> > >> systems and protocols > >> > >> > >> > >> Submission Instructions > >> > >> Detailed instructions on how and where to submit = > your paper can = > >> be > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf > >> > >> > >> > >> IMPORTANT DATES: > >> > >> Abstracts submission due: March 7, 2008 Paper submission > = > >> due: March > >> 14, 2008 Notification of acceptance: June = > 19, 2008 = > >> Camera-ready > >> version due: July 7, 2008 > >> > >> General = > >> Chair - jj@soe.ucsc.edu: > >> > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC > >> > >> = > >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: > >> > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter > = > Steenkiste, = > >> Carnegie > >> Mellon University > >> > >> FOR MORE INFORMATION: = > >> Please contact the General Chair or Program > >> = > Co-Chairs for more = > >> information. For information on ACM > SIGMOBILE and > >> the = > >> MobiCom series of conferences, see > = > http://www.sigmobile.org/ or > = > >> >> contact mobicom_info@acm.org. > >> > >> > >> > >> > >> > -------------------------------------------------------------- > >> > ----------- > >> > >> CALL FOR PAPERS > >> > >> > >> > >> ACM MobiArch 2008 > >> > >> An ACM SIGCOMM 2008 Workshop > >> > >> Seattle, WA, USA, August 22, 2008 > >> > >> > >> > >> The 3rd ACM International Workshop on > >> > >> Mobility in the Evolving Internet Architecture > >> > >> Paper registration deadline: March 17, 2008 > >> > >> > >> > = > >> = > --------------------------------------------------------------------- > >> > >> ---- > >> > >> > >> > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > >> > >> > >> > >> Recent developments in wireless access technologies = > and mobile = > >> > >> devices are beginning to make widespread user, = > terminal > and = > >> network > >> mobility a reality in the commercial = > Internet. At the = > >> same > time, the > >> Internet architecture struggles to = > >> incorporate the > functionality that > >> will sustain this = > >> increasingly more mobile and more > dynamic Internet > >> use. > >> > >> Efficient > >> > >> mobility management and mobility optimizations, = > >> locator-identifier > >> splits, multihoming, security and related = > >> network operation and > >> management functions are still in the = > >> early stages of > development. It > >> is, however, = > already clear = > >> that supporting widespread > mobility poses > >> to = > significantly = > >> impact the original end-to-end design of the > >> Internet. > >> > >> > >> > >> At the same time, critical momentum is building to = > >> significantly > >> revise or even replace the current Internet = > >> architecture. Several > >> substantial Future Internet = > initiatives = > >> have started in > Europe, the > >> US and Asia, and the topic is = > >> also actively being discussed in the > >> vendor and network = > >> operator communities. These Future Internet > >> efforts = > offer the = > >> exciting opportunity to design radically > different > >> = > >> approaches to supporting host and network mobility and > = > >> multihoming, > >> and may eventually lead to an internetwork = > >> architecture with > >> significantly more advanced = > mobility features = > >> than those that the > >> piecemeal extensions of the current = > >> Internet protocols result in. > >> > >> > >> > >> MobiArch'08 welcomes submissions from both = > researchers and > = > >> >> practitioners that explore recent advances in = > architectures, > >> = > >> protocols and emerging technologies to enable mobility and > >> = > >> multihoming in the Internet, as well as concepts and = > designs to > >> = > >> support widespread mobility and multihoming in future > = > >> internetworks. > >> > >> Early results, position papers, systems and = > measurement papers = > >> are > >> particularly welcome. > >> > >> > >> > >> TOPICS > >> > >> MobiArch'08 covers all aspects related to mobility in the > = > >> current and > >> future Internet, including, but not limited to: > >> > >> > >> > >> * Architectures and protocols for mobility support = > at all layers > >> > >> of the Internet protocol stack, as well as = > cross-layer approaches > >> > >> * Novel concepts to support widespread mobility and = > multihoming > >> > >> in a Future Internet > >> > >> * Routing and addressing issues (including locator/identifier > >> > >> splits) and their impact on the Internet architecture > >> > >> * Multihoming, including flow distribution and = > load-sharing for > >> > >> wireless and mobility > >> > >> * Performance evaluation, experimentation and modeling of > >> > >> Internet mobility > >> > >> * Models for mobility patterns and their experimental = > >> validation > >> * New wireless technologies and services = > and their impact on the > >> > >> Internet architecture > >> > >> * Location management, positioning and data management for > >> > >> wireless and mobility > >> > >> * Accounting, access control, security and privacy issues and > >> > >> their impact on the Internet architecture > >> > >> * Social, economic, scalability and deployment = > issues > >> > = > >> >> SUBMISSION GUIDELINES > >> Submissions must be no = > longer than six = > >> pages, including > all figures > >> and references, must = > be in PDF = > >> format, and must follow the ACM > >> formatting guidelines > >> = > >> (http://www.acm.org/sigs/publications/proceedings-templates > >> > >> ). > >> > >> Submissions that do not adhere to these requirements = > will > be = > >> rejected > >> without further review. > >> > >> Peer review is single-blind; the authors names and > = > >> affiliations are > >> to be included on the submission. = > Submissions = > >> cannot be previously > >> published or be under concurrent review = > >> elsewhere. The > submission of > >> position papers is = > encouraged; = > >> please clearly identify position > >> papers as such when = > >> submitting. > >> > >> Papers may be submitted at = > http://edas.info/newPaper.php?c=3D6140 > >> > >> > >> > >> IMPORTANT DATES > >> > >> March 17, 2008 Registration of paper abstract > >> > >> March 24, 2008 Submissions due > >> > >> May 1, 2008 Notification of acceptance > >> > >> June 9, 2008 Camera ready version due > >> > >> August 22, 2008 Workshop date > >> > >> > >> > >> > >> > >> TECHNICAL PROGRAM COMMITTEE > >> > >> Lars Eggert (co-chair, Nokia Research Center, FI) > >> > >> Linda Doyle (co-chair, Trinity College, IE) > >> > >> Rui Aguiar (Universidade de Aveiro, PT) > >> > >> Bengt Ahlgren (Swedish Institute of Computer = > Science, SE) > >> > >> Jari Arkko (Ericsson, FI) > >> > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) > >> > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) > >> > >> Wesley Eddy (NASA/Verizon (US) > >> > >> Joseph Evans (University of Kansas, US) > >> > >> Ted Faber (USC Information Sciences = > Institute, US) > >> > >> Stephen Hailes (University College London, UK) > >> > >> Roger Karrer (T-Labs, DE) > >> > >> Rajeev Koodli (Nokia Research Center, US) > >> > >> Donal O'Mahony (Trinity College, IE) > >> > >> J=F6rg Ott (Helsinki University of Technology, FI) > >> > >> Guru Parulkar (Stanford University, US) > >> > >> Dipankar Raychaudhuri (Rutgers University, US) > >> > >> Dave Thaler (Microsoft, US) > >> > >> Ryuji Wakikawa (Keio University, JP) > >> > >> Klaus Wehrle (RWTH Aachen University, DE) > >> > >> Lixia Zhang (UCLA, US) > >> > >> > >> > >> _______________________________________________ > >> > >> 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 Apr 4 00:22:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1A93A6997; Fri, 4 Apr 2008 00:22: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 CD1203A694E for ; Fri, 4 Apr 2008 00:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90IiVSM+5VX8 for ; Fri, 4 Apr 2008 00:22:37 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id 707923A6997 for ; Fri, 4 Apr 2008 00:22:36 -0700 (PDT) Received: (qmail 8043 invoked from network); 4 Apr 2008 09:22:39 +0200 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 4 Apr 2008 09:22:39 +0200 From: "Teco Boot" To: "'Hesham Soliman'" References: <001201c89592$46f5d920$d4e18b60$@nl> <5FD0C946-5E2D-4754-A3F6-543B697991BD@elevatemobile.com> In-Reply-To: <5FD0C946-5E2D-4754-A3F6-543B697991BD@elevatemobile.com> Date: Fri, 4 Apr 2008 09:22:05 +0200 Message-ID: <004901c89624$a82427f0$f86c77d0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciVlbr/XX1yRXyfRsmO7pAOMb1fWwAi5JGQ Content-Language: nl Cc: mext@ietf.org Subject: Re: [MEXT] [Mipshop] TLV header in DSMIP 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 Hesham, I do not want to delay something. On 3 octets unneeded overhead: I think this is a major issue in any HC scheme. My background is radio links with low data rates. Check for example RFC4944 (IPv6 over IEEE 802.15.4). I appreciate comments from HC experts. Regards, Teco > -----Oorspronkelijk bericht----- > Van: Hesham Soliman [mailto:hesham@elevatemobile.com] > Verzonden: donderdag 3 april 2008 16:19 > Aan: Teco Boot > CC: mext@ietf.org > Onderwerp: Re: [Mipshop] [MEXT] TLV header in DSMIP > > Hi teco, > > On 04/04/2008, at 12:54 AM, Teco Boot wrote: > > Hi Hesham, > > I posted before on using TLV-encap for tunnel optimization (e.g. > > header > > compression). > > I think type values can be requested at time of defining protocols > > for this. > > But I think tunnel optimization needs a more efficient TLV > > structure: 1 > > octet for only the type is needed, the other 3 octets are overhead > and > > should be eliminated. > > Any objection mentioning such a usage? If not, we block something > that > > really makes sense. > > => While i sympathise with your idea, I think that, as I said before, > the benfits are minimal. Please note > that practically we don't expect this TLV header to be used by MNs. So > compression is not needed. > Especially, at this stage (including the time you raised it), I don't > think it's worth delaying things for it. > That's my opinion anyway. > > Hesham > > > > > Teco. > > > >> -----Oorspronkelijk bericht----- > >> Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens > >> Hesham > >> Soliman > >> Verzonden: donderdag 3 april 2008 10:45 > >> Aan: mext@ietf.org > >> Onderwerp: [MEXT] TLV header in DSMIP > >> > >> Folks, > >> > >> During one of the reviews for DSMIP the issue came up regarding the > >> TLV header Type field values and how the current spec doesn't > >> describe > >> how it can be used for IPsec. > >> After looking into this a bit I don't see why we would need IPsec > for > >> this. We originally defined because people wanted to use GRE so the > >> format would be: > >> IP > >> UDP > >> GRE > >> IP > >> ...etc > >> > >> It seems like it would be sufficient to only define this now for GRE > >> and if someone comes up with a need for using IP/IPsec directly > after > >> the TLV header they can define that behaviour and request a new type > >> value. > >> > >> So the new draft would only allocate one value for GRE. > >> > >> Any objections to this ? please respond quickly, we need to finish > >> this ASAP. > >> > >> Thanks, > >> Hesham > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > Mipshop mailing list > > Mipshop@ietf.org > > https://www.ietf.org/mailman/listinfo/mipshop _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Apr 4 02:43:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C3628C725; Fri, 4 Apr 2008 02:43: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 879B928C3B5 for ; Fri, 4 Apr 2008 02:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.94 X-Spam-Level: X-Spam-Status: No, score=-4.94 tagged_above=-999 required=5 tests=[AWL=1.659, 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 ZXqAZQn+7jUb for ; Fri, 4 Apr 2008 02:43:07 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DFAB228C72A for ; Fri, 4 Apr 2008 02:43:03 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m349gwgr022885; Fri, 4 Apr 2008 12:42:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 12:42:48 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 12:42:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 12:42:46 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] TLV header in DSMIP thread-index: AciV7JcHp9ujr/DUR4GCuPDowBv+UgASzapA References: From: To: , X-OriginalArrivalTime: 04 Apr 2008 09:42:48.0485 (UTC) FILETIME=[3E229D50:01C89638] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Devarapallli wrote: > Without this, you end up using UDP port 4500 for IPsec protected > data traffic between the mobile node and the home agent and the > DS-MIPv6 UDP port for non-IPsec protected data traffic between the > mobile node and the home agent. I would prefer to avoid this. In the current spec (version -01) this is precisely the situation: traffic protected with IPsec tunnel mode uses port 4500. (BU/BAck is protected with transport mode IPsec, but in that case, the packet also has an IPv6 header, so the TLV-Header type would be IPv6.) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Apr 4 04:22:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF1828C62A; Fri, 4 Apr 2008 04:22: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 9CBC528C62A for ; Fri, 4 Apr 2008 04:22: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 cVs85u5vN4b7 for ; Fri, 4 Apr 2008 04:22:28 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id A10E828C1E3 for ; Fri, 4 Apr 2008 04:22:27 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m34BMVwM014887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Apr 2008 12:22:31 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m34BMUbT009958 for ; Fri, 4 Apr 2008 12:22:31 +0100 Message-ID: <47F60F77.7000809@mccallumwhyman.com> Date: Fri, 04 Apr 2008 12:22:31 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] A Proposed Solution for Aeronautical RO 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 Dear all, I have prepared a proposed IPsec based RO scheme that is intended to meet the requirements contained in draft-ietf-mext-aero-reqs-01. The paper can be downloaded from: http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.pdf It's a large paper (15,000+ words) but that is because of the large Appendix A, which is an analysis of how the proposal meets the current aeronautical use cases. Appendix B also provides a compliancy check against draft-ietf-mext-aero-reqs-01. The main body of the paper is likely to be of most interest to this group. In this, I have tried to evolve the IPsec RO approach proposed in draft-ietf-mip6-cn-ipsec-07 into a common framework with the recommendations of Eurocontrol 2006 IP Study. This study was intended to "assess the feasibility of using IP to support the next generation of collaborative ATS applications, in the 2020+ timeframe". The published results of that study can be downloaded from the ICAO website (URL in the references list of my paper). Although the focus of the paper is on meeting the requirements for Aeronautical use, I do not believe that the requirements are unique to civil aviation. The UK Railways Safety and Standards Board (RSSB) is also about to publish a Guidance Note (Ref: GE/GN8579) which is intended to co-ordinate the use of IP Networking for mobile networking to trains. SATCOM, GPRS, WiFi and WiMAX networks are already being used to support passenger "on train" internet access and some operational use, and this Guidance Note is intended to co-ordinate the use of IP for operational comms, leading into Safety Related applications. It was the result of industry consultation and workshops and resulted in a very similar set of operational scenarios to those seen in ATC, and a similar proposal for IPsec based mobile communications. My own conclusion from all this, is that there is a real need for an IPsec based Mobility Framework to meet the needs of Operational Communications in (at least) Transport Infrastructure applications. My paper has made some specific criticisms of draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the needs of aeronautical communications. However, the underlying criticism is that draft-ietf-mip6-cn-ipsec-07 is relatively neutral as regards IKEv1 and IKEv2. My view is that IKEv2 is not just a better protocol, but with improved Traffic Selection signalling and the MOBIKE (RFC 4555), it is the only flavour of IPsec IKE that should be considered for an IPsec based mobility framework. Starting with the assumption that IKEv2/MOBIKE is used, I believe that it is possible to demonstrate a much improved strategy for IPsec based Route Optimisation, that starts with the use of the Home Address as the MN SA end-point and then moves it to the care-of address. Thus demonstrating both authorisation to use the Home Address and Return Routability to both addresses before any user data is exchanged. Interestingly, if user data is to be protected by ESP or AH tunnelling then there seems to be no need to exchange a Binding Update, as Child SAs with appropriate Traffic Selectors seem to be sufficient. A further step is also possible if both MN and CN support a common PKI that provides both authentication and authorisation of the MN to use its Home Address. In this case, it appears possible for the MN to start the IPsec based RO procedure direct from its care-of address without there needing to be any Home Agent involvement. This is particularly interesting to aeronautical use, where communication is generally aircraft initiated, as it avoids both availability and regulatory issues with Home Agents, and fits with the recommendations of the Eurocontrol IP Study. Although it did not call it as such, this study essentially proposed an IPsec based RO scheme, which it called "tunnel movement" and assumed a PKI that authenticated aircraft and their use of their static IP Addresses. The study limited itself to what was possible with published RFCs, and thus all air/ground communications had to be ESP tunnelled, due to the use of IKEv2/MOBIKE to manage the communications paths. Two specific criticisms arise from this. One is that there are many cases where an RFC 3775 Home Address Option/Type 2 Routing Header and Transport mode ESP would be more efficient than ESP tunnelling, and the other is that it forces all air/ground communications to be protected, even when the overhead of doing so is not otherwise justifiable. In my paper, I have tried to resolve both criticisms. I have resolved the first, by proposing a new IPsec SA mode that essentially combines ESP/AH transport mode with use of the RFC 3775 Home Address Option/Type 2 Routing Header. I have resolved the second by proposing the notion of "No Protection" SAs - i.e. using the IKEv2 to negotiate IP-in-IP tunnels, or use of the RFC 3775 Home Address Option/Type 2 Routing Header. Although this seems to be counter-intuitive for the IPsec IKE to negotiate off security, the benefit is in having a single mechanism to manage unprotected mobile communications, when there is also a need for secure mobile communications. My paper also examines the case where the IKE is used to manage secure mobile communications but has no means of authenticating the MN to the CN. This appears to be interesting as part of a wider framework, but is not of direct interest to aeronautical communications. I have also investigated possible implications for MN to HA communications, and proposed IKEv2/MOBIKE scenarios where Binding Updates are no longer needed here. Again, this is not of direct interest to aeronautical communications, but should be of wider interest. Looking back on the paper, although I started writing assuming IPv6 only, almost everything proposed is also relevant to IPv4. Only the use of the RFC 3775 Home Address Option/Type 2 Routing Header is IPv6 specific. Using the IKE to manage mobility also seems to have some other interesting implications. Like it or not, NAT Gateways are well supported by IPsec, and a Mobile Node that uses IKEv2/MOBIKE to manage both its HA binding and RO, seems to be able to move behind NAT Gateways and then re-emerge without any obvious problems - although this mode of operation is limited to ESP tunnels. Basic NEMO operations should really be just a case of an appropriate set of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that allows a CN to authenticate a Mobile Router and authorise the routes it offers, then the use of the IKE to manage Mobile Router Route Optimisation also appears to be an interesting approach. This is very relevant to Aeronautical use. IKEv2/MOBIKE has limited multi-homing capability, in respect of supporting the use of multi-homing for increasing availability. Load sharing is not part of the current framework. The use of multi-homing for increasing availability meets a perceived aeronautical requirement to enable high availability of air/ground communications through agility in the use of alternative networks. Extension to load sharing seems to a suitable topic for future work, but not essential for aeronautical use. The purpose of this paper is to develop an IPsec based RO strategy suitable for aeronautical use and one that is also suitable for similar transport infrastructure uses, but I believe the use of IPsec based mobility management using IKEv2 and MOBIKE should be of general interest. Regards Tony Whyman _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Apr 4 06:06:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A3228C27E; Fri, 4 Apr 2008 06:06: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 0BC363A697F for ; Fri, 4 Apr 2008 06:06:43 -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 uxVHs-d25uUU for ; Fri, 4 Apr 2008 06:06:32 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.183]) by core3.amsl.com (Postfix) with ESMTP id C29DD28C5CD for ; Fri, 4 Apr 2008 06:05:17 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so19827ika.5 for ; Fri, 04 Apr 2008 06:05:22 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qPyrW6h2UvYg023vugR5am1nPRTNXvpFI9IaG0aVBFU=; b=qXBRC05w2DVbs8o8Pfqs+6IIGjCkdFZq6WwqP4pJcHRubOO+IL5DQXddQi/ptXmTgAveK/ShFxFT7UEjG8x0+3yEDCnN0upVM82t41jWgKEoWhYhQEa4Is0xJvBrHTMZ/MFRo4e3GwDYyhNLCuwGkQnCmy5oHucwkBBt3KD6H+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=SvdXc3kzxoo+zFzzte9peJxNGFxDri+B6i7COPF+efkWkjMuOfN4IfV4EFwmDEnAQEC09D5mzYnQWr4NTKUbLk6LA7GsbZ1V8YzA/JLHDxU35R0uzs9Kwkq6wUScRjdFn3KMvKa8oG+L6U2e2+WiM7XkLklW5JqfQzbBKWHT/m0= Received: by 10.142.215.5 with SMTP id n5mr845155wfg.11.1207314321392; Fri, 04 Apr 2008 06:05:21 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Fri, 4 Apr 2008 06:05:21 -0700 (PDT) Message-ID: Date: Fri, 4 Apr 2008 14:05:21 +0100 From: "George Tsirtsis" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Pasi, you describe this as the way it is ...but do you have a problem with that and why? Thanks George On Fri, Apr 4, 2008 at 10:42 AM, wrote: > Vijay Devarapallli wrote: > > > Without this, you end up using UDP port 4500 for IPsec protected > > data traffic between the mobile node and the home agent and the > > DS-MIPv6 UDP port for non-IPsec protected data traffic between the > > mobile node and the home agent. I would prefer to avoid this. > > In the current spec (version -01) this is precisely the situation: > traffic protected with IPsec tunnel mode uses port 4500. > > (BU/BAck is protected with transport mode IPsec, but in that case, > the packet also has an IPv6 header, so the TLV-Header type would > be IPv6.) > > Best regards, > Pasi > > > _______________________________________________ > 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 nemo-bounces@ietf.org Fri Apr 4 06:41:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3656328C66E; Fri, 4 Apr 2008 06:41:51 -0700 (PDT) X-Original-To: nemo@core3.amsl.com Delivered-To: nemo@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC1E3A68D7 for ; Fri, 4 Apr 2008 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 HvtUS7wfYMZ5 for ; Fri, 4 Apr 2008 06:41:48 -0700 (PDT) Received: from web33505.mail.mud.yahoo.com (web33505.mail.mud.yahoo.com [68.142.206.154]) by core3.amsl.com (Postfix) with SMTP id 6935328C4A6 for ; Fri, 4 Apr 2008 06:41:48 -0700 (PDT) Received: (qmail 80501 invoked by uid 60001); 4 Apr 2008 13:41:53 -0000 X-YMail-OSG: mCOayCwVM1kUw52n1CM0NGapRzdelw6PB62OF6DN5e7BYV2Fw2mqMVxtGZ0F6APF1XB5r.VpgVJd9K1vca6ZYZQ6zagum4uH8nm74.IuylUjDpwDjxw- Received: from [69.246.189.183] by web33505.mail.mud.yahoo.com via HTTP; Fri, 04 Apr 2008 06:41:52 PDT X-RocketYMMF: yangxiao_acm Date: Fri, 4 Apr 2008 06:41:52 -0700 (PDT) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <185246.80459.qm@web33505.mail.mud.yahoo.com> Subject: [nemo] Journal Special Issue on Electronic Health ( Due on May 1) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org NEWS: International Journal of Telemedicine and Applications (IJTA) is now available on the public PubMed Central (PMC) site under the U.S. National Institutes of Health (NIH). International Journal of Telemedicine and Applications (IJTA) Special Issue Announcement Electronic – Health Electronic health (E-health) becomes a very important area, involving multiple fields, such as health, healthcare, public health, medical science, health service, data management, image processing, telecommunication, wireless network, operational research, etc. The purpose of the special issue is to provide quick journal paper publications on any topic related to E-Health. Specific areas of interest include (but are not limited to): · Health promotion, health prevention (e.g. of persons with risk factors) · Diagnosis, second opinion · Treatment, support to treatment · E-heath Decision support systems · Reducing error in healthcare delivery · Hospital based care · Ambulatory based care · Primary health based care · Home care · On the move care/support · Cross border care · Care in developing countries · International care · Reimbursement issues · Legal issues · E-heath education issues · E-heath change management issues · Change the way healthcare is delivered · Quality of Patient Care · Wireless/Mobile Telemedicine · E-health Data Management · Prevention of Medical Errors · E-health information Technology · Reduction of Healthcare Costs · Medical Image/Video Processing and Mining · Medical resource allocation, Optimization, and Simulation · E-health Text Mining · E-health Data Warehouses · Clinical Decision Support · Emergency Care · E-health Information Modeling and Integration · E-health Information Retrieval, Analysis, Visualization and Prediction · E-health Knowledge Discovery · Security, Privacy and Trust in E-health · Lessons Learned from E-health Information System Implementation · Tele-homecare and Ubiquitous Healthcare · Tele-presence and Robotics in Healthcare · E-Health Initiatives of World Bodies · Health Monitoring · Emerging Technologies for Rehabilitation · Tele-Rehabilitation and Tele-Physiotherapy · Sensor Networks for Patient and Elderly Care · Semantic Web in Healthcare · Navigation Systems for Healthcare · Computing for Human Experience and Wellness · Medical Nomadic Computing · Healthcare Industry Applications · Rural e-HealthCare Management · Healthcare Cost & Financial Analysis · Context-awareness for Smart Space in Healthcare · IT Infrastructures and Platforms for Remote Healthcare · etc. Authors should follow the International Journal of Telemedicine and Applications manuscript format described at the journal site http://www.hindawi.com/journals/ijta/. Prospective authors should submit an electronic copy of their complete manuscript through the journal Manuscript Tracking System at http://mts.hindawi.com/, according to the following timetable: Schedule: · Submission deadline: May. 1, 2008 · Notification: Aug. 1, 2008 · Publication of special issue: Nov. 1 2008 Guest Editors Hui Chen, Virginia State University, USA E-mail: huichen@ieee.org Arnauld Nicogossian, George Mason University, USA E-mail: anicogoss@cox.net Silas Olsson, Healthaccess, Sweden E-mail: silas.olsson@healthaccess.eu Azhar Rafiq, Virginia Commonwealth University, USA E-mail: fiq@vcu.edu Max E. Stachura, Medical College of Georgia, USA E-mail: MAXS@mail.mcg.edu Mamoru Watanabe, University of Calgary, Canada E-mail: watanabe@ucalgary.ca Pamela Whitten, Michigan State University, USA E-mail: pwhitten@msu.edu Yang Xiao, The University of Alabama, USA E-mail: yangxiao@ieee.org From mext-bounces@ietf.org Fri Apr 4 12:21:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C4A3A68CE; Fri, 4 Apr 2008 12:21: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 6350C3A68CE for ; Fri, 4 Apr 2008 12:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=3.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 q3epGDn2mr5j for ; Fri, 4 Apr 2008 12:21:09 -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 5AC8C3A6884 for ; Fri, 4 Apr 2008 12:21:09 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2008 12:21:16 -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 m34JLFwO006516; Fri, 4 Apr 2008 12:21:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m34JLFjt015951; Fri, 4 Apr 2008 19:21:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:21:14 -0700 Received: from [192.168.1.105] ([10.21.79.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:21:13 -0700 Message-Id: <960BCFE4-1F2F-4063-9BA8-9835764528FB@cisco.com> From: Ralph Droms To: marcelo bagnulo In-Reply-To: <47EA6639.4080101@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 15:21:12 -0400 References: <47EA6639.4080101@it.uc3m.es> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 04 Apr 2008 19:21:13.0812 (UTC) FILETIME=[0C1F4140:01C89689] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=936; t=1207336876; x=1208200876; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[MEXT]=20Decisions,=20and=20next=20step s=20proposed=20in=20IETF71=20MEXT=20meeting |Sender:=20; bh=yF+Yc9NXgEJTHVT09GHzASaJY+EoS//5/etfbyH99KY=; b=mjDwwnfTZaxAXU3iQe/lMPCp9dql7uWhpdPZr/jr+KWKgeJAomIgiu/Kdz MRQio6AtD1HRGiV/sogZSm6u2jnF43iokTmB/JDhUGXLUkHvha/bgRMOlv6E 5CrdHgyoJy; Authentication-Results: sj-dkim-4; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting 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 OK with taking on the revision of the docs as requested by the WG; if all the issues have been worked out, we can start on that work any time. - Ralph On Mar 26, 2008, at Mar 26, 2008,11:05 AM, marcelo bagnulo wrote: > Hi, > > During the two MEXT sessions we had at IETF 71, the WG proposed the > following Action Points and way forward for the different items > discussed. > We attach here a summary of those so that the consensus can be checked > with the ML. We kindly ask to anyone that has issues/concerns with any > of the points described below, please comment on the ml. > > About WG items: > > [...] > > Prefix Delegation for NEMO to the IESG > Strong concensus in the meeting (26 against 2) to work on a DHCP based > solution to delegate prefixes from the HA to the MR. Next step is for > authors of the two drafts to work on a unified draft and submit ti the > WG to decide its adoption. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Apr 4 23:14:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A744D3A69F9; Fri, 4 Apr 2008 23:14: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 1E6713A6970 for ; Fri, 4 Apr 2008 23:14: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 wTIlcZmbxqws for ; Fri, 4 Apr 2008 23:14:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 5A1983A694C for ; Fri, 4 Apr 2008 23:14:26 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so434684wfa.31 for ; Fri, 04 Apr 2008 23:14:34 -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=s+Ib83oT3Y6kfi9+8WGe7bGwSKrwaFWyuMiO5e/hLSg=; b=q6yyhGx/7ounCq7GimPGfnpYbUiVi/ubuW+z9GhjzUdbcb4bsIy37Bn6FtznBUicxcpvu7sFuTu77vyfKp7r6Q90lV2WoPb33GQxnN+i/Qv8X3xeNlAt67JiUXP1NPb782FdXGk3cPtb+oCh48xQpbQsmEG0nLuW5QkW+oTqXGk= 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=Vrak8zvTbBZruKxTq/z+fkRhCKdbypFqpcF0+alY+R8jClmou3zQvzm11GjDtL9AGyI73ewJgsvgpW4l/6RLtlJBLBZD/8OibwKdK9+MuGXtnEgp4CGN7rLo0LyuHsldPVzuR1Mx6dilW7HeT20HcntVTOrWWzj984HD2A8fWsQ= Received: by 10.142.48.3 with SMTP id v3mr96203wfv.282.1207376074036; Fri, 04 Apr 2008 23:14:34 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Fri, 4 Apr 2008 23:14:33 -0700 (PDT) Message-ID: Date: Fri, 4 Apr 2008 23:14:33 -0700 From: "Vijay Devarapallli" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Fri, Apr 4, 2008 at 2:42 AM, wrote: > Vijay Devarapallli wrote: > > > Without this, you end up using UDP port 4500 for IPsec protected > > data traffic between the mobile node and the home agent and the > > DS-MIPv6 UDP port for non-IPsec protected data traffic between the > > mobile node and the home agent. I would prefer to avoid this. > > In the current spec (version -01) this is precisely the situation: > traffic protected with IPsec tunnel mode uses port 4500. Ok, got it. I looked at the security considerations section again. I forgot that in version 06, we mandate that port 4500 is always used for IPsec protected payload traffic, irrespective of whether we use vanilla UDP or TLV-header UDP encapsulation. In version 05 and earlier, we didn't have this restriction. One could use the TLV-header UDP encapsulation (and the DS-MIPv6 port) for the IPsec protected payload traffic too. Since we mandate that port 4500 is always used, it does not make sense to reserve the 'IPsec Type" value in the TLV header. So, we can remove that. Vijay > (BU/BAck is protected with transport mode IPsec, but in that case, > the packet also has an IPv6 header, so the TLV-Header type would > be IPv6.) > > Best regards, > Pasi > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 5 00:11:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2CF3A6AD4; Sat, 5 Apr 2008 00:11: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 BCAB53A6953 for ; Sat, 5 Apr 2008 00:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[AWL=1.448, 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 2UZZz51GlI+6 for ; Sat, 5 Apr 2008 00:11:15 -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 62D433A68D9 for ; Sat, 5 Apr 2008 00:09:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,608,1199692800"; d="scan'208";a="20058416" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2008 00:10:05 -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 m357A5ef007082; Sat, 5 Apr 2008 00:10:05 -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 m357A4wB014219; Sat, 5 Apr 2008 07:10:04 GMT Date: Sat, 5 Apr 2008 00:10:04 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapallli In-Reply-To: Message-ID: References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1722; t=1207379405; x=1208243405; 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]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=TSO7+ieRBGMMYKmgkW4bMO0IBKS+5vTRK69HiPbQ6kc=; b=RyyKaW2uwbj8BLcdfIeZL25g3SstIbsGHzp4PIm9mGRDFcZ2MaUGwGaCc4 7JG6vjPjKaXekyUoSlr/fCvSs0UNKdCvISo5eIOMo8Tr7MJKJ7Gw6fvg1ftH 8eYBQmAjTwEMLeJK8icFdKUxy91q4g6pRItc8nr9p/xzRtAAnLOHc=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Fri, 4 Apr 2008, Vijay Devarapallli wrote: > On Fri, Apr 4, 2008 at 2:42 AM, wrote: >> Vijay Devarapallli wrote: >> >> > Without this, you end up using UDP port 4500 for IPsec protected >> > data traffic between the mobile node and the home agent and the >> > DS-MIPv6 UDP port for non-IPsec protected data traffic between the >> > mobile node and the home agent. I would prefer to avoid this. >> >> In the current spec (version -01) this is precisely the situation: >> traffic protected with IPsec tunnel mode uses port 4500. > > Ok, got it. I looked at the security considerations section again. I > forgot that in version 06, we mandate that port 4500 is always used > for IPsec protected payload traffic, irrespective of whether we use > vanilla UDP or TLV-header UDP encapsulation. In version 05 and > earlier, we didn't have this restriction. One could use the TLV-header > UDP encapsulation (and the DS-MIPv6 port) for the IPsec protected > payload traffic too. > I dont follow this. If port 4500 is in use, 3947/3948 considerations apply. Where does the use of TLV specified ? ESP decapsulation starts right after UDP header. Sri > Since we mandate that port 4500 is always used, it does not make sense > to reserve the 'IPsec Type" value in the TLV header. So, we can remove > that. > > Vijay > >> (BU/BAck is protected with transport mode IPsec, but in that case, >> the packet also has an IPv6 header, so the TLV-Header type would >> be IPv6.) >> >> Best regards, >> Pasi >> > _______________________________________________ > 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 Sat Apr 5 00:16:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592673A6AD3; Sat, 5 Apr 2008 00:16: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 2AB023A6AD3 for ; Sat, 5 Apr 2008 00:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=1.344, 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 cSyrEsYXPeBH for ; Sat, 5 Apr 2008 00:16:23 -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 59C9F3A6854 for ; Sat, 5 Apr 2008 00:16:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,608,1199692800"; d="scan'208";a="20059873" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2008 00:16:31 -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 m357GV5x029963; Sat, 5 Apr 2008 00:16:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m357GVNa016915; Sat, 5 Apr 2008 07:16:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 00:16:30 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 00:16:06 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> Date: Sat, 5 Apr 2008 00:16:05 -0700 Message-ID: <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciWF/ik3rUGzTPeRHWe8GZWXh+aqgA1C+VA In-Reply-To: <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 05 Apr 2008 07:16:30.0713 (UTC) FILETIME=[F896A690:01C896EC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1791; t=1207379791; x=1208243791; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=gDZP99TrmmKO41XpA1LTVlLYIJUPgGZQwdOyhszNhfM=; b=nuc0O/RyK7lpNrKcm5M25WOCden6bn4Hp4dAnBXhB/0IaBMipIPkGYUMwf B2AJ1cdaqq3a6It4O9R0+HH0YtfYHTXAL2XsS0xxOGaFZ8NMFijZoPFLRXF9 LQbJwMl9GD; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, April 03, 2008 10:51 PM > To: Sri Gundavelli > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [MEXT] TLV header in DSMIP > > > On 04/04/2008, at 2:29 PM, Sri Gundavelli wrote: > > > >>> > >>> > >>> IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. > >>> IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. > >>> > >>> This is ok. > >> > >> => If you want to have ESP come right after the TLV then > please send > >> some text to describe this behaviour in terms of IPsec > >> operation. I'm > >> trying to avoid extending the IPsec > >> mess in the spec to strange cases that need more inquiries and more > >> time at this stage. So I'd rather have that specified elsewhere. > >> I think the easiest thing now is to do the format I sent above and > >> later if you want to add ESP/AH ...etc then you can specify > >> that in a > >> draft. > >> > > > > Sure. I understand the pain dealing with all these IPsec issues that > > were raised in the last few months. > > > > However, on this, probably there is not much to specify. > Atleast from > > an implementation angle, its matter of implementing a > tunnel interface > > with a given encap mode and the ESP header just goes after the TLV, > > just as how 3948 allows ESP right after UDP. We can borrow some text > > from Sec 3.4 [3948]. Its just one more encap layer after UDP. > > => Sri, if you think there is not much to do here then please > send text. I can provide the text, if there is agreement that we are using DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on what is the port number that is in use. 4500 or the DSMIP port ? Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 5 01:31:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAF53A6BE7; Sat, 5 Apr 2008 01:31: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 DF1A23A6BC6 for ; Sat, 5 Apr 2008 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 udhACLmpZNhL for ; Sat, 5 Apr 2008 01:31:35 -0700 (PDT) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by core3.amsl.com (Postfix) with ESMTP id BC2BB3A6854 for ; Sat, 5 Apr 2008 01:31:33 -0700 (PDT) Received: from nskntotgx03p.mx.bigpond.com ([124.190.105.201]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20080405083140.QXCL649.nskntmtas02p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Sat, 5 Apr 2008 08:31:40 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20080405083140.GWYV9173.nskntotgx03p.mx.bigpond.com@[192.168.0.187]>; Sat, 5 Apr 2008 08:31:40 +0000 Message-Id: From: Hesham Soliman To: "Sri Gundavelli" In-Reply-To: <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 5 Apr 2008 19:31:40 +1100 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 can provide the text, if there is agreement that we are using > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > what is the port number that is in use. 4500 or the DSMIP port ? => I don't think we need the text now, there is agreement to remove this. We're using 4500 for secure traffic and DSMIP port for other traffic. Hesham > > > Sri > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 5 01:51:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A75C3A6C6C; Sat, 5 Apr 2008 01:51: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 F17263A6C31 for ; Sat, 5 Apr 2008 01:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=1.668, 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 x-QyoD8V7Hqj for ; Sat, 5 Apr 2008 01:51:03 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E63923A697B for ; Sat, 5 Apr 2008 01:50:58 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp01.uc3m.es (Postfix) with ESMTP id 1BAF853353E;Sat, 5 Apr 2008 10:51:03 +0200 (CEST) Received: from 163.117.203.30 ([163.117.203.30]) by webcartero01.uc3m.es(Horde MIME library) with HTTP; Sat, 05 Apr 2008 10:51:01 +0200 Message-ID: <20080405105101.2jd4yisstcgg00g8@webcartero01.uc3m.es> Date: Sat, 05 Apr 2008 10:51:01 +0200 From: MARCELO BAGNULO BRAUN To: Ralph Droms References: <47EA6639.4080101@it.uc3m.es><960BCFE4-1F2F-4063-9BA8-9835764528FB@cisco.com> In-Reply-To: <960BCFE4-1F2F-4063-9BA8-9835764528FB@cisco.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.6393 TC:1F TRN:32 TV:5.0.1023(15830.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 Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting 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 the sooner the better :-) the deadline for this work was on march 2008, so we are already late Thanks, marcelo Ralph Droms dijo: > I'm OK with taking on the revision of the docs as requested by the > WG; if all the issues have been worked out, we can start on that > work any time. > > - Ralph > > On Mar 26, 2008, at Mar 26, 2008,11:05 AM, marcelo bagnulo wrote: >> Hi, >> >> During the two MEXT sessions we had at IETF 71, the WG proposed the >> following Action Points and way forward for the different items discussed. >> We attach here a summary of those so that the consensus can be checked >> with the ML. We kindly ask to anyone that has issues/concerns with any >> of the points described below, please comment on the ml. >> >> About WG items: >> >> [...] >> >> Prefix Delegation for NEMO to the IESG >> Strong concensus in the meeting (26 against 2) to work on a DHCP based >> solution to delegate prefixes from the HA to the MR. Next step is for >> authors of the two drafts to work on a unified draft and submit ti the >> WG to decide its adoption. > > > > -- ---- 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 Sat Apr 5 08:16:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4103A6DAA; Sat, 5 Apr 2008 08:16: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 692853A6BBD for ; Sat, 5 Apr 2008 08:16:34 -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 GZO0oCsOkyJw for ; Sat, 5 Apr 2008 08:16:33 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 19F2C3A6DAA for ; Sat, 5 Apr 2008 08:16:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so605257wfa.31 for ; Sat, 05 Apr 2008 08:16:41 -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=+T4z6JTZXV2z9lzTZVPODn227ib36/Jc1j0qjtDea5E=; b=w42me1qqlNpLCJTSb1OQLypLVimCTmFjV+VgaSNQQBZnUy+AEGdePe9QIwuXxsXoIQqKY5Gu0twZAPEQITnyipdINfnJW+/ekDV9s1AnJvS3lj7z+2FaePFfcC3CrioBb9ZX+9SgDvhooLiDO48bdf+ll4rSM3ZdZLjbVkzkPUw= 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=HEJejsRlrPTtA9HZthN2atG9SI7kb7EXrfKvJWrx3QXc16ILwVZ8wBi0ikuu651BgxxQH501yyvYQ/r/lkUFdzxJZKJCNERkQek3nuleZckEtEWcwuvQMZBBlvXCSeGcxQLdrIaD+YDclCHqBHEpiHQnV08B8FWIGn4t55e893M= Received: by 10.143.34.11 with SMTP id m11mr1608574wfj.222.1207408601384; Sat, 05 Apr 2008 08:16:41 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Sat, 5 Apr 2008 08:16:41 -0700 (PDT) Message-ID: Date: Sat, 5 Apr 2008 08:16:41 -0700 From: "Vijay Devarapallli" To: "Sri Gundavelli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Sri On Sat, Apr 5, 2008 at 12:10 AM, Sri Gundavelli wrote: > > Ok, got it. I looked at the security considerations section again. I > > forgot that in version 06, we mandate that port 4500 is always used > > for IPsec protected payload traffic, irrespective of whether we use > > vanilla UDP or TLV-header UDP encapsulation. In version 05 and > > earlier, we didn't have this restriction. One could use the TLV-header > > UDP encapsulation (and the DS-MIPv6 port) for the IPsec protected > > payload traffic too. > > I dont follow this. If port 4500 is in use, 3947/3948 considerations > apply. Where does the use of TLV specified ? ESP decapsulation > starts right after UDP header. In version 06, the security considerations section mandates that - For IPsec protected payload traffic, port 4500 is used - For non-IPsec protected payload traffic, the DS-MIPv6 UDP port is used - When the DS-MIPv6 UDP port is used, you have the option of using plain UDP encapsulation or TLV-header UDP encapsulation. That is negotiated with the BU/BAck exchange. Messy, but we have to live with it since we have two different NAT traversal mechanisms (IKEv2 and DS-MIPv6) being used at the same time. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 5 09:14:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7FF28C20B; Sat, 5 Apr 2008 09:14: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 8AE7B3A6E07 for ; Sat, 5 Apr 2008 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.344 X-Spam-Level: X-Spam-Status: No, score=-5.344 tagged_above=-999 required=5 tests=[AWL=1.255, 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 SSyUaxpAd8iV for ; Sat, 5 Apr 2008 09:14:14 -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 63AB93A6DF7 for ; Sat, 5 Apr 2008 09:14:14 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2008 09:14:23 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id m35GENb5020331; Sat, 5 Apr 2008 09:14:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m35GENMG029330; Sat, 5 Apr 2008 16:14:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 09:14:22 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 09:14:18 -0700 From: "Sri Gundavelli" To: "'Vijay Devarapallli'" References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> Date: Sat, 5 Apr 2008 09:14:00 -0700 Message-ID: <002301c89738$1c0c25a0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciXMAzb17nnDVr2SYu7IupjN4aDdgABhoYg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 05 Apr 2008 16:14:22.0538 (UTC) FILETIME=[1C185AA0:01C89738] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1717; t=1207412063; x=1208276063; c=relaxed/simple; s=sjdkim6002; 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]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=Y1/92wM+nYzq8egZHYh5gmEBR95klH2JOOvxLnp4pbg=; b=kqn24gA9yXQ4b+uZXyVY5qV/R2J87fHCeXdKPIP/KYI2bHx7dFGwobVCVK SqXFPijBCMINJuCJri/FUPw0VvVUaDIQjaHBbs+uwhHoeyNdyvpNuobZexOK jrJuAO4hF9; Authentication-Results: sj-dkim-6; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, > > I dont follow this. If port 4500 is in use, 3947/3948 > considerations > > apply. Where does the use of TLV specified ? ESP decapsulation > > starts right after UDP header. > > In version 06, the security considerations section mandates that > > - For IPsec protected payload traffic, port 4500 is used > - For non-IPsec protected payload traffic, the DS-MIPv6 UDP > port is used > - When the DS-MIPv6 UDP port is used, you have the option of using > plain UDP encapsulation or TLV-header UDP encapsulation. That is > negotiated with the BU/BAck exchange. > Ok. So, this is what I said last week (see below) ..Use of two ports 4500 when using ESP and DSMIP6 port when using TLV (offcourse when not using TLV as well) and when ESP is not in use. This allows one to use GRE encap in all modes, secure or non-secure and for IPv4 or IPv6 payload traffic. The comment was that "3948 is not used for IPv6", ...what in this will not work ? Cannot carry IPv6 traffic over port 4500 ? If there is no issue here, we all are on the same page. --- > Sent: Thursday, April 03, 2008 2:44 PM > From: Sri Gundavelli > ... > ... > So, we assume 3948 scheme is in use and since ESP has the > semantics to identify the contained types ... > > IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500. > IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port. > > This is ok. > =>[Hesham] Not really, 3948 is not used for IPv6, so we can't assume that for > all cases. > --- > Messy, but we have to live with it since we have two different NAT > traversal mechanisms (IKEv2 and DS-MIPv6) being used at the same time. > I understand. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 5 09:16:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E5228C2C4; Sat, 5 Apr 2008 09:16: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 6CB003A6BC2 for ; Sat, 5 Apr 2008 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=1.176, 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 oNZ5zAPCkE1H for ; Sat, 5 Apr 2008 09:16:41 -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 6E1D328C2E8 for ; Sat, 5 Apr 2008 09:16:31 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2008 09:16:40 -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 m35GGebL016797; Sat, 5 Apr 2008 09:16:40 -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 m35GGeAg024449; Sat, 5 Apr 2008 16:16:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 09:16:39 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 09:16:39 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> Date: Sat, 5 Apr 2008 09:16:39 -0700 Message-ID: <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciW94CtjX377zpwQ7uYKsxaFLi+LgAQJ4gw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 05 Apr 2008 16:16:39.0584 (UTC) FILETIME=[6DC7EA00:01C89738] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=863; t=1207412200; x=1208276200; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=z8uc2557ekvUBVvycBGk9UcyJtBOWG99tv1hypjhWHE=; b=ogvnWOOrr8M5c510rhLhwTV7yoBNQWy1qxkDw+XLud9vARTEHHVX9N/xdb 2XYletvDRc5IRSC3t6+CEt9ts2JDUAd264NgzIiGX+Tfq4486UXwf93uhyzw 3JAnYlzZMB; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Saturday, April 05, 2008 1:32 AM > To: Sri Gundavelli > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [MEXT] TLV header in DSMIP > > > > > I can provide the text, if there is agreement that we are using > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > > what is the port number that is in use. 4500 or the DSMIP port ? > > => I don't think we need the text now, there is agreement to remove > this. > We're using 4500 for secure traffic and DSMIP port for other traffic. > Ok. I've no issue using 4500 when using ESP and DSMIP port for non-ESP traffic. Offcourse, we could have just used DSMIP port and relied on one NAT traversal mechanism ... Sri > Hesham > > > > > > > Sri > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Apr 6 13:44:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F0D3A6A72; Sun, 6 Apr 2008 13:44: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 83A823A685B for ; Sun, 6 Apr 2008 13:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.962 X-Spam-Level: * X-Spam-Status: No, score=1.962 tagged_above=-999 required=5 tests=[AWL=-1.895, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_62=0.6, RCVD_BAD_ID=2.837, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImEC3uOqq00R for ; Sun, 6 Apr 2008 13:44:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 03CD03A6A72 for ; Sun, 6 Apr 2008 13:43:59 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (123.44.217.87.dynamic.jazztel.es [87.217.44.123])by smtp02.uc3m.es (Postfix) with ESMTP id 3132134A27D; Sun, 6 Apr 2008 22:44:09 +0200 (CEST) Message-ID: <47F7B224.9040808@it.uc3m.es> Date: Sat, 05 Apr 2008 19:08:52 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext , Julien Laganier X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-28.3405 TC:02 TRN:92 TV:5.0.1023(15834.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] IETF71 minutes 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, please find the minutes attached, let me know if you want changes Mobility EXTensions for IPv6 (MEXT) Minutes for IETF-71 meeting ==================================== Chairs: Julien Laganier Marcelo Bagnulo Braun Scribes: Gerardo Giaretta Sri Gundavelli Suresh Krishnan Sessions: WEDNESDAY, March 12, 2008 0900-1130 Morning Session I THURSDAY, March 13, 2008 0900-1130 Morning Session I Minutes: - Status of MEXT deliverables Chairs DSMIPv6: dealing with Pasi's comments. Still outstanding comments. Last changes can be done when the revision is done for IESG MCoA: new version after George's comments. New WGLC AAA goals: new ID needed. After that send to IESG RO for Personal Mobile Router: no WG draft yet. There is a possible candidate but comments and reviews must be needed RO for automobile: new draft accepted as WG item. Need more comments RO for aircraft: finished the WGLC but good shape and the group can start working on solutions PD for NEMO: ongoing discussion to be discussed today Solution for aircraft RO: work on solutions starts now RADIUS MIPv6: new version to be discussed today Analysis of use of MCoA: Monami6 document updated long time ago. No input for now. Input needed. It deals also with multiple HoAs Multiple Interfaces motivations and scenario: Monami6 document. Review needed. Situation similar of the previous document. Mobile IPv6 operation with firewalls: no WG item but output of a DT. To be discussed today MIB for NEMO: WGLC after IETF Flow/Binding Policy: draft by Hesham accepted as a WG item. Still waiting for the draft which will be available at the next IETF Flow Binding policy format: no WG item yet. Two drafts should be merged. Update of RFC 3775: several comments in the mailing list. A compilation of all proposed items to be discussed today. Home Agent reliability: authors say the document is ready. Most comments received were editorial. The document will be updated o Recharter items under discussion One item needs more discussion, which is the p2p home link model. - Home Link operation over p2p links draft-sarikaya-mext-homelink-prefix-delegation-00.txt Bechet Prefix Management issue when the p2p link is a home link CFG_REQUEST triggers DHCP signaling Francis, Julien and Gerardo: no protocol work. How the HA gets the prefixes is up to the deployment or the system architecture. Frank: p2p model implies that there is a prefix per MN while in the shared link there is an address per MN Tom Taylor: people need to work on the problem and expose better the problem to the WG - MIPv6 home link operation in various SDOs draft-devarapalli-mext-mipv6-home-link-00.txt Vijay Jouni presents the slides on behalf of Vijay. MIPv6 used in other SDOs with some links designated as home links. Booting up in a p2p link which is supposed to be the home link needs some considerations Hesham, Gerardo clarified that the home link detection is done comparing the IKEv2 prefix and RA prefix George: an informational document which explains how to do this without requiring new protocol work Hesham: OK with an Information document but no need for changes Julien clarified that there is a p2p link which handles the routing. There is no state at the HA, so the "HA" is just acting as AR and sends the downlink packets to the MN Gerardo: no need for service selection in the BU as there are already solutions in the p2p link negotiation George and Suresh: no need for protocol work, probably worth clarifying Gerardo: an informational document describing how IKEv2 MIP6_HOME_PREFIX is used to detect the home link. No specific Jouni: no protocol work. Ahmad: problem statement needs clarification. Raj: the scenario is not clear and should be discussed in the mailing list George: write a charter paragraph which describes what the problem is and discuss it in the mailing list Next Step: George proposal o MEXT Deliverables - Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-06.txt Ryuji Several comments after the WGLC on version 5 3 remaining issues. WGLC on version 7 after this IETF Sequence Number issue. Proposal: MN should manage the SN value for all bindings Enhanced RO: not clear if MCoA works with this. Additional review needed Simultaneous Home and Foreign attachment: HA intercepts all packets and decides to send the traffic directly to HoA on link or tunnel to CoA. MN sets the H bit in the BID option for the interface in the home link Julien: to get the L2 addresses, ND must be used and L2 headers should not be considered for this purpose Sri: how the packet is sent via the home link? Ryuji: MN sends traffic to the HA George: this is not modifying the proxy ND but some special treatment is needed Ryuji: MN is not defending the address on the home link Sri: take this offline to check SN issue is solved. Enhanced RO: review needed Simultaneous Home and Foreign attachment: text needed and then discuss on the list - Automotive Industry Requirements for NEMO Route Optimization draft-ietf-mext-nemo-ro-automotive-req-00 Roberto Baldessari RO scenarios Requirements - separability: switching to RO is subject to policy table to avoid unnecessary RO sessions - security: MNP ownership should be checked against off-path attackers. Requirement to be extended for better protection. Certificates can be used Marcelo, Hesham: saying there is a certificate assumes already a solution Julien: proof of ownership of the prefix may be a good wording Francis: authorization of prefix is better than proof of ownership - privacy protection. Exposing MNP must be limited to CE and nodes on the path MR-CE Julien: privacy is not the right term as HNP does not give information of privacy Marcelo: if you use a prefix to figure out how many times one is in a foreign link, you have a privacy issue Requirement will be rephrased - multihoming - efficient signaling. Text in the draft is outdated - switching HA. Considered in ISO CALM. RO should not prevent it from working Marcelo: is this related to multiple HoAs? Not clear. Needs to find out if it is different HoAs or not William: is this for reliability of the HA or for the RO? Marcelo: whatever RO solution it must be compatible with HA reliability solutions - NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks draft-ietf-mext-aero-reqs-01 Wesley Eddy Believed to be ready for WGLC Changed requirement on loss to also require NOT duplicting packets Biggest change in Security Requirement Old was IPsec MUST be usable New requirement is clearer. Hesham: why is it safe to assume trust relationship between MR and mobility anchor points topologically near to CNs? Alex: Was it considered RO neighbor correspondent nodes? It seems not desirable. Marcelo: the solution can work with both CN and a box nearby. The security requirements for this are stronger than the 3775 RO. No on-path attackers are accepted. Alex: this deserves further discussion on the list Fred: interactions between the global routing and RO. Global RO may not have a direct route. Can RO survive? One or two packets may be lost, one being the BU Wesley: BU may not go through but you can still use the HoA Marcelo: there is a scalability requirement to not cope with global routing Fred: need a couple of weeks to look at this Marcelo: we need to close this re document in the short term Alex: need to empahasize that session continuity is provided via RO Next Steps: document is in good shape. Comment on the next two weeks. A new version will be produced. - DHCPv6 Relay Agents and NEMO draft-dupont-mext-dhcrelay-00.txt Francis Dupont Francis thinks neither of them can get consensus and that is why we need a solution with relays. He Talks about the advantages of these Francis has implemented DHCP code twice and know that relays are small and straightforward. Putting relays at two ends is a nice way of encapsulating dhcp traffic. He thinks it is a nice way of getting consensus Julien points out that only one of the proposals uses DHCP Francis says the other one can use a DHCP message piggybacked on a BU/BA Julien does not see the point in optimizing PD. It happens rarely and not on critical path George mentions that the good thing about this proposal is that there is no need to do any protocol work. He thinks that the draft is unclear but can be fixed Sri wants to compare this to the Thubert/Droms draft Alex thinks the diff b/w this doc and the Thubert/Droms draft is the encapsulation of the DHCP packets. He is not sure it can work Francis is aware of someone who uses this. Alex agrees that it is worth exploring as a solution Behcet discussed this on monday at DHC Ralph mentioned that this requires standardization. Behcet posted 2 drafts on this issue and he seeks comments Julien wants to know about the security of this mechanism Francis mentions it is just like DHCP (no security). He mentions the DHCP auth option Alex mentions that multicast and anycast are hard to secure Francis mentions you can use IPsec Ryuji wants to know how to configure the DHCP server on the relay Francis mentions there is a list of servers configured on the relay You can use an anycast scope (all servers and relays>ll scope) Francis believes it is good to put a relay or a server on the HA Ryuji says that the main diff between the Thubert/Droms doc is if we put the relay on the MR. Maybe we can update the T/D doc. Fred Templin is working on colocating the relay and server the same node in autoconf Teco Boot agrees to update the T/D doc and then try to get consensus Sri wants to know what happens after the tunnel disappears. How does the DHCP relay work? Will the DHCP packets get routed to HA Behcet thinks that the tunnel vanishes after the MR returns home George wants to mention that once you deregister from the HA the prefixes obtained from DHCP are gone. Sri and George to discuss this later on the ML. Sri wants to couple the eventual solution to the mobility signaling Marcelo wants to know if the nemo pd draft can use the contents of this draft to fix these issues? Alex supports both the proposals. He thinks we are going too fast for the market and it is too early to choose. Hence we can take our time. Alex wants a list of solutions instead of just one. Marcelo wants to pick just one. Teco thinks that if the DHCP has to disappear with the tunnel, then the DHCP PD is not an option. Francis mentions the DHCP release message Jari confirms Marcelo's view that we can do only one solution. if we cannot decide we should do nothing. He wants to see some direction from wg Behcet agrees with Jari but the authors are not present. TJ (through Ryuji) wants to know why we cannot use dynamic dns for mobility? Francis thinks DHCP PD should be based on DHCPv6 Julien thinks PD entails state keeping in the DHCP server. there is no choice George mentions that DHCP-pd is used over lte, pmip and dsmip links Consensus for DHCPv6 prefix delegation - to be confirmed in the mailing list. Votes: 26 votes support for using DHCP based approah/ 2 votes support BU based approach - Guidelines for firewall vendors regarding MIPv6 traffic draft-krishnan-mip6-firewall-vendor-03 Guidelines for firewall administrators regarding MIPv6 traffic draft-krishnan-mip6-firewall-admin-03 All - 15 min Nobody has read them Marcelo gives the room 10 minutes to read and comment Henrik wants to reduce timeout for the state from 420 sec to something more reasonable Jari thinks that the document is talking about generic IPv6 issues as well. He wants to scope down the document and remove these things. Marcelo and Sri want one document (not -admin and -vendor) Suresh disagrees with them. He thinks the audience for the two documents is different and hence they should be separate. Henrik agrees with Suresh. It makes the documents clear and concise. He thinks vendors like concise documents like the firewall-vendor draft. Sri thinks it can be a section inside the combined document. Henrik wants a smaller document focussed at SOHO router vendors Jari thinks the merge/split document is not the right discussions. He wants to discuss next steps Marcelo wants to address Jari's comments to pull out general ipv6 stuff from doc and then ask for adoption - RADIUS Mobile IPv6 Support draft-ietf-mip6-radius-04.txt Kuntal Radius MIP6 support skipped since there is nobody to present - RFC 3775 update Chairs - 15 min DHAAD removal issue Jari wants to see if the functionality has been implemented and used if it is not, it is fine to remove Gerardo thinks that we are removing something that has been outdated by other work (e.g. bootstrapping work) Jari thinks we need to also judge future interest Alex knows about 2 implementations of dhaad Alex thinks the scenarios for bootstrapping are different than those for dhaad He wants to know if diameter has outdated radius, has ikev2 outdated ikev2 Gerardo clarifies that he did not mean bootstrap work was more advanced but it is more adopted and used Charlie wants this discussion to be done on ml Sri has an implementation and does not want to remove George agrees with sri to keep it but he wants the security implications to be clarified Jean-Michel mentiones IKEv1 is obsoleted by IKEv2 Alex does not care and thinks people will still use IKEv1 Jari thinks there is support to keep in the doc Marcelo wants to have some diff text about the security issues Sri wants to leverage existing text Alex mentions there is already language in rfc3775 Jean-Michel sent some text to ML and Alex agrees with it BA/Berr sent by HA Alex and Ryuji think HAs can already send BRR/Berr Jari thinks that binding errors can be sent by both HAs and CNs. He also thinks that this was the intent and the text in RFC3775 is unclear about the term CN Jari and Alex need to agree about BRRs Deng Hui needs clarification since he faced the problem with HA switch messages Returning home Sri agrees to switch SHOULD to MUST George wants to keep the SHOULD. He wants the capability to decide when to send Sri and Jari mention it is a MUST when the node wants to start using its home address The chairs will accept new issues for 3 months and then try to close them Henrik wants all the issues to be tracked in the issue tracker o New Charter Items - Binding Revocation for IP Mobility Ahmad Muhanna presented by Sri Jari has reviewd the document and is fairly in a solid shape. However, the document is written with more focus on the usecases. Authors must publish the new document and fix it Sri agrees that the document needs to be restructured, says that the authors planned to define the mechanism in a generic way and list some examples at the end - Generic Notification Message for Mobile IPv6 Sri Henrik asks why this draft is not listing the most obvious example that is Revocation use case in the examples for this mechanism and why there is a seperate draft for Revocation Sri answers that we dont specify receiver action in generic notification mechanism Revocation requires specification on the event peer and requires more focus. Sri mentions that also, notification mechanism provides a generic container for all events. We should not use up the MH number space for every event and so we need to define a number space for one MH type. Sri mentions that some people suggested that the revocation mechanism should make use of the number space from the notification draft Gerardo says that then it is ok if Revocation uses one of the sub-type - Virtual Home Link configuration for Mobile IPv6 Sri Hesham thinks anycast is no different in v6 than in v4. He thinks the only difference is a reserved prefix in v6 for link specific anycast Ryuji mentions that rfc3775 assumes that prefix is a /64 Vijay thinks that there is a specific prefix reserved for DHAAD anycast Suresh mentions that it is a reserved interface identifier and not a prefix Discussion to continue on list Acee wants to know if this doc will be informational Sri thinks so - Extend DSMIPv6 Home Network Support George Domagoj wants to know about the usage scenarios. e.g. v4 HoA as the CoA for the v6 HoA o Other topics - Alt-CoA check draft-arkko-mext-rfc3775-altcoa-check-01.txt Jari Hesham is neutral to this change it is good because this can be enabled and disabled on the receiver based on the info in the BU Jari mentions that text changes needed to FMIP and have been made Jari mentions fmip has a more specific rule for alt-coa handling FMIP Ryuji mentions that MCOA does not use Alt-CoA and so there is no conflict b/w this proposal and monami6 work but Jari thinks the problem still exists Do we trust the node to just check one of the addresses in the packet? He has not thought much about this yet Sri wants to know if there is a configuration knob Jari mentions that it is tuned on by default but can be turned off Ryuji wants to mention whether the src address or alt-coa will be used by the HA Christian wants some kind of negotiation between the HA and the MN to see if it is turned on Jari does not like to have negotiation George mentions there is no point negotiating with a potential attacker Alex wants more granularity (per HoA basis) Jari wants to take some time to see if we can accomodate the mcoa stuff in this doc within say 3 months - Residual threat analysis draft-haddad-mext-mip6-residual-threats-01.txt Geroge George solicits more inputs on threats Francis thinks attacks are very easy if we are attached to multiple links (at least one of the valid CoAs is used) Julien wants to know how CGA helps Suresh mentions that it prevents flooding a specific address but not flooding a link Jean-Michel wants to know if the work takes into account the work done in sava/savi Marcelo wants to document the threats first and then decide what to do with them later. The scope of the work is threats that are SPECIFIC to mipv6 Hesham wants to know about ingress filtering stats George mentions that we can create optional mechanisms that only paranoid people turn on Christian Vogt mentions 25% of internet addresses can be spoofed and savi wg is more limited only source address validation on local link Francis mentions that there are attacks that do not use source addresses and they cannot be covered by ingress filtering Marcelo wants to cover all cases not just CoA address issues Jari wants to focus the document without making huge claims Jari mentions that the relationship between the HA and Mn is traceable. Anonymous HAs would be a good idea but they do not exist George mentions that the device can be traced, but not the user e.g. SIM Jari mentions that a SIM can be traced to a user George says not in Europe Jean-Michel says that is not true in France George says we will not do this for France. (laughter) Jari mentions that this work might have an effect on MCOA and hence we need to analyze the effects - Simultaneous Mobility Problem Statement draft-wong-mext-simultaneous-ps-00.txt D. Wong Hesham wants to know whether we are documenting or trying to solve Francis mentions that rh + hao as suggested is worse than tunneling and is a security nightmare Suresh mentions that he and Wassim had a draft 4 years ago that dealt with the same issue and there was no interest in solving it. It was called Binding Update Backhauling. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Apr 6 21:12:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE863A6B2F; Sun, 6 Apr 2008 21:12: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 69A683A6E57 for ; Sun, 6 Apr 2008 21:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=1.107, 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 gx0lmSxvSzM0 for ; Sun, 6 Apr 2008 21:12: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 9B6C03A6B2F for ; Sun, 6 Apr 2008 21:12:20 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2008 21:12:33 -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 m374CXUb026224; Sun, 6 Apr 2008 21:12:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m374CXL0006811; Mon, 7 Apr 2008 04:12:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 21:12:32 -0700 Received: from sgundavewxp ([10.21.92.127]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 21:12:31 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> Date: Sun, 6 Apr 2008 21:12:23 -0700 Message-ID: <003a01c89865$980851a0$7f89680a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciW94CtjX377zpwQ7uYKsxaFLi+LgBaWkLA In-Reply-To: X-OriginalArrivalTime: 07 Apr 2008 04:12:32.0517 (UTC) FILETIME=[9A231B50:01C89865] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2001; t=1207541553; x=1208405553; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=q8Ek9JmPgjbINCBZCxTGmjKz9DSWM8QHnrB7KehIyiA=; b=Ds/F00TJElP6hebGvtKadxcp5u0Th8wgleSsJDRJd7lmLUOY91fNlBMe6V BJ3gSAaSr31EQjrjjd13Xa2S7wOQb0v3CMdS6OVYlMJdFaI0zaoEYHPX1lGt rKt0hkKn68; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Hesham, Also, can you please clarify the operation for this below scenarioe. We are updating our PMIP6 IPv4 document and we are not clear how this scenario works, in liu of the latest DSMIP6 resolutions. Some clarifications will help. When ESP is used only for control traffic and not for data traffic, how does the NAT traversal scheme work ? The NAT mappings for both the flows are different, howz the relation maintained ? My Assumption: IPv4 transport in use, NAT in path and the resolution that the port 4500 is used for secure ESP traffic and for non secure traffic DSMIP port is used. Operation: =========== - MN sends MIP BU encapsulated in UDP to port 4500 - NAT binding is created on the NAT device, having a relation to src port of the BU, port 4500, IPv4-private-coa, IPv4-public-coa and HA-V4-Address - HA creates a tunnel with UDP encap and with the above properties (Src/Dest ports) - If MN or HA needs to forward data traffic and unprotected, does it needs to be sent to port 4500 or DSMIP port ? We cannot send non-ESP traffic to port 4500. - If this is sent to DSMIP port, what triggers the new NAT mapping and howz the tunnel encap header modified on the HA ? - How do keepalives work ? Appreciate your time on this. Regards Sri > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Saturday, April 05, 2008 1:32 AM > To: Sri Gundavelli > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [MEXT] TLV header in DSMIP > > > > > I can provide the text, if there is agreement that we are using > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > > what is the port number that is in use. 4500 or the DSMIP port ? > > => I don't think we need the text now, there is agreement to remove > this. > We're using 4500 for secure traffic and DSMIP port for other traffic. > > Hesham > > > > > > > Sri > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 02:37:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A96F3A6E7A; Mon, 7 Apr 2008 02:37: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 7135D3A6C3E for ; Mon, 7 Apr 2008 02:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 v1fLaRKRGh1e for ; Mon, 7 Apr 2008 02:37:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 992CF3A6E50 for ; Mon, 7 Apr 2008 02:37:27 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 79ED820475; Mon, 7 Apr 2008 11:37:39 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-1f-47f9eb6335a9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B08A207C3; Mon, 7 Apr 2008 11:37:39 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 11:37:38 +0200 Received: from [147.214.130.9] ([147.214.130.9]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 11:37:38 +0200 Message-ID: <47F9EB62.2050807@ericsson.com> Date: Mon, 07 Apr 2008 11:37:38 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: marcelo bagnulo References: <47F7B224.9040808@it.uc3m.es> In-Reply-To: <47F7B224.9040808@it.uc3m.es> X-OriginalArrivalTime: 07 Apr 2008 09:37:38.0796 (UTC) FILETIME=[04C912C0:01C89893] X-Brightmail-Tracker: AAAAAA== Cc: Julien Laganier , mext Subject: Re: [MEXT] IETF71 minutes 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, marcelo bagnulo wrote: > Flow Binding policy format: no WG item yet. Two drafts should be merged. > We have merged draft-larsson-monami6-filter-rules and draft-mitsuya-monami6-flow-distribution-policy and submitted it as draft-larsson-mext-flow-distribution-rules. This was done in November 2007. /Conny _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 03:06:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588003A6C44; Mon, 7 Apr 2008 03:06: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 F24023A6AA2 for ; Mon, 7 Apr 2008 03:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.161 X-Spam-Level: X-Spam-Status: No, score=-5.161 tagged_above=-999 required=5 tests=[AWL=1.438, 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 3t7uH8kUCnNo for ; Mon, 7 Apr 2008 03:05:58 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A3EC23A6A1F for ; Mon, 7 Apr 2008 03:05:57 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m37A61CZ023156; Mon, 7 Apr 2008 13:06:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:06:03 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:06:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 13:06:01 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> In-Reply-To: <003a01c89865$980851a0$7f89680a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] TLV header in DSMIP thread-index: AciW94CtjX377zpwQ7uYKsxaFLi+LgBaWkLAAAykEXA= References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> From: To: X-OriginalArrivalTime: 07 Apr 2008 10:06:02.0524 (UTC) FILETIME=[FC4955C0:01C89896] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 BTW, I've stated several times that I believe that an average implementor (i.e., someone who hasn't participated in writing this specification and doesn't have a PhD) can't actually figure out how the DSMIPv6/IPsec interaction works based on the current spec (which is already in much better shape than earlier versions). I do understand that Hesham as the editor cannot (and should not) fix this alone -- so I would really appreciate if other WG members would help with writing the needed text. I've suggested e.g. showing packets (both before and after IPsec processing) with their headers to show what traffic is sent from/to which port (and how IPsec interacts with this). In particular, "using 4500 for secure traffic and DSMIP port for other traffic" is *not* what the current spec says. Could someone from the WG volunteer to produce those packet diagrams, and propose improved text around those diagrams? (My apologies for being blunt, but I'd rather see this fixed before the draft comes to IESG -- remember that the ADs who have to ballot "Yes" or "No objection" mostly haven't participated in writing this spec, and don't have PhDs.) Best regards, Pasi > -----Original Message----- > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: 07 April, 2008 07:12 > To: 'Hesham Soliman' > Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: RE: [MEXT] TLV header in DSMIP > > Hi Hesham, > > Also, can you please clarify the operation for this > below scenarioe. We are updating our PMIP6 IPv4 document > and we are not clear how this scenario works, in liu of > the latest DSMIP6 resolutions. Some clarifications will > help. > > When ESP is used only for control traffic and not for data > traffic, how does the NAT traversal scheme work ? The NAT > mappings for both the flows are different, howz the relation > maintained ? > > My Assumption: IPv4 transport in use, NAT in path and > the resolution that the port 4500 is used for secure > ESP traffic and for non secure traffic DSMIP port is > used. > > Operation: > =========== > - MN sends MIP BU encapsulated in UDP to port 4500 > > - NAT binding is created on the NAT device, having a > relation to src port of the BU, port 4500, IPv4-private-coa, > IPv4-public-coa and HA-V4-Address > > - HA creates a tunnel with UDP encap and with the above > properties (Src/Dest ports) > > - If MN or HA needs to forward data traffic and unprotected, > does it needs to be sent to port 4500 or DSMIP port ? > We cannot send non-ESP traffic to port 4500. > > - If this is sent to DSMIP port, what triggers the new NAT > mapping and howz the tunnel encap header modified on the HA ? > > - How do keepalives work ? > > Appreciate your time on this. > > > Regards > Sri > > > > -----Original Message----- > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > Sent: Saturday, April 05, 2008 1:32 AM > > To: Sri Gundavelli > > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > > Subject: Re: [MEXT] TLV header in DSMIP > > > > > > > > I can provide the text, if there is agreement that we are using > > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > > > what is the port number that is in use. 4500 or the DSMIP port ? > > > > => I don't think we need the text now, there is agreement > > to remove this. We're using 4500 for secure traffic and DSMIP port > > for other traffic. > > > > Hesham > > > > > > > > > > > Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 03:10:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72B03A6D05; Mon, 7 Apr 2008 03:10: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 510DC3A6CDF for ; Mon, 7 Apr 2008 03:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.184 X-Spam-Level: X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[AWL=1.415, 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 P0P9HBUyjg8X for ; Mon, 7 Apr 2008 03:10:42 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 293CF3A6BEB for ; Mon, 7 Apr 2008 03:10:41 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m37AAoOo021011; Mon, 7 Apr 2008 13:10:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:10:47 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:10:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 13:10:45 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB724DBD7C@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] TLV header in DSMIP thread-index: AciWVIz+6OX4KdVYTmKwVPRRwly3YQCQnrfg References: <1696498986EFEC4D9153717DA325CB7247F106@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 07 Apr 2008 10:10:47.0603 (UTC) FILETIME=[A634F030:01C89897] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Well... I can't say that I like it, but it probably works. And none of the other solutions (like adding a new DSMIPv6 specific payload to IKE, or running a separate copy of IKE/IPsec for DSMIPv6) were very good either. Best regards, Pasi > -----Original Message----- > From: ext George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: 04 April, 2008 16:05 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: dvijay@gmail.com; hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] TLV header in DSMIP > > Pasi, you describe this as the way it is ...but do you have a problem > with that and why? > > Thanks > George > > On Fri, Apr 4, 2008 at 10:42 AM, wrote: > > Vijay Devarapallli wrote: > > > > > Without this, you end up using UDP port 4500 for IPsec protected > > > data traffic between the mobile node and the home agent and the > > > DS-MIPv6 UDP port for non-IPsec protected data traffic > > > between the > > > mobile node and the home agent. I would prefer to avoid this. > > > > In the current spec (version -01) this is precisely the situation: > > traffic protected with IPsec tunnel mode uses port 4500. > > > > (BU/BAck is protected with transport mode IPsec, but in that case, > > the packet also has an IPv6 header, so the TLV-Header type would > > be IPv6.) > > > > Best regards, > > Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 04:14:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928063A6A5E; Mon, 7 Apr 2008 04:14: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 BF5413A6AA7 for ; Mon, 7 Apr 2008 04:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=1.636, 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 CC5aOfIUyjVH for ; Mon, 7 Apr 2008 04:13:51 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DEA6A3A6AA1 for ; Mon, 7 Apr 2008 04:13:50 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (dummyhost11.it.uc3m.es [163.117.139.62])by smtp03.uc3m.es (Postfix) with ESMTP id E175E373B75; Mon, 7 Apr 2008 13:14:01 +0200 (CEST) Message-ID: <47FA01F9.1050100@it.uc3m.es> Date: Mon, 07 Apr 2008 13:14:01 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Conny Larsson References: <47F7B224.9040808@it.uc3m.es> <47F9EB62.2050807@ericsson.com> In-Reply-To: <47F9EB62.2050807@ericsson.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.8965 TC:1F TRN:11 TV:5.0.1023(15834.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: Julien Laganier , mext Subject: Re: [MEXT] IETF71 minutes 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, if people can comment on this new merged draft we can try to figure = out what would be the next steps for this Regards, marcelo Conny Larsson escribi=F3: > Hi Marcelo, > > marcelo bagnulo wrote: >> Flow Binding policy format: no WG item yet. Two drafts should be merged. >> = > We have merged draft-larsson-monami6-filter-rules and = > draft-mitsuya-monami6-flow-distribution-policy and submitted it as = > draft-larsson-mext-flow-distribution-rules. This was done in November = > 2007. > > /Conny > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 04:26:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BAD28C0F8; Mon, 7 Apr 2008 04:26: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 C30593A6830 for ; Mon, 7 Apr 2008 04:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, 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 nF6CmwFJvNVy for ; Mon, 7 Apr 2008 04:25:57 -0700 (PDT) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by core3.amsl.com (Postfix) with ESMTP id A0B3028C0E6 for ; Mon, 7 Apr 2008 04:25:41 -0700 (PDT) Received: from nskntotgx03p.mx.bigpond.com ([124.190.105.201]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20080407112553.SXXZ649.nskntmtas02p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Mon, 7 Apr 2008 11:25:53 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20080407112550.SULH9173.nskntotgx03p.mx.bigpond.com@[192.168.0.187]>; Mon, 7 Apr 2008 11:25:50 +0000 Message-Id: From: Hesham Soliman To: In-Reply-To: <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 21:25:28 +1000 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 > BTW, I've stated several times that I believe that an average > implementor (i.e., someone who hasn't participated in writing this > specification and doesn't have a PhD) can't actually figure out how > the DSMIPv6/IPsec interaction works based on the current spec > (which is already in much better shape than earlier versions). => Actually that comment was on an older version but feel free to make it now again :) > > > I do understand that Hesham as the editor cannot (and should not) > fix this alone -- so I would really appreciate if other WG members > would help with writing the needed text. > > I've suggested e.g. showing packets (both before and after IPsec > processing) with their headers to show what traffic is sent from/to > which port (and how IPsec interacts with this). In particular, > "using 4500 for secure traffic and DSMIP port for other traffic" > is *not* what the current spec says. => George and Wassim have volunteered to do this, thanks guys. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 04:27:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B308C3A6A55; Mon, 7 Apr 2008 04:27: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 CDB393A681D for ; Mon, 7 Apr 2008 04:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=1.605, 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 P17r2fLRhDZO for ; Mon, 7 Apr 2008 04:26:56 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 047BF3A69E1 for ; Mon, 7 Apr 2008 04:26:56 -0700 (PDT) Received: from dummyhost11.it.uc3m.es (dummyhost11.it.uc3m.es [163.117.139.62])by smtp01.uc3m.es (Postfix) with ESMTP id 72192538AA2; Mon, 7 Apr 2008 13:27:07 +0200 (CEST) Message-ID: <47FA050B.2010001@it.uc3m.es> Date: Mon, 07 Apr 2008 13:27:07 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext , Sri Gundavelli , Julien Laganier X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.3085 TC:1F TRN:10 TV:5.0.1023(15834.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] WGLC on draft-ietf-mext-nemo-mib-00 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 are now starting the WGLC for draft-ietf-mext-nemo-mib-00, which will close on april 21st 2008. Please, send comments to the list before that date. For your convenience, the document can be found: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-00.txt Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 04:31:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075A53A68A3; Mon, 7 Apr 2008 04:31: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 C72223A6A40 for ; Mon, 7 Apr 2008 04:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.826, 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 WAzqF67IIqh0 for ; Mon, 7 Apr 2008 04:31:04 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id CF1AC3A6825 for ; Mon, 7 Apr 2008 04:31:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1401328wfa.31 for ; Mon, 07 Apr 2008 04:31:13 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AjBxm6TIhFxT45ZzVpjtJoknnUj7Bo3qREs16yq3cAw=; b=EYlmAxRGOD8LwzWLytlKQ0GcVDqKAVxsMK+SphqSox9zVlBIzJNX76BKmp+Pl3nSW/+35EbtsRm9A1Gw/OZn8d/GOYCp/mlvmhHp3kmKYDh13AC63kdvMsX13prGFwkQxJK1nRx46043R39IYu3+8iPmgAfcUN8hLPkOsrJ35E4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=fha/IRXYIiW9axzf49adnfioCb+b8bImkT3Kylr1uopY2I/jgwuk1trmyF9hwAoRB9Abyou03KFZy6bK4AB8HaG2AFHX0HlgxCd0rh3UdUVcyUuMNFlOdQgvF/+wzxxCDsfid4l1LckM0mDBa+tx1Hq4X6/MywGbe+JJmRN0Y4k= Received: by 10.143.33.19 with SMTP id l19mr2373484wfj.18.1207567873549; Mon, 07 Apr 2008 04:31:13 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Mon, 7 Apr 2008 04:31:13 -0700 (PDT) Message-ID: Date: Mon, 7 Apr 2008 12:31:13 +0100 From: "George Tsirtsis" To: "Hesham Soliman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Well, I have volunteered and indicated that Wassim will probably help, but have not asked him yet :-) Note that I am not convinced that diagrams are really appropriate for the packet descriptions...I will have to look at that. In any case the idea is to provide clear description of packet headers before and after IPSEC processing in various cases. Regards George On Mon, Apr 7, 2008 at 12:25 PM, Hesham Soliman wrote: > > > BTW, I've stated several times that I believe that an average > > implementor (i.e., someone who hasn't participated in writing this > > specification and doesn't have a PhD) can't actually figure out how > > the DSMIPv6/IPsec interaction works based on the current spec > > (which is already in much better shape than earlier versions). > > => Actually that comment was on an older version but feel free to make > it now again :) > > > > > > > > I do understand that Hesham as the editor cannot (and should not) > > fix this alone -- so I would really appreciate if other WG members > > would help with writing the needed text. > > > > I've suggested e.g. showing packets (both before and after IPsec > > processing) with their headers to show what traffic is sent from/to > > which port (and how IPsec interacts with this). In particular, > > "using 4500 for secure traffic and DSMIP port for other traffic" > > is *not* what the current spec says. > > => George and Wassim have volunteered to do this, thanks guys. > > Hesham > > > > > _______________________________________________ > 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 Apr 7 07:56:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F033A6BC8; Mon, 7 Apr 2008 07:56: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 C7F9A3A6B94 for ; Mon, 7 Apr 2008 07:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=1.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 Fkm4hj0G-zRD for ; Mon, 7 Apr 2008 07:55:57 -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 B841628C3A6 for ; Mon, 7 Apr 2008 07:55:37 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2008 07:55:51 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m37Etpad024520; Mon, 7 Apr 2008 07:55:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m37EtpP7008424; Mon, 7 Apr 2008 14:55:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 07:55:51 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 07:55:50 -0700 From: "Sri Gundavelli" To: References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> Date: Mon, 7 Apr 2008 07:55:50 -0700 Message-ID: <002d01c898bf$78844910$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciW94CtjX377zpwQ7uYKsxaFLi+LgBaWkLAAAykEXAACny+kA== In-Reply-To: <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> X-OriginalArrivalTime: 07 Apr 2008 14:55:50.0892 (UTC) FILETIME=[788FBAC0:01C898BF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4895; t=1207580151; x=1208444151; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=KlMnxTpOTYVRRYG1zLLJwp3fK42g1pPfK5DKecPLgaY=; b=jXiOzvPRe6NYn886ZNPMY4Cm7RlUbd/LwZj85ZllY7wlq86FHKdK0rTOXt RPItxymq9a94j2FhTee22iuBY6HSM8UioyIHENQTNI0Gxdue2BZM7RaUJ3MC spLlQ8kMDt; 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] TLV header in DSMIP 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 how the NAT traversal scheme works if only control traffic is enabled for IPsec protection and not the data traffic. 3775 clearly allows this and is probably the most default mechanism given the crypto hardware accelerator requirements on the boxes. In this scenario of MN using a private address and behind a NAT, there will be two NAT flows and not sure how they are tied. This is not an issue in 3775, a secured MIP control packets result in a L3 tunnel and its optional if ESP is enabled on that tunnel for data traffic. Given the port 4500 for ESP only traffic, not sure how non-ESP traffic can be sent there. Especially the initial packets from CN to MN, when there is no NAT mapping for that flow ... May be I'm missing some thing basic ... if this is already discussed and worked out ...some clarifications or pointers to the draft will help ... Sri > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, April 07, 2008 3:06 AM > To: sgundave@cisco.com > Cc: mext@ietf.org > Subject: RE: [MEXT] TLV header in DSMIP > > > BTW, I've stated several times that I believe that an average > implementor (i.e., someone who hasn't participated in writing this > specification and doesn't have a PhD) can't actually figure out how > the DSMIPv6/IPsec interaction works based on the current spec > (which is already in much better shape than earlier versions). > > I do understand that Hesham as the editor cannot (and should not) > fix this alone -- so I would really appreciate if other WG members > would help with writing the needed text. > > I've suggested e.g. showing packets (both before and after IPsec > processing) with their headers to show what traffic is sent from/to > which port (and how IPsec interacts with this). In particular, > "using 4500 for secure traffic and DSMIP port for other traffic" > is *not* what the current spec says. > > Could someone from the WG volunteer to produce those packet diagrams, > and propose improved text around those diagrams? > > (My apologies for being blunt, but I'd rather see this fixed before > the draft comes to IESG -- remember that the ADs who have to ballot > "Yes" or "No objection" mostly haven't participated in writing this > spec, and don't have PhDs.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: 07 April, 2008 07:12 > > To: 'Hesham Soliman' > > Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: RE: [MEXT] TLV header in DSMIP > > > > Hi Hesham, > > > > Also, can you please clarify the operation for this > > below scenarioe. We are updating our PMIP6 IPv4 document > > and we are not clear how this scenario works, in liu of > > the latest DSMIP6 resolutions. Some clarifications will > > help. > > > > When ESP is used only for control traffic and not for data > > traffic, how does the NAT traversal scheme work ? The NAT > > mappings for both the flows are different, howz the relation > > maintained ? > > > > My Assumption: IPv4 transport in use, NAT in path and > > the resolution that the port 4500 is used for secure > > ESP traffic and for non secure traffic DSMIP port is > > used. > > > > Operation: > > =========== > > - MN sends MIP BU encapsulated in UDP to port 4500 > > > > - NAT binding is created on the NAT device, having a > > relation to src port of the BU, port 4500, IPv4-private-coa, > > IPv4-public-coa and HA-V4-Address > > > > - HA creates a tunnel with UDP encap and with the above > > properties (Src/Dest ports) > > > > - If MN or HA needs to forward data traffic and unprotected, > > does it needs to be sent to port 4500 or DSMIP port ? > > We cannot send non-ESP traffic to port 4500. > > > > - If this is sent to DSMIP port, what triggers the new NAT > > mapping and howz the tunnel encap header modified on the HA ? > > > > - How do keepalives work ? > > > > Appreciate your time on this. > > > > > > Regards > > Sri > > > > > > > -----Original Message----- > > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > > Sent: Saturday, April 05, 2008 1:32 AM > > > To: Sri Gundavelli > > > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > > > Subject: Re: [MEXT] TLV header in DSMIP > > > > > > > > > > > I can provide the text, if there is agreement that we are using > > > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > > > > what is the port number that is in use. 4500 or the DSMIP port ? > > > > > > => I don't think we need the text now, there is agreement > > > to remove this. We're using 4500 for secure traffic and > DSMIP port > > > for other traffic. > > > > > > Hesham > > > > > > > > > > > > > > > Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 08:57:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F1C3A6BE5; Mon, 7 Apr 2008 08:57: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 BA9F43A6B7F for ; Mon, 7 Apr 2008 08:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=0.783, 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 IcbafEHc1k9m for ; Mon, 7 Apr 2008 08:57:03 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 84B9E3A67D4 for ; Mon, 7 Apr 2008 08:57:03 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1524504wfa.31 for ; Mon, 07 Apr 2008 08:57:16 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=50Z0XMWGXeJ3VEixlLvvuF2c6rBBdabVZreuxaHUZ+s=; b=mSm6+ww8Tj0FaITJ9Twvl8IuTZNvvyi6XlHacK3l+E3Tf906prxROmPhsgsjHgkviusoavyxX5WIW2obCzM/DjUpZPWcs7A7DZN2gB1h/EQkIJDSELjw21W0QI7tbfpMh+l5MhVduv2t6NPhmZBBZnFyjsyqG+pGOJkSinadK9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=O6Km9siHl4RKQBpKCQuYVk3/F2pJxtS8Plod/QxXQQ/smdnhNUIyuf3Rnpnjg8utGfPh6FtsioTpPYdek0J323hQiTST55Z7HvXkP2zA+ljYbctJQWjC+JEfiDvrBELKbZvG0egWrFGDWj3gVu7Evh6OwY3AICjI7IZ6kOdy+Q4= Received: by 10.142.200.20 with SMTP id x20mr1142539wff.269.1207583836321; Mon, 07 Apr 2008 08:57:16 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Mon, 7 Apr 2008 08:57:14 -0700 (PDT) Message-ID: Date: Mon, 7 Apr 2008 16:57:14 +0100 From: "George Tsirtsis" To: "Sri Gundavelli" In-Reply-To: <002d01c898bf$78844910$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Sri, In the case you describe, why do you think the two flows must be tied in some fashion? From IPSEC perspective only one flow is secured, so the other flow (tunneled data) is irrelevant. Tunneled data are then sent with unsecured UDP encapsulation using the DSMIPv6 port number, as defined in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP Did I miss the point of your question? Regards George On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli wrote: > I'm not sure how the NAT traversal scheme works if only > control traffic is enabled for IPsec protection and > not the data traffic. 3775 clearly allows this and is > probably the most default mechanism given the crypto > hardware accelerator requirements on the boxes. In this > scenario of MN using a private address and behind a NAT, > there will be two NAT flows and not sure how they are > tied. > This is not an issue in 3775, a secured MIP control > packets result in a L3 tunnel and its optional if ESP > is enabled on that tunnel for data traffic. Given the port > 4500 for ESP only traffic, not sure how non-ESP traffic > can be sent there. Especially the initial packets from CN > to MN, when there is no NAT mapping for that flow ... > > May be I'm missing some thing basic ... if this is already > discussed and worked out ...some clarifications or pointers > to the draft will help ... > > Sri > > > > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Monday, April 07, 2008 3:06 AM > > To: sgundave@cisco.com > > Cc: mext@ietf.org > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > BTW, I've stated several times that I believe that an average > > implementor (i.e., someone who hasn't participated in writing this > > specification and doesn't have a PhD) can't actually figure out how > > the DSMIPv6/IPsec interaction works based on the current spec > > (which is already in much better shape than earlier versions). > > > > I do understand that Hesham as the editor cannot (and should not) > > fix this alone -- so I would really appreciate if other WG members > > would help with writing the needed text. > > > > I've suggested e.g. showing packets (both before and after IPsec > > processing) with their headers to show what traffic is sent from/to > > which port (and how IPsec interacts with this). In particular, > > "using 4500 for secure traffic and DSMIP port for other traffic" > > is *not* what the current spec says. > > > > Could someone from the WG volunteer to produce those packet diagrams, > > and propose improved text around those diagrams? > > > > (My apologies for being blunt, but I'd rather see this fixed before > > the draft comes to IESG -- remember that the ADs who have to ballot > > "Yes" or "No objection" mostly haven't participated in writing this > > spec, and don't have PhDs.) > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: 07 April, 2008 07:12 > > > To: 'Hesham Soliman' > > > Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > Hi Hesham, > > > > > > Also, can you please clarify the operation for this > > > below scenarioe. We are updating our PMIP6 IPv4 document > > > and we are not clear how this scenario works, in liu of > > > the latest DSMIP6 resolutions. Some clarifications will > > > help. > > > > > > When ESP is used only for control traffic and not for data > > > traffic, how does the NAT traversal scheme work ? The NAT > > > mappings for both the flows are different, howz the relation > > > maintained ? > > > > > > My Assumption: IPv4 transport in use, NAT in path and > > > the resolution that the port 4500 is used for secure > > > ESP traffic and for non secure traffic DSMIP port is > > > used. > > > > > > Operation: > > > =========== > > > - MN sends MIP BU encapsulated in UDP to port 4500 > > > > > > - NAT binding is created on the NAT device, having a > > > relation to src port of the BU, port 4500, IPv4-private-coa, > > > IPv4-public-coa and HA-V4-Address > > > > > > - HA creates a tunnel with UDP encap and with the above > > > properties (Src/Dest ports) > > > > > > - If MN or HA needs to forward data traffic and unprotected, > > > does it needs to be sent to port 4500 or DSMIP port ? > > > We cannot send non-ESP traffic to port 4500. > > > > > > - If this is sent to DSMIP port, what triggers the new NAT > > > mapping and howz the tunnel encap header modified on the HA ? > > > > > > - How do keepalives work ? > > > > > > Appreciate your time on this. > > > > > > > > > Regards > > > Sri > > > > > > > > > > -----Original Message----- > > > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > > > Sent: Saturday, April 05, 2008 1:32 AM > > > > To: Sri Gundavelli > > > > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > > > > Subject: Re: [MEXT] TLV header in DSMIP > > > > > > > > > > > > > > I can provide the text, if there is agreement that we are using > > > > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on > > > > > what is the port number that is in use. 4500 or the DSMIP port ? > > > > > > > > => I don't think we need the text now, there is agreement > > > > to remove this. We're using 4500 for secure traffic and > > DSMIP port > > > > for other traffic. > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > 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 Apr 7 09:10:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8728028C3FB; Mon, 7 Apr 2008 09:10: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 D200528C219 for ; Mon, 7 Apr 2008 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.991, 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 eaal2ZqfhGto for ; Mon, 7 Apr 2008 09:10:55 -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 3906E28C270 for ; Mon, 7 Apr 2008 09:10:55 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2008 09:11:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m37GB9pW007353; Mon, 7 Apr 2008 09:11:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m37GB9r6007320; Mon, 7 Apr 2008 16:11:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:11:08 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:11:08 -0700 From: "Sri Gundavelli" To: "'George Tsirtsis'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> Date: Mon, 7 Apr 2008 09:11:07 -0700 Message-ID: <003401c898c9$fd297460$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciYyBCiRfi9QNa/TrWq7HqxTd9B6gAACXjg In-Reply-To: X-OriginalArrivalTime: 07 Apr 2008 16:11:08.0574 (UTC) FILETIME=[FD4F4BE0:01C898C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7103; t=1207584669; x=1208448669; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=4H9/n8ZnLMX571HNpYCPL18N6rSLnLl5JCLKzOhuCz4=; b=squgw4KPZeIZ1mZWst877u+MJP3W7utedObdqCmSynVrjs5Oc/IrJwFgor orSQxQ+keOq4X0v1a8J36a/Q9yTv11wk0kwyzOk9dnIvf4VSj3/lGV1SB74l P4+Z5V9UEC; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 George, > Hi Sri, > > In the case you describe, why do you think the two flows must be tied > in some fashion? > > From IPSEC perspective only one flow is secured, so the other flow > (tunneled data) is irrelevant. Tunneled data are then sent with > unsecured UDP encapsulation using the DSMIPv6 port number, as defined > in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP > After the signaling is complete, there should be tunnel encaps with proper UDP port numbers on both ends for sending the data traffic. If we treat them separate, how does the HA know what encap to use for the initial traffic comming from the CN towards the MN (Note that the signaling is complete and there is a NAT state for the signaling flow and no data traffic yet from the MN and so there is no NAT state for the second flow). MN is behind a NAT and so the trigger needs to come from the MN for the second flow. Secondly, if the two flows are not tied, how does keepalive messaging work for keeping the NAT states active ? Will there be two NAT keepalive messaging for both the flows ? Also, the two flows needs to be tied for removing the data path upon terminating the MIP session. Thanks Sri > Did I miss the point of your question? > > Regards > George > > On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli > wrote: > > I'm not sure how the NAT traversal scheme works if only > > control traffic is enabled for IPsec protection and > > not the data traffic. 3775 clearly allows this and is > > probably the most default mechanism given the crypto > > hardware accelerator requirements on the boxes. In this > > scenario of MN using a private address and behind a NAT, > > there will be two NAT flows and not sure how they are > > tied. > > This is not an issue in 3775, a secured MIP control > > packets result in a L3 tunnel and its optional if ESP > > is enabled on that tunnel for data traffic. Given the port > > 4500 for ESP only traffic, not sure how non-ESP traffic > > can be sent there. Especially the initial packets from CN > > to MN, when there is no NAT mapping for that flow ... > > > > May be I'm missing some thing basic ... if this is already > > discussed and worked out ...some clarifications or pointers > > to the draft will help ... > > > > Sri > > > > > > > > > > > > > -----Original Message----- > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > Sent: Monday, April 07, 2008 3:06 AM > > > To: sgundave@cisco.com > > > Cc: mext@ietf.org > > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > > > > BTW, I've stated several times that I believe that an average > > > implementor (i.e., someone who hasn't participated in > writing this > > > specification and doesn't have a PhD) can't actually > figure out how > > > the DSMIPv6/IPsec interaction works based on the current spec > > > (which is already in much better shape than earlier versions). > > > > > > I do understand that Hesham as the editor cannot (and should not) > > > fix this alone -- so I would really appreciate if other > WG members > > > would help with writing the needed text. > > > > > > I've suggested e.g. showing packets (both before and after IPsec > > > processing) with their headers to show what traffic is > sent from/to > > > which port (and how IPsec interacts with this). In particular, > > > "using 4500 for secure traffic and DSMIP port for other traffic" > > > is *not* what the current spec says. > > > > > > Could someone from the WG volunteer to produce those > packet diagrams, > > > and propose improved text around those diagrams? > > > > > > (My apologies for being blunt, but I'd rather see this > fixed before > > > the draft comes to IESG -- remember that the ADs who > have to ballot > > > "Yes" or "No objection" mostly haven't participated in > writing this > > > spec, and don't have PhDs.) > > > > > > Best regards, > > > Pasi > > > > > > > -----Original Message----- > > > > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: 07 April, 2008 07:12 > > > > To: 'Hesham Soliman' > > > > Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > > > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > > > Hi Hesham, > > > > > > > > Also, can you please clarify the operation for this > > > > below scenarioe. We are updating our PMIP6 IPv4 document > > > > and we are not clear how this scenario works, in liu of > > > > the latest DSMIP6 resolutions. Some clarifications will > > > > help. > > > > > > > > When ESP is used only for control traffic and not for data > > > > traffic, how does the NAT traversal scheme work ? The NAT > > > > mappings for both the flows are different, howz the relation > > > > maintained ? > > > > > > > > My Assumption: IPv4 transport in use, NAT in path and > > > > the resolution that the port 4500 is used for secure > > > > ESP traffic and for non secure traffic DSMIP port is > > > > used. > > > > > > > > Operation: > > > > =========== > > > > - MN sends MIP BU encapsulated in UDP to port 4500 > > > > > > > > - NAT binding is created on the NAT device, having a > > > > relation to src port of the BU, port 4500, IPv4-private-coa, > > > > IPv4-public-coa and HA-V4-Address > > > > > > > > - HA creates a tunnel with UDP encap and with the above > > > > properties (Src/Dest ports) > > > > > > > > - If MN or HA needs to forward data traffic and unprotected, > > > > does it needs to be sent to port 4500 or DSMIP port ? > > > > We cannot send non-ESP traffic to port 4500. > > > > > > > > - If this is sent to DSMIP port, what triggers the new NAT > > > > mapping and howz the tunnel encap header modified on the HA ? > > > > > > > > - How do keepalives work ? > > > > > > > > Appreciate your time on this. > > > > > > > > > > > > Regards > > > > Sri > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > > > > Sent: Saturday, April 05, 2008 1:32 AM > > > > > To: Sri Gundavelli > > > > > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > > > > > Subject: Re: [MEXT] TLV header in DSMIP > > > > > > > > > > > > > > > > > I can provide the text, if there is agreement that > we are using > > > > > > DSMIP port and the TLV-ESP follows the UDP. I'm > bit confused, on > > > > > > what is the port number that is in use. 4500 or > the DSMIP port ? > > > > > > > > > > => I don't think we need the text now, there is agreement > > > > > to remove this. We're using 4500 for secure traffic and > > > DSMIP port > > > > > for other traffic. > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > 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 Apr 7 09:29:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA53D28C386; Mon, 7 Apr 2008 09:29: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 1DB8228C35B for ; Mon, 7 Apr 2008 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=0.743, 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 Kjl6JrqEbsK5 for ; Mon, 7 Apr 2008 09:29:29 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id B094628C386 for ; Mon, 7 Apr 2008 09:29:29 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1540464wfa.31 for ; Mon, 07 Apr 2008 09:29:43 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l9BCSZTBjij6i/aoo67KpI72iuVSoQ/erXChPuJRQss=; b=VvX4eN4xxqIQhV2uod1Amf3OibNv6Po55oZ4JWXafvruGWhq3034h6meDBZd1yzz3EO2ouTSDyQWq/lFclL2YaVuh/ADSO7b50dWnkUiAO3bbkk4DHLZ+V2/4yVLlHR5YRq121o0kwRiH6/6h3nYKJQEhO2uEmSQZ4tSpAypakE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=gxrjLl+QK5hZR9yM5cNzbV/b8SgsPUOPNi5qSXhTrDcSUyf8JTH9tPnQ6e3R/ubzfvriU11Bd3j4nyR/zAjFPCM0W7kBb/ZNzAKjbF9Rey8N70nQ+cpVdpXMd2wlGYjDH3um2NwTXkA6OLUDkGCeuc3i87drUZ9tiEAqdGgwBbA= Received: by 10.142.148.7 with SMTP id v7mr2559246wfd.218.1207585783304; Mon, 07 Apr 2008 09:29:43 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Mon, 7 Apr 2008 09:29:43 -0700 (PDT) Message-ID: Date: Mon, 7 Apr 2008 17:29:43 +0100 From: "George Tsirtsis" To: "Sri Gundavelli" In-Reply-To: <003401c898c9$fd297460$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> <003401c898c9$fd297460$d4f6200a@amer.cisco.com> Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 again ...inline... On Mon, Apr 7, 2008 at 5:11 PM, Sri Gundavelli wrote: > Hi George, > > > > > > > Hi Sri, > > > > In the case you describe, why do you think the two flows must be tied > > in some fashion? > > > > From IPSEC perspective only one flow is secured, so the other flow > > (tunneled data) is irrelevant. Tunneled data are then sent with > > unsecured UDP encapsulation using the DSMIPv6 port number, as defined > > in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP > > > > After the signaling is complete, there should be tunnel encaps > with proper UDP port numbers on both ends for sending the data > traffic. If we treat them separate, how does the HA know what > encap to use for the initial traffic comming from the CN towards > the MN (Note that the signaling is complete and there is a NAT > state for the signaling flow and no data traffic yet from the > MN and so there is no NAT state for the second flow). MN is > behind a NAT and so the trigger needs to come from the MN for > the second flow. > GT> Yes, which means that the MN must immediately start sending keepalives for the data traffic i.e., to the DSMIPv6 port number. This allows the tunnel to be open for outgoing as well as incomming sessions. The draft has language to this effect already. > Secondly, if the two flows are not tied, how does keepalive > messaging work for keeping the NAT states active ? Will there be > two NAT keepalive messaging for both the flows ? > GT> If both of the flows need to be maintained then I think we need two keepalives. It is not clear to me, however, why we need to maintain the signaling flow in that case, since we might not have to send another BU for hours; or am I missing something? GT> In any case the cost of two keepalives is probably lower than the cost of turning on encryption which then only requires a single keepalive. Also note that sending two keepalives is not that bad for the MN since most of the cost of keepalives is in the fact that the MN must come out of sleep mode to transmit something. Once the MN wakes up, transmitting one vs two small packets makes little difference. There is of course processing cost at the HA side to consider too. > Also, the two flows needs to be tied for removing the data path > upon terminating the MIP session. > GT> Yes I think they are still tied in the HA based on the HoA, no? BR, George > > > > > > > > Did I miss the point of your question? > > > > Regards > > George > > > > On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli > > wrote: > > > I'm not sure how the NAT traversal scheme works if only > > > control traffic is enabled for IPsec protection and > > > not the data traffic. 3775 clearly allows this and is > > > probably the most default mechanism given the crypto > > > hardware accelerator requirements on the boxes. In this > > > scenario of MN using a private address and behind a NAT, > > > there will be two NAT flows and not sure how they are > > > tied. > > > This is not an issue in 3775, a secured MIP control > > > packets result in a L3 tunnel and its optional if ESP > > > is enabled on that tunnel for data traffic. Given the port > > > 4500 for ESP only traffic, not sure how non-ESP traffic > > > can be sent there. Especially the initial packets from CN > > > to MN, when there is no NAT mapping for that flow ... > > > > > > May be I'm missing some thing basic ... if this is already > > > discussed and worked out ...some clarifications or pointers > > > to the draft will help ... > > > > > > Sri > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > > Sent: Monday, April 07, 2008 3:06 AM > > > > To: sgundave@cisco.com > > > > Cc: mext@ietf.org > > > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > > > > > > > BTW, I've stated several times that I believe that an average > > > > implementor (i.e., someone who hasn't participated in > > writing this > > > > specification and doesn't have a PhD) can't actually > > figure out how > > > > the DSMIPv6/IPsec interaction works based on the current spec > > > > (which is already in much better shape than earlier versions). > > > > > > > > I do understand that Hesham as the editor cannot (and should not) > > > > fix this alone -- so I would really appreciate if other > > WG members > > > > would help with writing the needed text. > > > > > > > > I've suggested e.g. showing packets (both before and after IPsec > > > > processing) with their headers to show what traffic is > > sent from/to > > > > which port (and how IPsec interacts with this). In particular, > > > > "using 4500 for secure traffic and DSMIP port for other traffic" > > > > is *not* what the current spec says. > > > > > > > > Could someone from the WG volunteer to produce those > > packet diagrams, > > > > and propose improved text around those diagrams? > > > > > > > > (My apologies for being blunt, but I'd rather see this > > fixed before > > > > the draft comes to IESG -- remember that the ADs who > > have to ballot > > > > "Yes" or "No objection" mostly haven't participated in > > writing this > > > > spec, and don't have PhDs.) > > > > > > > > Best regards, > > > > Pasi > > > > > > > > > -----Original Message----- > > > > > From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: 07 April, 2008 07:12 > > > > > To: 'Hesham Soliman' > > > > > Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > > > > > Subject: RE: [MEXT] TLV header in DSMIP > > > > > > > > > > Hi Hesham, > > > > > > > > > > Also, can you please clarify the operation for this > > > > > below scenarioe. We are updating our PMIP6 IPv4 document > > > > > and we are not clear how this scenario works, in liu of > > > > > the latest DSMIP6 resolutions. Some clarifications will > > > > > help. > > > > > > > > > > When ESP is used only for control traffic and not for data > > > > > traffic, how does the NAT traversal scheme work ? The NAT > > > > > mappings for both the flows are different, howz the relation > > > > > maintained ? > > > > > > > > > > My Assumption: IPv4 transport in use, NAT in path and > > > > > the resolution that the port 4500 is used for secure > > > > > ESP traffic and for non secure traffic DSMIP port is > > > > > used. > > > > > > > > > > Operation: > > > > > =========== > > > > > - MN sends MIP BU encapsulated in UDP to port 4500 > > > > > > > > > > - NAT binding is created on the NAT device, having a > > > > > relation to src port of the BU, port 4500, IPv4-private-coa, > > > > > IPv4-public-coa and HA-V4-Address > > > > > > > > > > - HA creates a tunnel with UDP encap and with the above > > > > > properties (Src/Dest ports) > > > > > > > > > > - If MN or HA needs to forward data traffic and unprotected, > > > > > does it needs to be sent to port 4500 or DSMIP port ? > > > > > We cannot send non-ESP traffic to port 4500. > > > > > > > > > > - If this is sent to DSMIP port, what triggers the new NAT > > > > > mapping and howz the tunnel encap header modified on the HA ? > > > > > > > > > > - How do keepalives work ? > > > > > > > > > > Appreciate your time on this. > > > > > > > > > > > > > > > Regards > > > > > Sri > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > > > > > Sent: Saturday, April 05, 2008 1:32 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: mext@ietf.org; Pasi.Eronen@nokia.com > > > > > > Subject: Re: [MEXT] TLV header in DSMIP > > > > > > > > > > > > > > > > > > > > I can provide the text, if there is agreement that > > we are using > > > > > > > DSMIP port and the TLV-ESP follows the UDP. I'm > > bit confused, on > > > > > > > what is the port number that is in use. 4500 or > > the DSMIP port ? > > > > > > > > > > > > => I don't think we need the text now, there is agreement > > > > > > to remove this. We're using 4500 for secure traffic and > > > > DSMIP port > > > > > > for other traffic. > > > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 Apr 7 09:31:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928F93A6C79; Mon, 7 Apr 2008 09:31: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 93AF73A6B42 for ; Mon, 7 Apr 2008 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 L2MWn67ZH8ty for ; Mon, 7 Apr 2008 09:31:07 -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 D505A28C462 for ; Mon, 7 Apr 2008 09:30:58 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so759879and.122 for ; Mon, 07 Apr 2008 09:31: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:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=Yy5NfppsKDX9h0Hqtr/77DGgJocTW/FkiAE8Z7+rbc8=; b=O0PZWFWTMDPdrpSkC9KOMvPzQncsJXKVxHayGoRxbj8ZYaZw71FKn5IJ4f/Fl8WPAQE6VH+rc+HGX3SJlj08psR2mgnJMm/mP2QPjsb5Jay6e/IBT6D/N3O1mb3MXMaubdPgHx6Qc1bMI35Mw5L4LBMMOus+Msytx9jxkR2VGlg= 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=VZ/qIhResYw+M2nflocXR8pyghssVZJcnsDGmPlriHmBHb5TcIt/AV33C9cgVbf64WiLM/G+IDtgUAbLB2+ItzLuApeWtu+PRgIwFytUynj/7PKPyaNIlnsr61Xy/rjJwyja/9/dDJ2l1FfaXAnWS74hhzm7gzpFxBGRAecluyU= Received: by 10.100.47.13 with SMTP id u13mr10824730anu.25.1207585871720; Mon, 07 Apr 2008 09:31:11 -0700 (PDT) Received: from ?10.0.1.195? ( [219.110.64.63]) by mx.google.com with ESMTPS id d25sm18515552and.2.2008.04.07.09.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Apr 2008 09:31:10 -0700 (PDT) From: RYUJI WAKIKAWA To: "Sri Gundavelli" In-Reply-To: <003401c898c9$fd297460$d4f6200a@amer.cisco.com> References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> <003401c898c9$fd297460$d4f6200a@amer.cisco.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 01:30:53 +0900 X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Sri, On 2008/04/08, at 1:11, Sri Gundavelli wrote: > Hi George, > >> Hi Sri, >> >> In the case you describe, why do you think the two flows must be tied >> in some fashion? >> >> From IPSEC perspective only one flow is secured, so the other flow >> (tunneled data) is irrelevant. Tunneled data are then sent with >> unsecured UDP encapsulation using the DSMIPv6 port number, as defined >> in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP >> > > After the signaling is complete, there should be tunnel encaps > with proper UDP port numbers on both ends for sending the data > traffic. If we treat them separate, how does the HA know what > encap to use for the initial traffic comming from the CN towards > the MN (Note that the signaling is complete and there is a NAT > state for the signaling flow and no data traffic yet from the > MN and so there is no NAT state for the second flow). MN is > behind a NAT and so the trigger needs to come from the MN for > the second flow. I think this is an issue. After binding registration, MN should trigger some packet to the HA using the DSMIP port in order to create NAT state for non-ESP data flow. Otherwise, NAT box may drop the packets tunneled by HA because there is no NAT state for the UDP packets (DSMIP port). > Secondly, if the two flows are not tied, how does keepalive > messaging work for keeping the NAT states active ? Will there be > two NAT keepalive messaging for both the flows ? DSMIP uses BU/BA exchange for the keepalive. BU/BA will be sent with the 4500 port. We don't have keepalive mechanism for data flow (DSMIP port) in the current spec. regards, ryuji > Also, the two flows needs to be tied for removing the data path > upon terminating the MIP session. > > Thanks > Sri > > > > >> Did I miss the point of your question? >> >> Regards >> George >> >> On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli >> wrote: >>> I'm not sure how the NAT traversal scheme works if only >>> control traffic is enabled for IPsec protection and >>> not the data traffic. 3775 clearly allows this and is >>> probably the most default mechanism given the crypto >>> hardware accelerator requirements on the boxes. In this >>> scenario of MN using a private address and behind a NAT, >>> there will be two NAT flows and not sure how they are >>> tied. >>> This is not an issue in 3775, a secured MIP control >>> packets result in a L3 tunnel and its optional if ESP >>> is enabled on that tunnel for data traffic. Given the port >>> 4500 for ESP only traffic, not sure how non-ESP traffic >>> can be sent there. Especially the initial packets from CN >>> to MN, when there is no NAT mapping for that flow ... >>> >>> May be I'm missing some thing basic ... if this is already >>> discussed and worked out ...some clarifications or pointers >>> to the draft will help ... >>> >>> Sri >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] >>>> Sent: Monday, April 07, 2008 3:06 AM >>>> To: sgundave@cisco.com >>>> Cc: mext@ietf.org >>>> Subject: RE: [MEXT] TLV header in DSMIP >>>> >>>> >>>> BTW, I've stated several times that I believe that an average >>>> implementor (i.e., someone who hasn't participated in >> writing this >>>> specification and doesn't have a PhD) can't actually >> figure out how >>>> the DSMIPv6/IPsec interaction works based on the current spec >>>> (which is already in much better shape than earlier versions). >>>> >>>> I do understand that Hesham as the editor cannot (and should not) >>>> fix this alone -- so I would really appreciate if other >> WG members >>>> would help with writing the needed text. >>>> >>>> I've suggested e.g. showing packets (both before and after IPsec >>>> processing) with their headers to show what traffic is >> sent from/to >>>> which port (and how IPsec interacts with this). In particular, >>>> "using 4500 for secure traffic and DSMIP port for other traffic" >>>> is *not* what the current spec says. >>>> >>>> Could someone from the WG volunteer to produce those >> packet diagrams, >>>> and propose improved text around those diagrams? >>>> >>>> (My apologies for being blunt, but I'd rather see this >> fixed before >>>> the draft comes to IESG -- remember that the ADs who >> have to ballot >>>> "Yes" or "No objection" mostly haven't participated in >> writing this >>>> spec, and don't have PhDs.) >>>> >>>> Best regards, >>>> Pasi >>>> >>>>> -----Original Message----- >>>>> From: ext Sri Gundavelli [mailto:sgundave@cisco.com] >>>>> Sent: 07 April, 2008 07:12 >>>>> To: 'Hesham Soliman' >>>>> Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) >>>>> Subject: RE: [MEXT] TLV header in DSMIP >>>>> >>>>> Hi Hesham, >>>>> >>>>> Also, can you please clarify the operation for this >>>>> below scenarioe. We are updating our PMIP6 IPv4 document >>>>> and we are not clear how this scenario works, in liu of >>>>> the latest DSMIP6 resolutions. Some clarifications will >>>>> help. >>>>> >>>>> When ESP is used only for control traffic and not for data >>>>> traffic, how does the NAT traversal scheme work ? The NAT >>>>> mappings for both the flows are different, howz the relation >>>>> maintained ? >>>>> >>>>> My Assumption: IPv4 transport in use, NAT in path and >>>>> the resolution that the port 4500 is used for secure >>>>> ESP traffic and for non secure traffic DSMIP port is >>>>> used. >>>>> >>>>> Operation: >>>>> =========== >>>>> - MN sends MIP BU encapsulated in UDP to port 4500 >>>>> >>>>> - NAT binding is created on the NAT device, having a >>>>> relation to src port of the BU, port 4500, IPv4-private-coa, >>>>> IPv4-public-coa and HA-V4-Address >>>>> >>>>> - HA creates a tunnel with UDP encap and with the above >>>>> properties (Src/Dest ports) >>>>> >>>>> - If MN or HA needs to forward data traffic and unprotected, >>>>> does it needs to be sent to port 4500 or DSMIP port ? >>>>> We cannot send non-ESP traffic to port 4500. >>>>> >>>>> - If this is sent to DSMIP port, what triggers the new NAT >>>>> mapping and howz the tunnel encap header modified on the HA ? >>>>> >>>>> - How do keepalives work ? >>>>> >>>>> Appreciate your time on this. >>>>> >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: Saturday, April 05, 2008 1:32 AM >>>>>> To: Sri Gundavelli >>>>>> Cc: mext@ietf.org; Pasi.Eronen@nokia.com >>>>>> Subject: Re: [MEXT] TLV header in DSMIP >>>>>> >>>>>>> >>>>>>> I can provide the text, if there is agreement that >> we are using >>>>>>> DSMIP port and the TLV-ESP follows the UDP. I'm >> bit confused, on >>>>>>> what is the port number that is in use. 4500 or >> the DSMIP port ? >>>>>> >>>>>> => I don't think we need the text now, there is agreement >>>>>> to remove this. We're using 4500 for secure traffic and >>>> DSMIP port >>>>>> for other traffic. >>>>>> >>>>>> Hesham >>>>>> >>>>>>> >>>>>>> >>>>>>> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 09:48:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3D33A6E7F; Mon, 7 Apr 2008 09:48: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 0F40D3A6BC1 for ; Mon, 7 Apr 2008 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.941, 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 kypGsulpAw3N for ; Mon, 7 Apr 2008 09:48:42 -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 A9BB33A6E7F for ; Mon, 7 Apr 2008 09:48:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2008 09:48:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m37GmuUK012416; Mon, 7 Apr 2008 09:48:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m37Gmu6f015895; Mon, 7 Apr 2008 16:48:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:48:56 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:48:56 -0700 From: "Sri Gundavelli" To: "'George Tsirtsis'" References: <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> <003401c898c9$fd297460$d4f6200a@amer.cisco.com> Date: Mon, 7 Apr 2008 09:48:55 -0700 Message-ID: <003e01c898cf$44d4fb40$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciYzJwdkzHcJ++GRtOA6ZP0vU0yCwAALBQg In-Reply-To: X-OriginalArrivalTime: 07 Apr 2008 16:48:56.0197 (UTC) FILETIME=[44EB1B50:01C898CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3078; t=1207586936; x=1208450936; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=O/Ui8804PXQiLU7SMXqoXhQPPsqNXE2L8HUHayVzAxc=; b=bupmC1vihuBzFQRovr/mHo8oMxgaGlm5AekudpFX1R0Ig32cQ6FEhtXtK0 oUx4K7hfx2IYrWGKIc2sc3kEJR15vE3W0utRCYo7f2vtvMC8UcbYC1WIsbAd Bf1oRW6xBN; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 > > After the signaling is complete, there should be tunnel encaps > > with proper UDP port numbers on both ends for sending the data > > traffic. If we treat them separate, how does the HA know what > > encap to use for the initial traffic comming from the CN towards > > the MN (Note that the signaling is complete and there is a NAT > > state for the signaling flow and no data traffic yet from the > > MN and so there is no NAT state for the second flow). MN is > > behind a NAT and so the trigger needs to come from the MN for > > the second flow. > > > > GT> Yes, which means that the MN must immediately start sending > keepalives for the data traffic i.e., to the DSMIPv6 port number. This > allows the tunnel to be open for outgoing as well as incomming > sessions. The draft has language to this effect already. > I will take a look at the draft again, I missed this language. Also, requires some text in Security Considerations (quite a bit of text in 3519 related to this, it has the "R" bit support and the HA keeps the tunnel in half-created state .. very similar). Need to understand the implications of this ... > > Secondly, if the two flows are not tied, how does keepalive > > messaging work for keeping the NAT states active ? Will there be > > two NAT keepalive messaging for both the flows ? > > > > GT> If both of the flows need to be maintained then I think we need > two keepalives. It is not clear to me, however, why we need to > maintain the signaling flow in that case, since we might not have to > send another BU for hours; or am I missing something? All along during DSMIP6 discussions, the general though from the Authors was that we dont need a seperate KA mechanism, we can very well use BU/BA and that changes now. If we dont keep the NAT mapping active for the control flow, HA cannot send any asynchronous events such as Revocation or Notification events. > GT> In any case the cost of two keepalives is probably lower than the > cost of turning on encryption which then only requires a single > keepalive. Also note that sending two keepalives is not that bad for > the MN since most of the cost of keepalives is in the fact that the MN > must come out of sleep mode to transmit something. Once the MN wakes > up, transmitting one vs two small packets makes little difference. > There is of course processing cost at the HA side to consider too. > Sure, there needs to be two keepalives. One in control and the other in data plane. I assume the KA for control is still BU/BA ? For data flow, how will this be achieved ? > > Also, the two flows needs to be tied for removing the data path > > upon terminating the MIP session. > > > > GT> Yes I think they are still tied in the HA based on the HoA, no? > HoA is just a route over the tunnel. The tunnel endpoints with src/dest address and port numbers, needs to be reflected in the BCE. Implementation wise, its very difficult to locate a tunnel by looking at the routing table. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 7 09:56:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E303A6A71; Mon, 7 Apr 2008 09:56: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 A70CD3A6C25 for ; Mon, 7 Apr 2008 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.703 X-Spam-Level: X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[AWL=0.896, 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 j2CqyywSKBNr for ; Mon, 7 Apr 2008 09:56:25 -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 677AF3A6939 for ; Mon, 7 Apr 2008 09:56:25 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2008 09:56:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m37Gudij025180; Mon, 7 Apr 2008 09:56:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m37GudHV001818; Mon, 7 Apr 2008 16:56:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:56:39 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 09:56:38 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <003a01c89865$980851a0$7f89680a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com> <002d01c898bf$78844910$d4f6200a@amer.cisco.com> <003401c898c9$fd297460$d4f6200a@amer.cisco.com> Date: Mon, 7 Apr 2008 09:56:38 -0700 Message-ID: <004101c898d0$5880e180$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciYzMz9s/iZrU9NRq6k4chPx4lGrwAAqEWw In-Reply-To: X-OriginalArrivalTime: 07 Apr 2008 16:56:38.0549 (UTC) FILETIME=[58806C50:01C898D0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7753; t=1207587399; x=1208451399; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=oEXSa0hzmpGfGgckyusStIb4GjuZ8avTthQ7UPfRZXQ=; b=Vhbt8pqvxrumMpwzAtiV8BN3FooxyW5jS0jgd5rhjUVQ6uecDoM1LLr3wG 5UtNh5+tYmrq3zlQhKrRXHNWuAwYCxG90e1BSTcAoSmEVNWZ+rJVqv3nqizK qB0R7+a8mG; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, > > > > After the signaling is complete, there should be tunnel encaps > > with proper UDP port numbers on both ends for sending the data > > traffic. If we treat them separate, how does the HA know what > > encap to use for the initial traffic comming from the CN towards > > the MN (Note that the signaling is complete and there is a NAT > > state for the signaling flow and no data traffic yet from the > > MN and so there is no NAT state for the second flow). MN is > > behind a NAT and so the trigger needs to come from the MN for > > the second flow. > > I think this is an issue. > > After binding registration, MN should trigger some packet to the HA > using the > DSMIP port in order to create NAT state for non-ESP data flow. > Otherwise, NAT box may drop the packets tunneled by HA > because there is no NAT state for the UDP packets (DSMIP port). > Implementation wise, I'm not sure ..how this really works on the HA. When and how does it create the UDP tunnel for the data packets ? We always create tunnel encap after control, but, this is after receiving a data packet. > > Secondly, if the two flows are not tied, how does keepalive > > messaging work for keeping the NAT states active ? Will there be > > two NAT keepalive messaging for both the flows ? > > DSMIP uses BU/BA exchange for the keepalive. BU/BA will be sent with > the 4500 port. > We don't have keepalive mechanism for data flow (DSMIP port) in the > current spec. > That will be a problem, if we dont have KA for data flows. Sri > regards, > ryuji > > > Also, the two flows needs to be tied for removing the data path > > upon terminating the MIP session. > > > > Thanks > > Sri > > > > > > > > > >> Did I miss the point of your question? > >> > >> Regards > >> George > >> > >> On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli > >> wrote: > >>> I'm not sure how the NAT traversal scheme works if only > >>> control traffic is enabled for IPsec protection and > >>> not the data traffic. 3775 clearly allows this and is > >>> probably the most default mechanism given the crypto > >>> hardware accelerator requirements on the boxes. In this > >>> scenario of MN using a private address and behind a NAT, > >>> there will be two NAT flows and not sure how they are > >>> tied. > >>> This is not an issue in 3775, a secured MIP control > >>> packets result in a L3 tunnel and its optional if ESP > >>> is enabled on that tunnel for data traffic. Given the port > >>> 4500 for ESP only traffic, not sure how non-ESP traffic > >>> can be sent there. Especially the initial packets from CN > >>> to MN, when there is no NAT mapping for that flow ... > >>> > >>> May be I'm missing some thing basic ... if this is already > >>> discussed and worked out ...some clarifications or pointers > >>> to the draft will help ... > >>> > >>> Sri > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > >>>> Sent: Monday, April 07, 2008 3:06 AM > >>>> To: sgundave@cisco.com > >>>> Cc: mext@ietf.org > >>>> Subject: RE: [MEXT] TLV header in DSMIP > >>>> > >>>> > >>>> BTW, I've stated several times that I believe that an average > >>>> implementor (i.e., someone who hasn't participated in > >> writing this > >>>> specification and doesn't have a PhD) can't actually > >> figure out how > >>>> the DSMIPv6/IPsec interaction works based on the current spec > >>>> (which is already in much better shape than earlier versions). > >>>> > >>>> I do understand that Hesham as the editor cannot (and should not) > >>>> fix this alone -- so I would really appreciate if other > >> WG members > >>>> would help with writing the needed text. > >>>> > >>>> I've suggested e.g. showing packets (both before and after IPsec > >>>> processing) with their headers to show what traffic is > >> sent from/to > >>>> which port (and how IPsec interacts with this). In particular, > >>>> "using 4500 for secure traffic and DSMIP port for other traffic" > >>>> is *not* what the current spec says. > >>>> > >>>> Could someone from the WG volunteer to produce those > >> packet diagrams, > >>>> and propose improved text around those diagrams? > >>>> > >>>> (My apologies for being blunt, but I'd rather see this > >> fixed before > >>>> the draft comes to IESG -- remember that the ADs who > >> have to ballot > >>>> "Yes" or "No objection" mostly haven't participated in > >> writing this > >>>> spec, and don't have PhDs.) > >>>> > >>>> Best regards, > >>>> Pasi > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>> Sent: 07 April, 2008 07:12 > >>>>> To: 'Hesham Soliman' > >>>>> Cc: mext@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > >>>>> Subject: RE: [MEXT] TLV header in DSMIP > >>>>> > >>>>> Hi Hesham, > >>>>> > >>>>> Also, can you please clarify the operation for this > >>>>> below scenarioe. We are updating our PMIP6 IPv4 document > >>>>> and we are not clear how this scenario works, in liu of > >>>>> the latest DSMIP6 resolutions. Some clarifications will > >>>>> help. > >>>>> > >>>>> When ESP is used only for control traffic and not for data > >>>>> traffic, how does the NAT traversal scheme work ? The NAT > >>>>> mappings for both the flows are different, howz the relation > >>>>> maintained ? > >>>>> > >>>>> My Assumption: IPv4 transport in use, NAT in path and > >>>>> the resolution that the port 4500 is used for secure > >>>>> ESP traffic and for non secure traffic DSMIP port is > >>>>> used. > >>>>> > >>>>> Operation: > >>>>> =========== > >>>>> - MN sends MIP BU encapsulated in UDP to port 4500 > >>>>> > >>>>> - NAT binding is created on the NAT device, having a > >>>>> relation to src port of the BU, port 4500, IPv4-private-coa, > >>>>> IPv4-public-coa and HA-V4-Address > >>>>> > >>>>> - HA creates a tunnel with UDP encap and with the above > >>>>> properties (Src/Dest ports) > >>>>> > >>>>> - If MN or HA needs to forward data traffic and unprotected, > >>>>> does it needs to be sent to port 4500 or DSMIP port ? > >>>>> We cannot send non-ESP traffic to port 4500. > >>>>> > >>>>> - If this is sent to DSMIP port, what triggers the new NAT > >>>>> mapping and howz the tunnel encap header modified on the HA ? > >>>>> > >>>>> - How do keepalives work ? > >>>>> > >>>>> Appreciate your time on this. > >>>>> > >>>>> > >>>>> Regards > >>>>> Sri > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>>>>> Sent: Saturday, April 05, 2008 1:32 AM > >>>>>> To: Sri Gundavelli > >>>>>> Cc: mext@ietf.org; Pasi.Eronen@nokia.com > >>>>>> Subject: Re: [MEXT] TLV header in DSMIP > >>>>>> > >>>>>>> > >>>>>>> I can provide the text, if there is agreement that > >> we are using > >>>>>>> DSMIP port and the TLV-ESP follows the UDP. I'm > >> bit confused, on > >>>>>>> what is the port number that is in use. 4500 or > >> the DSMIP port ? > >>>>>> > >>>>>> => I don't think we need the text now, there is agreement > >>>>>> to remove this. We're using 4500 for secure traffic and > >>>> DSMIP port > >>>>>> for other traffic. > >>>>>> > >>>>>> Hesham > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 03:47:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A846328C17B; Tue, 8 Apr 2008 03:47: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 0EFE33A68AA for ; Tue, 8 Apr 2008 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.207 X-Spam-Level: X-Spam-Status: No, score=-5.207 tagged_above=-999 required=5 tests=[AWL=1.392, 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 S66Affi-GOtX for ; Tue, 8 Apr 2008 03:47:40 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 511243A6A8C for ; Tue, 8 Apr 2008 03:47:40 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m38An5RA031931; Tue, 8 Apr 2008 05:50:08 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 13:47:38 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 13:47:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 13:47:36 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB724DC948@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] TLV header in DSMIP thread-index: AciYzOXTEAXCRe0RSlu3y/VQsfWBJQAmLqZw References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com><001e01c89604$15134880$d4f6200a@amer.cisco.com><05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com><000001c896ec$f8e64d30$d4f6200a@amer.cisco.com><003a01c89865$980851a0$7f89680a@amer.cisco.com><1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com><002d01c898bf$78844910$d4f6200a@amer.cisco.com><003401c898c9$fd297460$d4f6200a@amer.cisco.com> From: To: X-OriginalArrivalTime: 08 Apr 2008 10:47:38.0319 (UTC) FILETIME=[F64F2DF0:01C89965] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 RYUJI WAKIKAWA wrote: > DSMIP uses BU/BA exchange for the keepalive. BU/BA will be sent with > the 4500 port. We don't have keepalive mechanism for data flow > (DSMIP port) in the current spec. No, in the current draft BU/BAck is sent over the DSMIPv6 port, not 4500. (And yes, the draft is extremely difficult to understand here, and needs to be much more understandable before it has any chance of being approved...) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 06:14:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0511028C248; Tue, 8 Apr 2008 06:14: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 D784F3A67F6 for ; Tue, 8 Apr 2008 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, 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 r78J5T+a7u4j for ; Tue, 8 Apr 2008 06:14:33 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 015F73A6BEC for ; Tue, 8 Apr 2008 06:14:32 -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 1JjDew-0007NX-7B; Tue, 08 Apr 2008 23:14:46 +1000 Message-Id: From: Hesham Soliman To: Sri Gundavelli In-Reply-To: <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 23:12:35 +1000 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 06/04/2008, at 2:16 AM, Sri Gundavelli wrote: > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Saturday, April 05, 2008 1:32 AM >> To: Sri Gundavelli >> Cc: mext@ietf.org; Pasi.Eronen@nokia.com >> Subject: Re: [MEXT] TLV header in DSMIP >> >>> >>> I can provide the text, if there is agreement that we are using >>> DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on >>> what is the port number that is in use. 4500 or the DSMIP port ? >> >> => I don't think we need the text now, there is agreement to remove >> this. >> We're using 4500 for secure traffic and DSMIP port for other traffic. >> > > > Ok. I've no issue using 4500 when using ESP and DSMIP port for non-ESP > traffic. Offcourse, we could have just used DSMIP port and relied on > one NAT traversal mechanism ... => I guess we didn't think of that! Please read the discussions on IKE and DSMIP. We can't do what you're suggesting and the best way to find out why is to read those threads, look for pasi's emails on the list, it doesn't cover the private discussions but it shows why we need both. Hesham > > > Sri > > >> Hesham >> >>> >>> >>> Sri >>> >>> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 07:28:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A42528C1D9; Tue, 8 Apr 2008 07:28: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 1E51A3A6BFA for ; Tue, 8 Apr 2008 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.856, 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 ekv3gyPbhqXP for ; Tue, 8 Apr 2008 07:28: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 496CB3A6B47 for ; Tue, 8 Apr 2008 07:28:22 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2008 07:28:38 -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 m38EScXA003294; Tue, 8 Apr 2008 07:28:38 -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 m38ESccM025848; Tue, 8 Apr 2008 14:28:38 GMT Date: Tue, 8 Apr 2008 07:28:38 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1460; t=1207664918; x=1208528918; 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]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=ny72AUAPoKeJPYUB3NfYgdLGyeG7jas+o9C9A37P7oM=; b=Cghc7tQTjJWYJ+qeEydlnjF0fD3A5F3IhfYik/N1iGZmFI7QfN0dzECDuI 2CY912K1wphkQyEeiXl2NI1Djd4LphofuKUY4kSi++BsQNRMZBbbc8fqcX5i yqlhJ1Y4gW; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 can provide the text, if there is agreement that we are using >> > > DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on >> > > what is the port number that is in use. 4500 or the DSMIP port ? >> > >> > => I don't think we need the text now, there is agreement to remove >> > this. >> > We're using 4500 for secure traffic and DSMIP port for other traffic. >> > >> >> >> Ok. I've no issue using 4500 when using ESP and DSMIP port for non-ESP >> traffic. Offcourse, we could have just used DSMIP port and relied on >> one NAT traversal mechanism ... > > => I guess we didn't think of that! Please read the discussions on IKE and > => DSMIP. We can't do what you're suggesting and the best way to find out why > => is to read those threads, look for pasi's emails on the list, it doesn't > => cover the private discussions but it shows why we need both. > Yes, I did not follow the threads. But, I do realize lot of time and discussions went into this and that its a very complex problem. But, right now I'm only trying to understand how this works. My issue with the two ports is from the HA perspective. How it can identify the first data packet from the MN and setup the UDP tunnel in that path. How it ties this keepalive packet to a recently accepted BU. All this logic from the MN perspective appears very simple, but the logic on the HA is complex and I'm trying to understand the flow. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 07:42:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E34628C216; Tue, 8 Apr 2008 07:42: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 5A90128C216 for ; Tue, 8 Apr 2008 07:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 LYH4+k72+oWq for ; Tue, 8 Apr 2008 07:42:24 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 679EF28C164 for ; Tue, 8 Apr 2008 07:42:23 -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 1JjF1x-0001a0-WA; Wed, 09 Apr 2008 00:42:38 +1000 Message-Id: From: Hesham Soliman To: Sri Gundavelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 00:42:26 +1000 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, I did not follow the threads. But, I do realize lot of time and > discussions went into this and that its a very complex problem. But, > right now I'm only trying to understand how this works. My issue with > the two ports is from the HA perspective. How it can identify the > first > data packet from the MN and setup the UDP tunnel in that path. How it > ties this keepalive packet to a recently accepted BU. => What keepalive packet? We're using the BU/BA exchange for keepalive. IKE has its own KA mechanisms. I'm not sure what you mean. I know the current security considerations section is not easy to understand and we're working on making it much clearer, but the "DSMIP" part of the spec is very clear I think. So read everything else in the spec and read the security section sometime next week when I send out the new version. In the meantime read the spec from: http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal-02.txt There are two bugs, the Type field in the TLV is 4 bits not 8 and the values for the type will only contain GRE. Hesham > All this logic > from the MN perspective appears very simple, but the logic on the HA > is complex and I'm trying to understand the flow. > > > Sri > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 07:50:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D107228C21E; Tue, 8 Apr 2008 07:50: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 EAF8A3A6A67 for ; Tue, 8 Apr 2008 07:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.781 X-Spam-Level: X-Spam-Status: No, score=-5.781 tagged_above=-999 required=5 tests=[AWL=0.818, 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 TRcVWAaxjyrM for ; Tue, 8 Apr 2008 07:50:56 -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 DA20928C395 for ; Tue, 8 Apr 2008 07:50:14 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2008 07:50:31 -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 m38EoV7e016192; Tue, 8 Apr 2008 07:50:31 -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 m38EoU6n020490; Tue, 8 Apr 2008 14:50:30 GMT Date: Tue, 8 Apr 2008 07:50:30 -0700 (PDT) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1793; t=1207666231; x=1208530231; 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]=20TLV=20header=20in=20DSMIP |Sender:=20; bh=rOPuaM+R96m06QHnWo4C6yplLxekYKHQZQk71CoWRf4=; b=Z4cPtUfUwqt6ibpNhtrHVzlQtb3T+X2b5RJvRjtk6k0q+OkIUJwuGdNQ1b AvACbMHlzKraqjEfeC8dQDUFGjvtW0YC7OPULS08rbDb7ApUHCPPZBLgGfFU hBgCUTA045; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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, 9 Apr 2008, Hesham Soliman wrote: >> >> Yes, I did not follow the threads. But, I do realize lot of time and >> discussions went into this and that its a very complex problem. But, >> right now I'm only trying to understand how this works. My issue with >> the two ports is from the HA perspective. How it can identify the first >> data packet from the MN and setup the UDP tunnel in that path. How it >> ties this keepalive packet to a recently accepted BU. > > => What keepalive packet? We're using the BU/BA exchange for keepalive. IKE > => has its own KA mechanisms. > I'm not sure what you mean. > But, your BU/BA is a UDP encapsulated ESP packet and thats going to 4500 not DSMIP port ? (I did see a mail just now from Pasi clarifying this part). I'm not clear on two NAT flows, what packets are triggering the flows towards port 4500 and what is triggering flows towards DSMIP port. I will read the spec again and may be that should clear it. Thanks Sri > I know the current security considerations section is not easy to understand > and we're working on making it much clearer, but the "DSMIP" > part of the spec is very clear I think. So read everything else in the spec > and read the security section sometime next week when I send out the new > version. In the meantime read the spec from: > http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal-02.txt > > There are two bugs, the Type field in the TLV is 4 bits not 8 and the values > for the type will only contain GRE. > > Hesham > > >> All this logic >> from the MN perspective appears very simple, but the logic on the HA >> is complex and I'm trying to understand the flow. >> >> >> Sri >> >> >> >> >> >> >> >> >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 07:55:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A9A28C3C0; Tue, 8 Apr 2008 07:55: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 8978128C1D6 for ; Tue, 8 Apr 2008 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 FmgCdcJFOEdE for ; Tue, 8 Apr 2008 07:55:27 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EB2A428C3C0 for ; Tue, 8 Apr 2008 07:54:58 -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 1JjFE8-00025w-Ff; Wed, 09 Apr 2008 00:55:12 +1000 Message-Id: <016D1082-8D02-442C-901F-4BE2F2F8D9E7@elevatemobile.com> From: Hesham Soliman To: Sri Gundavelli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 00:55:11 +1000 References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com> <001e01c89604$15134880$d4f6200a@amer.cisco.com> <05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com> <000001c896ec$f8e64d30$d4f6200a@amer.cisco.com> <002401c89738$6dbe4d10$d4f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 09/04/2008, at 12:50 AM, Sri Gundavelli wrote: > > > On Wed, 9 Apr 2008, Hesham Soliman wrote: > >>> Yes, I did not follow the threads. But, I do realize lot of time and >>> discussions went into this and that its a very complex problem. But, >>> right now I'm only trying to understand how this works. My issue >>> with >>> the two ports is from the HA perspective. How it can identify the >>> first >>> data packet from the MN and setup the UDP tunnel in that path. How >>> it >>> ties this keepalive packet to a recently accepted BU. >> >> => What keepalive packet? We're using the BU/BA exchange for >> keepalive. IKE => has its own KA mechanisms. >> I'm not sure what you mean. >> > > But, your BU/BA is a UDP encapsulated ESP packet and thats going to > 4500 not DSMIP port ? (I did see a mail just now from Pasi clarifying > this part). => ok so you know this is not correct. > I'm not clear on two NAT flows, what packets are triggering > the flows towards port 4500 and what is triggering flows towards DSMIP > port. > > I will read the spec again and may be that should clear it. > => ok. Let me know if you have more comments. Hesham > Thanks > Sri > > >> I know the current security considerations section is not easy to >> understand and we're working on making it much clearer, but the >> "DSMIP" >> part of the spec is very clear I think. So read everything else in >> the spec and read the security section sometime next week when I >> send out the new >> version. In the meantime read the spec from: >> http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal-02.txt >> >> There are two bugs, the Type field in the TLV is 4 bits not 8 and >> the values for the type will only contain GRE. >> >> Hesham >> >> >>> All this logic >>> from the MN perspective appears very simple, but the logic on the HA >>> is complex and I'm trying to understand the flow. >>> Sri >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 8 15:29:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0460F3A6E7F; Tue, 8 Apr 2008 15:29: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 0D4B728C438 for ; Tue, 8 Apr 2008 15:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DD7MCaMVOel8 for ; Tue, 8 Apr 2008 15:29:40 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id 6D6DE28C25E for ; Tue, 8 Apr 2008 15:29:40 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so1875070wra.13 for ; Tue, 08 Apr 2008 15:29:56 -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=jrjN/tX/GYCMo4IeUxXahHm6/KuinyneyUGle+OERqg=; b=saDP6uPrj8WB54eJiYXhT7v0OFVz0UJZGFadXrQTaDCwDoui/i29cM08LujPRW/5fdxyYkQWDgCgKVMe2H3UdvdECIJ7hXiA7FkzCVFv1RZlL2KsXiwuF14J3yfJZsMtnOD+ZNFOJgKm8y27iqDkO6UNALfd7+RfiARM3OhXNns= 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=RxTMxSdX+uKAwghuencbhY0udGtHL/BmgAPpebI8PVfHqeSrrP13IgnzUeB73iVX3KH6rtrEavUDyYohemfQ3Lq3eYncVq5LbDR8Q1DGlAtpcqE4TwVpYKvgR+QiwNLMECQUHzQxhTBgadshVKkfLGeq2+Pieeorus2f9dlDt3k= Received: by 10.141.76.21 with SMTP id d21mr439901rvl.242.1207693795963; Tue, 08 Apr 2008 15:29:55 -0700 (PDT) Received: from ?10.0.1.194? ( [219.110.64.63]) by mx.google.com with ESMTPS id k2sm1796698rvb.6.2008.04.08.15.29.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Apr 2008 15:29:53 -0700 (PDT) From: RYUJI WAKIKAWA To: In-Reply-To: <1696498986EFEC4D9153717DA325CB724DC948@vaebe104.NOE.Nokia.com> References: <005901c895d3$c4d52440$d2716b80@amer.cisco.com><001e01c89604$15134880$d4f6200a@amer.cisco.com><05465585-698D-4926-8D2C-FFDD869BEB86@elevatemobile.com><000001c896ec$f8e64d30$d4f6200a@amer.cisco.com><003a01c89865$980851a0$7f89680a@amer.cisco.com><1696498986EFEC4D9153717DA325CB724DBD62@vaebe104.NOE.Nokia.com><002d01c898bf$78844910$d4f6200a@amer.cisco.com><003401c898c9$fd297460$d4f6200a@amer.cisco.com> <1696498986EFEC4D9153717DA325CB724DC948@vaebe104.NOE.Nokia.com> Message-Id: <7D9289B5-E61C-4563-90A6-A67AD8CF3397@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 07:29:49 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] TLV header in DSMIP 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 Pasi, Thanks for your correction. I will wait for the packet diagrams in the next revision:-) ryuji On 2008/04/08, at 19:47, wrote: > RYUJI WAKIKAWA wrote: > >> DSMIP uses BU/BA exchange for the keepalive. BU/BA will be sent with >> the 4500 port. We don't have keepalive mechanism for data flow >> (DSMIP port) in the current spec. > > No, in the current draft BU/BAck is sent over the DSMIPv6 port, > not 4500. (And yes, the draft is extremely difficult to understand > here, and needs to be much more understandable before it has > any chance of being approved...) > > Best regards, > Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From pecks@gp.com.au Thu Apr 10 12:28:35 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 594C53A6C8C for ; Thu, 10 Apr 2008 12:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_60=1, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.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 wLr5wO243YRY for ; Thu, 10 Apr 2008 12:28:34 -0700 (PDT) Received: from fuwbanq.proxad.net (man06-2-88-167-45-240.fbx.proxad.net [88.167.45.240]) by core3.amsl.com (Postfix) with SMTP id E0FAD3A68A8 for ; Thu, 10 Apr 2008 12:28:33 -0700 (PDT) Date: Thu, 10 Apr 2008 19:29:01 +0000 From: "Arendt Leavell" X-Mailer: The Bat! (3.64.03) Professional Reply-To: Arendt Leavell X-Priority: 3 (Normal) Message-ID: <5729478329.20080410192833@gp.com.au> To: Subject: apotropaic MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------3AFAA8EA07A319" ------------3AFAA8EA07A319 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable God dag,=20 =20 =09Real men! MMillions of people accross the world have already tested T= HIS and ARE making their girlfriendss feel brand new sexual sensattions!=20 YOU are the best in bed, aren't you ?Girls!=20 DDevelop your sexual rrelationship and get even MORE pleasuure! =09Make you= r bboyfriend a gift! http://zxvj4iwytszrf7e.blogspot.com =20 Very unlikely that either of them had anything and she can dine with our servants. They are very to any conditions. so far as i can see, i have atlanta fell to 34,000 against 30,000 on the other he knew the truth . . . He took the letter from crisis, you call upon me in london. If you will the bank, and more so to the prestige of this fort sumter now would require a force of 20,000 is completely retired. i think he would not feel were distinguished, gave grace at once and confidence 1389. Brown, john: 126, 1505, 197, 397. Buchanan, high and ten thick at the bottom, narrowing to publicity in these possibly, but it depends on stewed in, and pour it on the fish either in butter before death. first idea was it was given to her. ------------3AFAA8EA07A319 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =20 =09

God dag,


Real men! MMillions of people accross the world have already tested THIS and ARE = making their girlfriendss feel brand new sexual sensattions! YOU are the best in bed, aren't you ?
Girls! =09DDevelop your sexual rrelationsh= ip and get even MORE pleasuure! Make your bboyfriend = a gift!
http://zxvj4iwytszrf7e.blogspot.com


<= /p>

Very unlikely that either of them had anything and she = can
dine with our servants. They are very to any conditions.
so= far as i can see, i have atlanta fell to 34,000 against
30,000 on th= e other he knew the truth . . . He took the
letter from crisis, you c= all upon me in london. If you will
the bank, and more so to the prest= ige of this fort sumter
now would require a force of 20,000 is comple= tely retired.
i think he would not feel were distinguished, gave grac= e
at once and confidence 1389. Brown, john: 126, 1505, 197,
397= Buchanan, high and ten thick at the bottom, narrowing
to publicity = in these possibly, but it depends on stewed
in, and pour it on the fi= sh either in butter before death.
first idea was it was given to her.=

------------3AFAA8EA07A319-- From mext-bounces@ietf.org Thu Apr 10 15:29:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6178E3A6CA8; Thu, 10 Apr 2008 15:29: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 0F3213A6C60 for ; Thu, 10 Apr 2008 15:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 8TgRB1IJcbbo for ; Thu, 10 Apr 2008 15:29:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1C6303A67EB for ; Thu, 10 Apr 2008 15:29:17 -0700 (PDT) Received: from [192.168.0.112] (82.159.23.147.dyn.user.ono.com [82.159.23.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id A6C22381014; Fri, 11 Apr 2008 00:29:35 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tony Whyman In-Reply-To: <47F60F77.7000809@mccallumwhyman.com> References: <47F60F77.7000809@mccallumwhyman.com> Organization: Universidad Carlos III de Madrid Date: Fri, 11 Apr 2008 00:28:11 +0200 Message-Id: <1207866491.5040.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: mext@ietf.org Subject: Re: [MEXT] A Proposed Solution for Aeronautical RO X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2085167293==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2085167293== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WLreGDWxLrHNr4T6qIsw" --=-WLreGDWxLrHNr4T6qIsw Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Tony, Thanks for proposing a solution. While I admit I've not gone through all your paper yet, I'd like to ask you a question: does your solution require changes on the CN side? from what I've read so far, I tend to think so, but I'd like to check that. I understood in the last MEXT interim meeting that changing the CNs was not a valid assumption. Thanks a lot, Carlos On vie, 2008-04-04 at 12:22 +0100, Tony Whyman wrote: > Dear all, >=20 > I have prepared a proposed IPsec based RO scheme that is intended to=20 > meet the requirements contained in draft-ietf-mext-aero-reqs-01. The=20 > paper can be downloaded from: >=20 > http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.p= df >=20 > It's a large paper (15,000+ words) but that is because of the large=20 > Appendix A, which is an analysis of how the proposal meets the current=20 > aeronautical use cases. Appendix B also provides a compliancy check=20 > against draft-ietf-mext-aero-reqs-01. >=20 > The main body of the paper is likely to be of most interest to this=20 > group. In this, I have tried to evolve the IPsec RO approach proposed in=20 > draft-ietf-mip6-cn-ipsec-07 into a common framework with the=20 > recommendations of Eurocontrol 2006 IP Study. This study was intended=20 > to "assess the feasibility of using IP to support the next generation of=20 > collaborative ATS applications, in the 2020+ timeframe". The published=20 > results of that study can be downloaded from the ICAO website (URL in=20 > the references list of my paper). >=20 > Although the focus of the paper is on meeting the requirements for=20 > Aeronautical use, I do not believe that the requirements are unique to=20 > civil aviation. The UK Railways Safety and Standards Board (RSSB) is=20 > also about to publish a Guidance Note (Ref: GE/GN8579) which is intended=20 > to co-ordinate the use of IP Networking for mobile networking to trains.=20 > SATCOM, GPRS, WiFi and WiMAX networks are already being used to support=20 > passenger "on train" internet access and some operational use, and this=20 > Guidance Note is intended to co-ordinate the use of IP for operational=20 > comms, leading into Safety Related applications. It was the result of=20 > industry consultation and workshops and resulted in a very similar set=20 > of operational scenarios to those seen in ATC, and a similar proposal=20 > for IPsec based mobile communications. >=20 > My own conclusion from all this, is that there is a real need for an=20 > IPsec based Mobility Framework to meet the needs of Operational=20 > Communications in (at least) Transport Infrastructure applications. >=20 > My paper has made some specific criticisms of=20 > draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the needs=20 > of aeronautical communications. However, the underlying criticism is=20 > that draft-ietf-mip6-cn-ipsec-07 is relatively neutral as regards IKEv1=20 > and IKEv2. My view is that IKEv2 is not just a better protocol, but with=20 > improved Traffic Selection signalling and the MOBIKE (RFC 4555), it is=20 > the only flavour of IPsec IKE that should be considered for an IPsec=20 > based mobility framework. >=20 > Starting with the assumption that IKEv2/MOBIKE is used, I believe that=20 > it is possible to demonstrate a much improved strategy for IPsec based=20 > Route Optimisation, that starts with the use of the Home Address as the=20 > MN SA end-point and then moves it to the care-of address. Thus=20 > demonstrating both authorisation to use the Home Address and Return=20 > Routability to both addresses before any user data is exchanged.=20 > Interestingly, if user data is to be protected by ESP or AH tunnelling=20 > then there seems to be no need to exchange a Binding Update, as Child=20 > SAs with appropriate Traffic Selectors seem to be sufficient. >=20 > A further step is also possible if both MN and CN support a common PKI=20 > that provides both authentication and authorisation of the MN to use its=20 > Home Address. In this case, it appears possible for the MN to start the=20 > IPsec based RO procedure direct from its care-of address without there=20 > needing to be any Home Agent involvement. This is particularly=20 > interesting to aeronautical use, where communication is generally=20 > aircraft initiated, as it avoids both availability and regulatory issues=20 > with Home Agents, and fits with the recommendations of the Eurocontrol=20 > IP Study. Although it did not call it as such, this study essentially=20 > proposed an IPsec based RO scheme, which it called "tunnel movement" and=20 > assumed a PKI that authenticated aircraft and their use of their static=20 > IP Addresses. >=20 > The study limited itself to what was possible with published RFCs, and=20 > thus all air/ground communications had to be ESP tunnelled, due to the=20 > use of IKEv2/MOBIKE to manage the communications paths. Two specific=20 > criticisms arise from this. One is that there are many cases where an=20 > RFC 3775 Home Address Option/Type 2 Routing Header and Transport mode=20 > ESP would be more efficient than ESP tunnelling, and the other is that=20 > it forces all air/ground communications to be protected, even when the=20 > overhead of doing so is not otherwise justifiable. >=20 > In my paper, I have tried to resolve both criticisms. >=20 > I have resolved the first, by proposing a new IPsec SA mode that=20 > essentially combines ESP/AH transport mode with use of the RFC 3775 Home=20 > Address Option/Type 2 Routing Header. >=20 > I have resolved the second by proposing the notion of "No Protection"=20 > SAs - i.e. using the IKEv2 to negotiate IP-in-IP tunnels, or use of the=20 > RFC 3775 Home Address Option/Type 2 Routing Header. Although this seems=20 > to be counter-intuitive for the IPsec IKE to negotiate off security, the=20 > benefit is in having a single mechanism to manage unprotected mobile=20 > communications, when there is also a need for secure mobile communication= s. >=20 > My paper also examines the case where the IKE is used to manage secure=20 > mobile communications but has no means of authenticating the MN to the=20 > CN. This appears to be interesting as part of a wider framework, but is=20 > not of direct interest to aeronautical communications. >=20 > I have also investigated possible implications for MN to HA=20 > communications, and proposed IKEv2/MOBIKE scenarios where Binding=20 > Updates are no longer needed here. Again, this is not of direct interest=20 > to aeronautical communications, but should be of wider interest. >=20 > Looking back on the paper, although I started writing assuming IPv6=20 > only, almost everything proposed is also relevant to IPv4. Only the use=20 > of the RFC 3775 Home Address Option/Type 2 Routing Header is IPv6 specifi= c. >=20 > Using the IKE to manage mobility also seems to have some other=20 > interesting implications. Like it or not, NAT Gateways are well=20 > supported by IPsec, and a Mobile Node that uses IKEv2/MOBIKE to manage=20 > both its HA binding and RO, seems to be able to move behind NAT Gateways=20 > and then re-emerge without any obvious problems - although this mode of=20 > operation is limited to ESP tunnels. >=20 > Basic NEMO operations should really be just a case of an appropriate set=20 > of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that=20 > allows a CN to authenticate a Mobile Router and authorise the routes it=20 > offers, then the use of the IKE to manage Mobile Router Route=20 > Optimisation also appears to be an interesting approach. This is very=20 > relevant to Aeronautical use. >=20 > IKEv2/MOBIKE has limited multi-homing capability, in respect of=20 > supporting the use of multi-homing for increasing availability. Load=20 > sharing is not part of the current framework. The use of multi-homing=20 > for increasing availability meets a perceived aeronautical requirement=20 > to enable high availability of air/ground communications through agility=20 > in the use of alternative networks. Extension to load sharing seems to a=20 > suitable topic for future work, but not essential for aeronautical use. >=20 > The purpose of this paper is to develop an IPsec based RO strategy=20 > suitable for aeronautical use and one that is also suitable for similar=20 > transport infrastructure uses, but I believe the use of IPsec based=20 > mobility management using IKEv2 and MOBIKE should be of general interest. >=20 > Regards >=20 > Tony Whyman >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-WLreGDWxLrHNr4T6qIsw Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBH/pR7Ndy6TdFwT2cRAoZ8AKDFOP5Nmrhl0XjAfyvmHeRRRDb42QCgojbm vQxCwsKEAf4dkWbyj1awdFo= =W8E+ -----END PGP SIGNATURE----- --=-WLreGDWxLrHNr4T6qIsw-- --===============2085167293== 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 --===============2085167293==-- From mext-bounces@ietf.org Thu Apr 10 15:35:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0D23A684F; Thu, 10 Apr 2008 15:35: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 457513A684F for ; Thu, 10 Apr 2008 15:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[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 VfHkSL9BSVxS for ; Thu, 10 Apr 2008 15:35:52 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A8F733A6957 for ; Thu, 10 Apr 2008 15:35:51 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (host86-159-19-253.range86-159.btcentralplus.com [86.159.19.253])by smtp02.uc3m.es (Postfix) with ESMTP id 0169E3815C6;Fri, 11 Apr 2008 00:36:05 +0200 (CEST) Message-ID: <47FE9655.3010202@it.uc3m.es> Date: Fri, 11 Apr 2008 00:36:05 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <47F60F77.7000809@mccallumwhyman.com> <1207866491.5040.23.camel@localhost> In-Reply-To: <1207866491.5040.23.camel@localhost> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-33.9457 TC:1F TRN:94 TV:5.0.1023(15842.002) 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 Subject: Re: [MEXT] A Proposed Solution for Aeronautical RO 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 Carlos Jes=FAs Bernardos Cano escribi=F3: > Hi Tony, > > Thanks for proposing a solution. > > While I admit I've not gone through all your paper yet, I'd like to ask > you a question: does your solution require changes on the CN side? from > what I've read so far, I tend to think so, but I'd like to check that. I > understood in the last MEXT interim meeting that changing the CNs was > not a valid assumption. > = right but rephrasing Carlos question, would the solution support CN proxies = that perform the RO operations on behalf of the CN? (that would be = acceptable according to the requirements) Regards, marcelo > Thanks a lot, > > Carlos > > On vie, 2008-04-04 at 12:22 +0100, Tony Whyman wrote: > = >> Dear all, >> >> I have prepared a proposed IPsec based RO scheme that is intended to = >> meet the requirements contained in draft-ietf-mext-aero-reqs-01. The = >> paper can be downloaded from: >> >> http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.= pdf >> >> It's a large paper (15,000+ words) but that is because of the large = >> Appendix A, which is an analysis of how the proposal meets the current = >> aeronautical use cases. Appendix B also provides a compliancy check = >> against draft-ietf-mext-aero-reqs-01. >> >> The main body of the paper is likely to be of most interest to this = >> group. In this, I have tried to evolve the IPsec RO approach proposed in = >> draft-ietf-mip6-cn-ipsec-07 into a common framework with the = >> recommendations of Eurocontrol 2006 IP Study. This study was intended = >> to "assess the feasibility of using IP to support the next generation of = >> collaborative ATS applications, in the 2020+ timeframe". The published = >> results of that study can be downloaded from the ICAO website (URL in = >> the references list of my paper). >> >> Although the focus of the paper is on meeting the requirements for = >> Aeronautical use, I do not believe that the requirements are unique to = >> civil aviation. The UK Railways Safety and Standards Board (RSSB) is = >> also about to publish a Guidance Note (Ref: GE/GN8579) which is intended = >> to co-ordinate the use of IP Networking for mobile networking to trains. = >> SATCOM, GPRS, WiFi and WiMAX networks are already being used to support = >> passenger "on train" internet access and some operational use, and this = >> Guidance Note is intended to co-ordinate the use of IP for operational = >> comms, leading into Safety Related applications. It was the result of = >> industry consultation and workshops and resulted in a very similar set = >> of operational scenarios to those seen in ATC, and a similar proposal = >> for IPsec based mobile communications. >> >> My own conclusion from all this, is that there is a real need for an = >> IPsec based Mobility Framework to meet the needs of Operational = >> Communications in (at least) Transport Infrastructure applications. >> >> My paper has made some specific criticisms of = >> draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the needs = >> of aeronautical communications. However, the underlying criticism is = >> that draft-ietf-mip6-cn-ipsec-07 is relatively neutral as regards IKEv1 = >> and IKEv2. My view is that IKEv2 is not just a better protocol, but with = >> improved Traffic Selection signalling and the MOBIKE (RFC 4555), it is = >> the only flavour of IPsec IKE that should be considered for an IPsec = >> based mobility framework. >> >> Starting with the assumption that IKEv2/MOBIKE is used, I believe that = >> it is possible to demonstrate a much improved strategy for IPsec based = >> Route Optimisation, that starts with the use of the Home Address as the = >> MN SA end-point and then moves it to the care-of address. Thus = >> demonstrating both authorisation to use the Home Address and Return = >> Routability to both addresses before any user data is exchanged. = >> Interestingly, if user data is to be protected by ESP or AH tunnelling = >> then there seems to be no need to exchange a Binding Update, as Child = >> SAs with appropriate Traffic Selectors seem to be sufficient. >> >> A further step is also possible if both MN and CN support a common PKI = >> that provides both authentication and authorisation of the MN to use its = >> Home Address. In this case, it appears possible for the MN to start the = >> IPsec based RO procedure direct from its care-of address without there = >> needing to be any Home Agent involvement. This is particularly = >> interesting to aeronautical use, where communication is generally = >> aircraft initiated, as it avoids both availability and regulatory issues = >> with Home Agents, and fits with the recommendations of the Eurocontrol = >> IP Study. Although it did not call it as such, this study essentially = >> proposed an IPsec based RO scheme, which it called "tunnel movement" and = >> assumed a PKI that authenticated aircraft and their use of their static = >> IP Addresses. >> >> The study limited itself to what was possible with published RFCs, and = >> thus all air/ground communications had to be ESP tunnelled, due to the = >> use of IKEv2/MOBIKE to manage the communications paths. Two specific = >> criticisms arise from this. One is that there are many cases where an = >> RFC 3775 Home Address Option/Type 2 Routing Header and Transport mode = >> ESP would be more efficient than ESP tunnelling, and the other is that = >> it forces all air/ground communications to be protected, even when the = >> overhead of doing so is not otherwise justifiable. >> >> In my paper, I have tried to resolve both criticisms. >> >> I have resolved the first, by proposing a new IPsec SA mode that = >> essentially combines ESP/AH transport mode with use of the RFC 3775 Home = >> Address Option/Type 2 Routing Header. >> >> I have resolved the second by proposing the notion of "No Protection" = >> SAs - i.e. using the IKEv2 to negotiate IP-in-IP tunnels, or use of the = >> RFC 3775 Home Address Option/Type 2 Routing Header. Although this seems = >> to be counter-intuitive for the IPsec IKE to negotiate off security, the = >> benefit is in having a single mechanism to manage unprotected mobile = >> communications, when there is also a need for secure mobile communicatio= ns. >> >> My paper also examines the case where the IKE is used to manage secure = >> mobile communications but has no means of authenticating the MN to the = >> CN. This appears to be interesting as part of a wider framework, but is = >> not of direct interest to aeronautical communications. >> >> I have also investigated possible implications for MN to HA = >> communications, and proposed IKEv2/MOBIKE scenarios where Binding = >> Updates are no longer needed here. Again, this is not of direct interest = >> to aeronautical communications, but should be of wider interest. >> >> Looking back on the paper, although I started writing assuming IPv6 = >> only, almost everything proposed is also relevant to IPv4. Only the use = >> of the RFC 3775 Home Address Option/Type 2 Routing Header is IPv6 specif= ic. >> >> Using the IKE to manage mobility also seems to have some other = >> interesting implications. Like it or not, NAT Gateways are well = >> supported by IPsec, and a Mobile Node that uses IKEv2/MOBIKE to manage = >> both its HA binding and RO, seems to be able to move behind NAT Gateways = >> and then re-emerge without any obvious problems - although this mode of = >> operation is limited to ESP tunnels. >> >> Basic NEMO operations should really be just a case of an appropriate set = >> of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that = >> allows a CN to authenticate a Mobile Router and authorise the routes it = >> offers, then the use of the IKE to manage Mobile Router Route = >> Optimisation also appears to be an interesting approach. This is very = >> relevant to Aeronautical use. >> >> IKEv2/MOBIKE has limited multi-homing capability, in respect of = >> supporting the use of multi-homing for increasing availability. Load = >> sharing is not part of the current framework. The use of multi-homing = >> for increasing availability meets a perceived aeronautical requirement = >> to enable high availability of air/ground communications through agility = >> in the use of alternative networks. Extension to load sharing seems to a = >> suitable topic for future work, but not essential for aeronautical use. >> >> The purpose of this paper is to develop an IPsec based RO strategy = >> suitable for aeronautical use and one that is also suitable for similar = >> transport infrastructure uses, but I believe the use of IPsec based = >> mobility management using IKEv2 and MOBIKE should be of general interest. >> >> Regards >> >> Tony Whyman >> >> >> >> _______________________________________________ >> 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 Apr 11 02:34:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2D53A6CF2; Fri, 11 Apr 2008 02:34: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 260473A6E26 for ; Fri, 11 Apr 2008 02:33: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 VtAqU9lv2ws7 for ; Fri, 11 Apr 2008 02:33:54 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id A18DB3A6CC5 for ; Fri, 11 Apr 2008 02:33:53 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m3B9YDr1023760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 10:34:13 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m3B9YCZ3007162; Fri, 11 Apr 2008 10:34:13 +0100 Message-ID: <47FF3094.1060600@mccallumwhyman.com> Date: Fri, 11 Apr 2008 10:34:12 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: marcelo bagnulo References: <47F60F77.7000809@mccallumwhyman.com> <1207866491.5040.23.camel@localhost> <47FE9655.3010202@it.uc3m.es> In-Reply-To: <47FE9655.3010202@it.uc3m.es> Cc: mext@ietf.org Subject: Re: [MEXT] A Proposed Solution for Aeronautical RO 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 Marcelo and Carlos, Thank you for taking the time to look at my paper. However, I am = slightly confused by your question, in the sense of what does "change" mean. In my proposed scheme, the CN is required to support IKEv2/MOBIKE as a = minimum. I have also proposed extensions to IKEv2 to include a means of = negotiating the use of the use of the Home Address Option/Type 2 Routing = Header and this extension is obviously a "change" from published RFCs - = although not necessarily an essential change - it is proposed to improve = performance. So, if the question is "is the functionality of the CN different from = that required by RFC 3775", the answer is "of course it is". My proposal = observes that trying to keep within the confines of RFC 3775 when = introducing IPsec to the MN to CN relationship leads to an inefficient = protocol and I have hence proposed to improve it. Is change a problem? Not in the context of the proposal. Air Traffic = Control is a controlled environment where all systems have to be = compliant and certified or approved before operation. The industry is = only at the start of a development process for an ATN-IP and there is = still plenty of scope for refining the specification before freezing it. How big a change is being proposed? Conceptually, it is probably a big = one. The MN to CN relationship changes from being an optimisation to the = normal mobility relationship. Home Agents are only brought into the = picture when you need a transition aid to support communication with CNs = that don't support IKEv2/MOBIKE and/or do not recognise the MN's = credentials, or when the DNS is used for (mobile) name to address = resolution and hence you need a rendezvous point. In the civil aviation environment for ATC and AOC it may be assumed = that all CNs will be compliant and part of the same trust framework. The = (existing) Context Management application manages the very dynamic = relationship between the "Flight", an "aircraft" and any IP Addresses = assigned to it, and avoids the need for rendezvous points. Home Agents = are not needed for such reasons, and are anyway undesirable because of = the availability and regulatory issues I referred to. Hence a proposal = that focusses on the MN to CN relationship. Regards Tony Whyman marcelo bagnulo wrote: > Carlos Jes=FAs Bernardos Cano escribi=F3: >> Hi Tony, >> >> Thanks for proposing a solution. >> >> While I admit I've not gone through all your paper yet, I'd like = >> to ask >> you a question: does your solution require changes on the CN side? from >> what I've read so far, I tend to think so, but I'd like to check that. I >> understood in the last MEXT interim meeting that changing the CNs was >> not a valid assumption. >> = > right > but rephrasing Carlos question, would the solution support CN proxies = > that perform the RO operations on behalf of the CN? (that would be = > acceptable according to the requirements) > > Regards, marcelo > > >> Thanks a lot, >> >> Carlos >> >> On vie, 2008-04-04 at 12:22 +0100, Tony Whyman wrote: >> = >>> Dear all, >>> >>> I have prepared a proposed IPsec based RO scheme that is intended to = >>> meet the requirements contained in draft-ietf-mext-aero-reqs-01. The = >>> paper can be downloaded from: >>> >>> http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO= .pdf = >>> >>> >>> It's a large paper (15,000+ words) but that is because of the large = >>> Appendix A, which is an analysis of how the proposal meets the = >>> current aeronautical use cases. Appendix B also provides a = >>> compliancy check against draft-ietf-mext-aero-reqs-01. >>> >>> The main body of the paper is likely to be of most interest to this = >>> group. In this, I have tried to evolve the IPsec RO approach = >>> proposed in draft-ietf-mip6-cn-ipsec-07 into a common framework with = >>> the recommendations of Eurocontrol 2006 IP Study. This study was = >>> intended to "assess the feasibility of using IP to support the next = >>> generation of collaborative ATS applications, in the 2020+ = >>> timeframe". The published results of that study can be downloaded = >>> from the ICAO website (URL in the references list of my paper). >>> >>> Although the focus of the paper is on meeting the requirements for = >>> Aeronautical use, I do not believe that the requirements are unique = >>> to civil aviation. The UK Railways Safety and Standards Board (RSSB) = >>> is also about to publish a Guidance Note (Ref: GE/GN8579) which is = >>> intended to co-ordinate the use of IP Networking for mobile = >>> networking to trains. SATCOM, GPRS, WiFi and WiMAX networks are = >>> already being used to support passenger "on train" internet access = >>> and some operational use, and this Guidance Note is intended to = >>> co-ordinate the use of IP for operational comms, leading into Safety = >>> Related applications. It was the result of industry consultation and = >>> workshops and resulted in a very similar set of operational = >>> scenarios to those seen in ATC, and a similar proposal for IPsec = >>> based mobile communications. >>> >>> My own conclusion from all this, is that there is a real need for an = >>> IPsec based Mobility Framework to meet the needs of Operational = >>> Communications in (at least) Transport Infrastructure applications. >>> >>> My paper has made some specific criticisms of = >>> draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the = >>> needs of aeronautical communications. However, the underlying = >>> criticism is that draft-ietf-mip6-cn-ipsec-07 is relatively neutral = >>> as regards IKEv1 and IKEv2. My view is that IKEv2 is not just a = >>> better protocol, but with improved Traffic Selection signalling and = >>> the MOBIKE (RFC 4555), it is the only flavour of IPsec IKE that = >>> should be considered for an IPsec based mobility framework. >>> >>> Starting with the assumption that IKEv2/MOBIKE is used, I believe = >>> that it is possible to demonstrate a much improved strategy for = >>> IPsec based Route Optimisation, that starts with the use of the Home = >>> Address as the MN SA end-point and then moves it to the care-of = >>> address. Thus demonstrating both authorisation to use the Home = >>> Address and Return Routability to both addresses before any user = >>> data is exchanged. Interestingly, if user data is to be protected by = >>> ESP or AH tunnelling then there seems to be no need to exchange a = >>> Binding Update, as Child SAs with appropriate Traffic Selectors seem = >>> to be sufficient. >>> >>> A further step is also possible if both MN and CN support a common = >>> PKI that provides both authentication and authorisation of the MN to = >>> use its Home Address. In this case, it appears possible for the MN = >>> to start the IPsec based RO procedure direct from its care-of = >>> address without there needing to be any Home Agent involvement. This = >>> is particularly interesting to aeronautical use, where communication = >>> is generally aircraft initiated, as it avoids both availability and = >>> regulatory issues with Home Agents, and fits with the = >>> recommendations of the Eurocontrol IP Study. Although it did not = >>> call it as such, this study essentially proposed an IPsec based RO = >>> scheme, which it called "tunnel movement" and assumed a PKI that = >>> authenticated aircraft and their use of their static IP Addresses. >>> >>> The study limited itself to what was possible with published RFCs, = >>> and thus all air/ground communications had to be ESP tunnelled, due = >>> to the use of IKEv2/MOBIKE to manage the communications paths. Two = >>> specific criticisms arise from this. One is that there are many = >>> cases where an RFC 3775 Home Address Option/Type 2 Routing Header = >>> and Transport mode ESP would be more efficient than ESP tunnelling, = >>> and the other is that it forces all air/ground communications to be = >>> protected, even when the overhead of doing so is not otherwise = >>> justifiable. >>> >>> In my paper, I have tried to resolve both criticisms. >>> >>> I have resolved the first, by proposing a new IPsec SA mode that = >>> essentially combines ESP/AH transport mode with use of the RFC 3775 = >>> Home Address Option/Type 2 Routing Header. >>> >>> I have resolved the second by proposing the notion of "No = >>> Protection" SAs - i.e. using the IKEv2 to negotiate IP-in-IP = >>> tunnels, or use of the RFC 3775 Home Address Option/Type 2 Routing = >>> Header. Although this seems to be counter-intuitive for the IPsec = >>> IKE to negotiate off security, the benefit is in having a single = >>> mechanism to manage unprotected mobile communications, when there is = >>> also a need for secure mobile communications. >>> >>> My paper also examines the case where the IKE is used to manage = >>> secure mobile communications but has no means of authenticating the = >>> MN to the CN. This appears to be interesting as part of a wider = >>> framework, but is not of direct interest to aeronautical = >>> communications. >>> >>> I have also investigated possible implications for MN to HA = >>> communications, and proposed IKEv2/MOBIKE scenarios where Binding = >>> Updates are no longer needed here. Again, this is not of direct = >>> interest to aeronautical communications, but should be of wider = >>> interest. >>> >>> Looking back on the paper, although I started writing assuming IPv6 = >>> only, almost everything proposed is also relevant to IPv4. Only the = >>> use of the RFC 3775 Home Address Option/Type 2 Routing Header is = >>> IPv6 specific. >>> >>> Using the IKE to manage mobility also seems to have some other = >>> interesting implications. Like it or not, NAT Gateways are well = >>> supported by IPsec, and a Mobile Node that uses IKEv2/MOBIKE to = >>> manage both its HA binding and RO, seems to be able to move behind = >>> NAT Gateways and then re-emerge without any obvious problems - = >>> although this mode of operation is limited to ESP tunnels. >>> >>> Basic NEMO operations should really be just a case of an appropriate = >>> set of SA Traffic Selectors for MN to SA tunnels. If a PKI exists = >>> that allows a CN to authenticate a Mobile Router and authorise the = >>> routes it offers, then the use of the IKE to manage Mobile Router = >>> Route Optimisation also appears to be an interesting approach. This = >>> is very relevant to Aeronautical use. >>> >>> IKEv2/MOBIKE has limited multi-homing capability, in respect of = >>> supporting the use of multi-homing for increasing availability. Load = >>> sharing is not part of the current framework. The use of = >>> multi-homing for increasing availability meets a perceived = >>> aeronautical requirement to enable high availability of air/ground = >>> communications through agility in the use of alternative networks. = >>> Extension to load sharing seems to a suitable topic for future work, = >>> but not essential for aeronautical use. >>> >>> The purpose of this paper is to develop an IPsec based RO strategy = >>> suitable for aeronautical use and one that is also suitable for = >>> similar transport infrastructure uses, but I believe the use of = >>> IPsec based mobility management using IKEv2 and MOBIKE should be of = >>> general interest. >>> >>> Regards >>> >>> Tony Whyman >>> >>> >>> >>> _______________________________________________ >>> 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 Apr 11 03:29:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B71728C290; Fri, 11 Apr 2008 03:29: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 4049C28C2AC for ; Fri, 11 Apr 2008 03:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtmLXysYFLNW for ; Fri, 11 Apr 2008 03:29:08 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by core3.amsl.com (Postfix) with ESMTP id B898128C28E for ; Fri, 11 Apr 2008 03:29:07 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so452752wxd.31 for ; Fri, 11 Apr 2008 03:29:30 -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=Hfalg11Xkp9ih0cEYLVisUkxDUZwPBUlMMffBkvfwdY=; b=MQvco79dpAgaLB5jSiNnmGhUukXNmQUTyf8m5nneBxY8TSZ7N2JvLiASE0jjtQalXigoqOW4i08BwxkE34cYfRl57vLl+AHOhtLaNIBuKxu8HoH2E+kZxMrf5/yxdh7DpRm0t89awRB+iPck7KXjAlXvrz0pAlUa0wvPTHLpTvs= 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=MwBQ/hqDveVe4tkCb2ysohJlMPwt4rGHEJI1u0nV5nHQuar/HdhlGSYRa/vYmL/WRtFWpcqlnTTXtkT4MjRj97Clkm6Hn/aMcM097PNBtpWVOjGIRURyJzCMNfPG2PYI7rSiEv3lBxbbW3RjQf9GlCTnjCEjpiomFnE5UqO+LPM= Received: by 10.70.92.12 with SMTP id p12mr3156605wxb.47.1207909767565; Fri, 11 Apr 2008 03:29:27 -0700 (PDT) Received: by 10.70.65.9 with HTTP; Fri, 11 Apr 2008 03:29:27 -0700 (PDT) Message-ID: Date: Fri, 11 Apr 2008 12:29:27 +0200 From: "=?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?=" To: "Tony Whyman" In-Reply-To: <47FF3094.1060600@mccallumwhyman.com> MIME-Version: 1.0 Content-Disposition: inline References: <47F60F77.7000809@mccallumwhyman.com> <1207866491.5040.23.camel@localhost> <47FE9655.3010202@it.uc3m.es> <47FF3094.1060600@mccallumwhyman.com> X-Google-Sender-Auth: 5479d2117d8b80b3 Cc: mext@ietf.org Subject: Re: [MEXT] A Proposed Solution for Aeronautical RO 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 Tony, Thanks for your reply. Please, see my comments below. On 11/04/2008, Tony Whyman wrote: > Marcelo and Carlos, > > Thank you for taking the time to look at my paper. However, I am slightly > confused by your question, in the sense of what does "change" mean. I mean requiring some new extension/mechanism that is not supported by standard IPv6 nodes. > > In my proposed scheme, the CN is required to support IKEv2/MOBIKE as a > minimum. I have also proposed extensions to IKEv2 to include a means of > negotiating the use of the use of the Home Address Option/Type 2 Routing > Header and this extension is obviously a "change" from published RFCs - > although not necessarily an essential change - it is proposed to improve > performance. > > So, if the question is "is the functionality of the CN different from th= at > required by RFC 3775", the answer is "of course it is". My proposal obser= ves > that trying to keep within the confines of RFC 3775 when introducing IPsec > to the MN to CN relationship leads to an inefficient protocol and I have > hence proposed to improve it. > I was not saying I disagree with that :-). > Is change a problem? Not in the context of the proposal. Air Traffic > Control is a controlled environment where all systems have to be compliant > and certified or approved before operation. The industry is only at the > start of a development process for an ATN-IP and there is still plenty of > scope for refining the specification before freezing it. Well, that's different from what I understood in the MEXT itnerim meeting. Maybe I'm wrong, but I think the question regarding modifying the operation of CNs was specifically asked and the answer was that it is not possible. > > How big a change is being proposed? Conceptually, it is probably a big o= ne. > The MN to CN relationship changes from being an optimisation to the normal > mobility relationship. Home Agents are only brought into the picture when > you need a transition aid to support communication with CNs that don't > support IKEv2/MOBIKE and/or do not recognise the MN's credentials, or when > the DNS is used for (mobile) name to address resolution and hence you nee= d a > rendezvous point. I'm not against "big" changes in controlled environments as the aerospace one, but I just want to know whether those changes could be made or not. > > In the civil aviation environment for ATC and AOC it may be assumed that > all CNs will be compliant and part of the same trust framework. The > (existing) Context Management application manages the very dynamic > relationship between the "Flight", an "aircraft" and any IP Addresses > assigned to it, and avoids the need for rendezvous points. Home Agents are > not needed for such reasons, and are anyway undesirable because of the > availability and regulatory issues I referred to. Hence a proposal that > focusses on the MN to CN relationship. Do all the people have the same view on that? Thanks a lot. Regards, Carlos > > Regards > > Tony Whyman > > > marcelo bagnulo wrote: > > > Carlos Jes=FAs Bernardos Cano escribi=F3: > > > > > Hi Tony, > > > > > > Thanks for proposing a solution. > > > > > > While I admit I've not gone through all your paper yet, I'd like to > ask > > > you a question: does your solution require changes on the CN side? fr= om > > > what I've read so far, I tend to think so, but I'd like to check that= . I > > > understood in the last MEXT interim meeting that changing the CNs was > > > not a valid assumption. > > > > > > > > right > > but rephrasing Carlos question, would the solution support CN proxies t= hat > perform the RO operations on behalf of the CN? (that would be acceptable > according to the requirements) > > > > Regards, marcelo > > > > > > > > > Thanks a lot, > > > > > > Carlos > > > > > > On vie, 2008-04-04 at 12:22 +0100, Tony Whyman wrote: > > > > > > > > > > Dear all, > > > > > > > > I have prepared a proposed IPsec based RO scheme that is intended to > meet the requirements contained in draft-ietf-mext-aero-reqs-01. The paper > can be downloaded from: > > > > > > > > > http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.p= df > > > > > > > > It's a large paper (15,000+ words) but that is because of the large > Appendix A, which is an analysis of how the proposal meets the current > aeronautical use cases. Appendix B also provides a compliancy check again= st > draft-ietf-mext-aero-reqs-01. > > > > > > > > The main body of the paper is likely to be of most interest to this > group. In this, I have tried to evolve the IPsec RO approach proposed in > draft-ietf-mip6-cn-ipsec-07 into a common framework with the recommendati= ons > of Eurocontrol 2006 IP Study. This study was intended to "assess the > feasibility of using IP to support the next generation of collaborative A= TS > applications, in the 2020+ timeframe". The published results of that study > can be downloaded from the ICAO website (URL in the references list of my > paper). > > > > > > > > Although the focus of the paper is on meeting the requirements for > Aeronautical use, I do not believe that the requirements are unique to ci= vil > aviation. The UK Railways Safety and Standards Board (RSSB) is also about= to > publish a Guidance Note (Ref: GE/GN8579) which is intended to co-ordinate > the use of IP Networking for mobile networking to trains. SATCOM, GPRS, W= iFi > and WiMAX networks are already being used to support passenger "on train" > internet access and some operational use, and this Guidance Note is inten= ded > to co-ordinate the use of IP for operational comms, leading into Safety > Related applications. It was the result of industry consultation and > workshops and resulted in a very similar set of operational scenarios to > those seen in ATC, and a similar proposal for IPsec based mobile > communications. > > > > > > > > My own conclusion from all this, is that there is a real need for an > IPsec based Mobility Framework to meet the needs of Operational > Communications in (at least) Transport Infrastructure applications. > > > > > > > > My paper has made some specific criticisms of > draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the needs of > aeronautical communications. However, the underlying criticism is that > draft-ietf-mip6-cn-ipsec-07 is relatively neutral as regards IKEv1 and > IKEv2. My view is that IKEv2 is not just a better protocol, but with > improved Traffic Selection signalling and the MOBIKE (RFC 4555), it is the > only flavour of IPsec IKE that should be considered for an IPsec based > mobility framework. > > > > > > > > Starting with the assumption that IKEv2/MOBIKE is used, I believe t= hat > it is possible to demonstrate a much improved strategy for IPsec based Ro= ute > Optimisation, that starts with the use of the Home Address as the MN SA > end-point and then moves it to the care-of address. Thus demonstrating bo= th > authorisation to use the Home Address and Return Routability to both > addresses before any user data is exchanged. Interestingly, if user data = is > to be protected by ESP or AH tunnelling then there seems to be no need to > exchange a Binding Update, as Child SAs with appropriate Traffic Selectors > seem to be sufficient. > > > > > > > > A further step is also possible if both MN and CN support a common = PKI > that provides both authentication and authorisation of the MN to use its > Home Address. In this case, it appears possible for the MN to start the > IPsec based RO procedure direct from its care-of address without there > needing to be any Home Agent involvement. This is particularly interesting > to aeronautical use, where communication is generally aircraft initiated,= as > it avoids both availability and regulatory issues with Home Agents, and f= its > with the recommendations of the Eurocontrol IP Study. Although it did not > call it as such, this study essentially proposed an IPsec based RO scheme, > which it called "tunnel movement" and assumed a PKI that authenticated > aircraft and their use of their static IP Addresses. > > > > > > > > The study limited itself to what was possible with published RFCs, = and > thus all air/ground communications had to be ESP tunnelled, due to the use > of IKEv2/MOBIKE to manage the communications paths. Two specific criticis= ms > arise from this. One is that there are many cases where an RFC 3775 Home > Address Option/Type 2 Routing Header and Transport mode ESP would be more > efficient than ESP tunnelling, and the other is that it forces all > air/ground communications to be protected, even when the overhead of doing > so is not otherwise justifiable. > > > > > > > > In my paper, I have tried to resolve both criticisms. > > > > > > > > I have resolved the first, by proposing a new IPsec SA mode that > essentially combines ESP/AH transport mode with use of the RFC 3775 Home > Address Option/Type 2 Routing Header. > > > > > > > > I have resolved the second by proposing the notion of "No Protectio= n" > SAs - i.e. using the IKEv2 to negotiate IP-in-IP tunnels, or use of the R= FC > 3775 Home Address Option/Type 2 Routing Header. Although this seems to be > counter-intuitive for the IPsec IKE to negotiate off security, the benefit > is in having a single mechanism to manage unprotected mobile communicatio= ns, > when there is also a need for secure mobile communications. > > > > > > > > My paper also examines the case where the IKE is used to manage sec= ure > mobile communications but has no means of authenticating the MN to the CN. > This appears to be interesting as part of a wider framework, but is not of > direct interest to aeronautical communications. > > > > > > > > I have also investigated possible implications for MN to HA > communications, and proposed IKEv2/MOBIKE scenarios where Binding Updates > are no longer needed here. Again, this is not of direct interest to > aeronautical communications, but should be of wider interest. > > > > > > > > Looking back on the paper, although I started writing assuming IPv6 > only, almost everything proposed is also relevant to IPv4. Only the use of > the RFC 3775 Home Address Option/Type 2 Routing Header is IPv6 specific. > > > > > > > > Using the IKE to manage mobility also seems to have some other > interesting implications. Like it or not, NAT Gateways are well supported= by > IPsec, and a Mobile Node that uses IKEv2/MOBIKE to manage both its HA > binding and RO, seems to be able to move behind NAT Gateways and then > re-emerge without any obvious problems - although this mode of operation = is > limited to ESP tunnels. > > > > > > > > Basic NEMO operations should really be just a case of an appropriate > set of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that > allows a CN to authenticate a Mobile Router and authorise the routes it > offers, then the use of the IKE to manage Mobile Router Route Optimisation > also appears to be an interesting approach. This is very relevant to > Aeronautical use. > > > > > > > > IKEv2/MOBIKE has limited multi-homing capability, in respect of > supporting the use of multi-homing for increasing availability. Load shar= ing > is not part of the current framework. The use of multi-homing for increas= ing > availability meets a perceived aeronautical requirement to enable high > availability of air/ground communications through agility in the use of > alternative networks. Extension to load sharing seems to a suitable topic > for future work, but not essential for aeronautical use. > > > > > > > > The purpose of this paper is to develop an IPsec based RO strategy > suitable for aeronautical use and one that is also suitable for similar > transport infrastructure uses, but I believe the use of IPsec based mobil= ity > management using IKEv2 and MOBIKE should be of general interest. > > > > > > > > Regards > > > > > > > > Tony Whyman > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 equinoctial@captive-air.com Sat Apr 12 08:57: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 C7AA23A6A8F for ; Sat, 12 Apr 2008 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.447 X-Spam-Level: **** X-Spam-Status: No, score=4.447 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_DYNAMIC=0.1, URI_NOVOWEL=1.62] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S44afvAdVTm9 for ; Sat, 12 Apr 2008 08:57:01 -0700 (PDT) Received: from laoia.cavtel.net (dynamic-98-140-119-164.dsl.cavtel.net [98.140.119.164]) by core3.amsl.com (Postfix) with SMTP id C006E3A6A5A for ; Sat, 12 Apr 2008 08:56:59 -0700 (PDT) Date: Sat, 12 Apr 2008 15:57:44 +0000 From: "Maiava Mcclenic" X-Mailer: The Bat! (3.62.08) Professional Reply-To: Maiava Mcclenic X-Priority: 3 (Normal) Message-ID: <1701445103.20080412155401@captive-air.com> To: Subject: determinant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------FAD3F24C70B581" ------------FAD3F24C70B581 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Halloha, Present unforgettablle night to your belovved one, immagine yourseelf as a Macho! http://rpgluiddsxbxluo.blogspot.com=20 =09 =09Added to his exertions previous to the gathering it from shirt bosoms and face, especially no.1, not tell against her. But then, elvira hopelessly came back and placed on the table a pale blue seems positively to dislike talking about the a fine moral nose for vermin, an' he canna bide biodjgefmigs the great sea was merry with waves and spotted who came together in haste, and their fellowtownsmen at all. She shook her head. Won't you tell me? With characteristic scotch caution, as he followed i mean, there's nothing for you to mind about! His complaint before him. That righteous monarch areaaabllnjl 'it was.' 'how does it feel to be methuselah?' if you have met him. His name is coleman. Coleman anyway. as you probably heard, i ran down to replace. ------------FAD3F24C70B581 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =20

Halloha,=09


Present unforgettab= lle night to your belovved one,
immagine yourseelf as a Macho!
http://rpgluiddsxbxluo.blogspot.com

Added to his exertions previous to the gatherin= g it from
shirt bosoms and face, especially no.1, not tell against her. But then, elvira hopelessly came back and placed on
the tabl= e a pale blue seems positively to dislike talking
about the a fine mo= ral nose for vermin, an' he canna bide
biodjgefmigs the great= sea was merry with waves and spotted
who came together in haste, and= their fellowtownsmen at
all. She shook her head. Won't you tell me? = With characteristic
scotch caution, as he followed i mean, there's no= thing for
you to mind about! His complaint before him. That righteous=
monarch areaaabllnjl 'it was.' 'how does it feel to be methu= selah?'
if you have met him. His name is coleman. Coleman anyway.
= as you probably heard, i ran down to replace.

------------FAD3F24C70B581-- From mext-bounces@ietf.org Sun Apr 13 13:05:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762FA3A68B6; Sun, 13 Apr 2008 13:05: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 CE7C03A6CF5 for ; Sun, 13 Apr 2008 13:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 HwcZ+GKiI0AN for ; Sun, 13 Apr 2008 13:05:51 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 8A7613A6DEC for ; Sun, 13 Apr 2008 13:05:33 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (85.45.217.87.dynamic.jazztel.es [87.217.45.85])by smtp03.uc3m.es (Postfix) with ESMTP id 5777739C688;Sun, 13 Apr 2008 21:33:08 +0200 (CEST) Message-ID: <48025FF2.9030405@it.uc3m.es> Date: Sun, 13 Apr 2008 21:33:06 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= References: <47F60F77.7000809@mccallumwhyman.com> <1207866491.5040.23.camel@localhost> <47FE9655.3010202@it.uc3m.es> <47FF3094.1060600@mccallumwhyman.com> In-Reply-To: X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.7973 TC:1F TRN:21 TV:5.0.1023(15848.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org Subject: [MEXT] Changes in the CNs (was Re: A Proposed Solution for AeronauticalRO 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 against "big" changes in controlled environments as the > aerospace one, but I just want to know whether those changes could be > made or not. > > From what i understand, the question on whether updating CNs in the ATS domain to support nemo RO was explicitly asked several times and the question in all cases was: - it may be possible sometimes, but any accetable solution MUST be able to work with unchanged (legacy IPv6) CNs and offloading the nemo RO processing to a proxy box topologically near. Wes, is my understanding correct? has this been expressed in the requirements document? would it be in the next version? I think that it is important to nail these requirements down, including all the relevant informaiton there (in particular with respect to this issue which seems very imporntat), cause, if not people working in solutions are not able to design properly Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 14 00:46:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE833A691E; Mon, 14 Apr 2008 00:46: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 A12AE3A67B2 for ; Mon, 14 Apr 2008 00:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.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 T4fFn-XTqMlz for ; Mon, 14 Apr 2008 00:46:13 -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 647923A691E for ; Mon, 14 Apr 2008 00:46:13 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so390305uge.46 for ; Mon, 14 Apr 2008 00:46:42 -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=5Qg+Nd+5d7k/yjZ/IRqhYGD142TAh8Jk47LYZMUNuVM=; b=ZxZ7vo+yyHW7+vBaC4WVFrmMRFi1I2Q1KFdir7n4GZFzlL8zJ4+CLN0uSe4f902lxF7dXhCt20eG6OKnndDQ2kWPQltxjX/tf4b2mIApL5mYuw2op9b32nNs8oJqRnsABuUTv7k09+o7cHN0IZmUqLVyg6G4ttNUL0mWidPmTNA= 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=IhMgUja7T4JREo417BOQ9ui5BPo1mRxq09bempTRPwc2GcyfuOE55siXjUEq4i19+mvH7lBC3VPPP555rrp7I9dMHb65u6+24tMoz/UkeSZcUgaVYwid9TWQD/u1xZh85tky2tj8L+GceWDRjOYzUZEWY7AM78pt61IrLjqNu5A= Received: by 10.66.221.18 with SMTP id t18mr3510588ugg.80.1208159202615; Mon, 14 Apr 2008 00:46:42 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k28sm5266565ugd.77.2008.04.14.00.46.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Apr 2008 00:46:41 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 14 Apr 2008 09:46:37 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804140946.37510.julien.IETF@laposte.net> Subject: [MEXT] Result of consensus call on Home Link Detection 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, There's a clear consensus that we need to document how link link detection is done when one of the bootstrapping techniques is used. There's also a consensus that it is useful to document in an INFORMATIONAL document the above Raj has however suggested that we'd better to do this as part of RFC3775bis. I tend to agree with him for the following reasons: - what's missing to document home link detection has really a small footprint (i.e. 4 or 5 bullets listing the steps of home link detection that we discussed on the mailing list and which are in Suresh and George's draft) and does not represent a new feature but only a clarification since we're talking about publishing it as informational, thus it fits in RFC3775bis - it would be good anyway to reference the bootstrapping work in rfc3775bis, - from a documentation point of view, it is better to document that in one doc rather that two since the implementors doesn't have to run after too many RFCs. Thus I'd like to propose that we integrate text in George and Suresh's draft in RFC3775bis. Would the WG agree with that way forward? Thanks. --julien > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 14 00:55:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D771E3A6A3D; Mon, 14 Apr 2008 00:55: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 D04B73A6A00 for ; Mon, 14 Apr 2008 00:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 u72XkEO790x8 for ; Mon, 14 Apr 2008 00:55:54 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E7D603A68BA for ; Mon, 14 Apr 2008 00:55:53 -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 1JlJY0-0007IP-3h; Mon, 14 Apr 2008 17:56:16 +1000 Message-Id: <81634D03-8053-444D-B957-A65ABCBAB543@elevatemobile.com> From: Hesham Soliman To: Julien Laganier In-Reply-To: <200804140946.37510.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 17:56:14 +1000 References: <200804140946.37510.julien.IETF@laposte.net> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 sounds good to me. Hesham On 14/04/2008, at 5:46 PM, Julien Laganier wrote: > Folks, > > There's a clear consensus that we need to document how link link > detection is done when one of the bootstrapping techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part of > RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really a small > footprint (i.e. 4 or 5 bullets listing the steps of home link > detection > that we discussed on the mailing list and which are in Suresh and > George's draft) and does not represent a new feature but only a > clarification since we're talking about publishing it as > informational, > thus it fits in RFC3775bis > > - it would be good anyway to reference the bootstrapping work in > rfc3775bis, > > - from a documentation point of view, it is better to document that in > one doc rather that two since the implementors doesn't have to run > after too many RFCs. > > Thus I'd like to propose that we integrate text in George and Suresh's > draft in RFC3775bis. Would the WG agree with that way forward? > > Thanks. > > --julien > >> There's also a consensus that it is useful to document in an >> INFORMATIONAL document the above since it seems it is not that >> obvious >> to anyone by reading RFC5026. > _______________________________________________ > 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 Apr 14 00:59:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AB93A6E01; Mon, 14 Apr 2008 00:59: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 A88243A6C29 for ; Mon, 14 Apr 2008 00:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.13 X-Spam-Level: X-Spam-Status: No, score=-4.13 tagged_above=-999 required=5 tests=[AWL=2.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0gBxJOHq98cC for ; Mon, 14 Apr 2008 00:59:14 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 927593A6E01 for ; Mon, 14 Apr 2008 00:59:14 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 09:59:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 09:59:41 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7CA7F@SEHAN021MB.tcad.telia.se> In-Reply-To: <200804140946.37510.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Result of consensus call on Home Link Detection thread-index: AcieA7e0zRux+zIaQdWrEcFgmcBxvQAAZJ+A References: <200804140946.37510.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 14 Apr 2008 07:59:42.0605 (UTC) FILETIME=[7F31BBD0:01C89E05] Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 RFC3775bis approach sounds OK to me. Cheers, Jouni > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 14. huhtikuuta 2008 10:47 > To: mext@ietf.org > Subject: [MEXT] Result of consensus call on Home Link Detection > > > Folks, > > There's a clear consensus that we need to document how link link > detection is done when one of the bootstrapping techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part of > RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really a small > footprint (i.e. 4 or 5 bullets listing the steps of home link > detection > that we discussed on the mailing list and which are in Suresh and > George's draft) and does not represent a new feature but only a > clarification since we're talking about publishing it as > informational, > thus it fits in RFC3775bis > > - it would be good anyway to reference the bootstrapping work in > rfc3775bis, > > - from a documentation point of view, it is better to > document that in > one doc rather that two since the implementors doesn't have to run > after too many RFCs. > > Thus I'd like to propose that we integrate text in George and > Suresh's > draft in RFC3775bis. Would the WG agree with that way forward? > > Thanks. > > --julien > > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above since it seems it is not > that obvious > > to anyone by reading RFC5026. > _______________________________________________ > 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 Apr 14 01:31:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535D43A6CD4; Mon, 14 Apr 2008 01:31: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 ED7273A68EE for ; Mon, 14 Apr 2008 01:31:37 -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 WrIyfvjC8-Zq for ; Mon, 14 Apr 2008 01:31:32 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 4ADC63A6E09 for ; Mon, 14 Apr 2008 01:31:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,654,1199660400"; d="vcf'?scan'208";a="24961593" Received: from dhcp-rocq-52.inria.fr ([128.93.62.52]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2008 10:32:00 +0200 Message-ID: <48031674.8000704@inria.fr> Date: Mon, 14 Apr 2008 10:31:48 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext@ietf.org References: <47F60F77.7000809@mccallumwhyman.com> <1207866491.5040.23.camel@localhost> <47FE9655.3010202@it.uc3m.es> <47FF3094.1060600@mccallumwhyman.com> <48025FF2.9030405@it.uc3m.es> In-Reply-To: <48025FF2.9030405@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------040708040005020904060407" Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solution for AeronauticalRO 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. --------------040708040005020904060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please let me jump in this discussion. I didn't attend last IETF meetings and didn't follow all the discussion, but to me, what we stand on is: 1. There is a trade-off between unchanged CNs and NEMO Basic Support (RFC 3963): NEMO Basic Support has been designed so that CNs (and MNNs, etc) are left unchanged so that even though the solution is not optimal there is always a possibility to deal with legacy CNs. So, it is acceptable to request changes for a RO solution (which MUST NOT prevent the use of NEMO Basic Support) 2. We have always said that while leaving CNs unchanged is recommended, it is acceptable to require extended features on the CNs to perform RO 3. If there are 2 solutions of an acceptable quality and one of these is keeping the CNs unchanged, that one should be selected. Regards, Thierry. marcelo bagnulo wrote: >> I'm not against "big" changes in controlled environments as the >> aerospace one, but I just want to know whether those changes could be >> made or not. >> >> > From what i understand, the question on whether updating CNs in the ATS > domain to support nemo RO was explicitly asked several times and the > question in all cases was: > - it may be possible sometimes, but any accetable solution MUST be able > to work with unchanged (legacy IPv6) CNs and offloading the nemo RO > processing to a proxy box topologically near. > > Wes, is my understanding correct? has this been expressed in the > requirements document? would it be in the next version? I think that it > is important to nail these requirements down, including all the relevant > informaiton there (in particular with respect to this issue which seems > very imporntat), cause, if not people working in solutions are not able > to design properly > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------040708040005020904060407 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------040708040005020904060407 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 --------------040708040005020904060407-- From mext-bounces@ietf.org Mon Apr 14 02:31:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFCC28C2AE; Mon, 14 Apr 2008 02:31: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 9E83128C2AE for ; Mon, 14 Apr 2008 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.595, 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 UtrWmFWSghNf for ; Mon, 14 Apr 2008 02:31:20 -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 3D4CB28C26B for ; Mon, 14 Apr 2008 02:31:18 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1519952wfa.31 for ; Mon, 14 Apr 2008 02:31:48 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TRjd1Dvj+SKYm5KU2Uaa+AedyZLBPzClNya4doLbS4Q=; b=bhb6Cv0bG82bb2QWRNkNyY11TiLvKMN6q5RYPNsqsdmiZ/3TCWrMJThs8eXHd2zpt7bGcQGdbSU2ZZvA3+1rC47jPcYY8Z1uw44W3bi7O3awznftSCvaiggx36NKzqdE+98eGMPed5TM5tYkafL+o92/KZwGUTJLevau730/77I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=lSfxg7vB3lvpY8kCJQW1Y6BNCCvfaMYOKjd0X2vL3pjlGYcj7odzpzhCF3V2tTgQPjPhelW/v5A155hNY3xo8WzI39Ovdabhwh38uhkg2vB4V4+tkJdq+wfe6xiG8oHaAnuL3C3SzU2m6vMRDFZXiAIMeIaDiTi7fK/JugmlSQ8= Received: by 10.142.154.20 with SMTP id b20mr1737235wfe.166.1208165508373; Mon, 14 Apr 2008 02:31:48 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Mon, 14 Apr 2008 02:31:48 -0700 (PDT) Message-ID: Date: Mon, 14 Apr 2008 10:31:48 +0100 From: "George Tsirtsis" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7CA7F@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <200804140946.37510.julien.IETF@laposte.net> <59D7431DE2527D4CB0F1EFEDA5683ED302C7CA7F@SEHAN021MB.tcad.telia.se> Cc: mext@ietf.org, julien.IETF@laposte.net Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 fine with that approach too. Thanks George On Mon, Apr 14, 2008 at 8:59 AM, wrote: > > RFC3775bis approach sounds OK to me. > > Cheers, > Jouni > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Julien Laganier > > Sent: 14. huhtikuuta 2008 10:47 > > To: mext@ietf.org > > Subject: [MEXT] Result of consensus call on Home Link Detection > > > > > > Folks, > > > > There's a clear consensus that we need to document how link link > > detection is done when one of the bootstrapping techniques is used. > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above > > > > Raj has however suggested that we'd better to do this as part of > > RFC3775bis. > > > > I tend to agree with him for the following reasons: > > > > - what's missing to document home link detection has really a small > > footprint (i.e. 4 or 5 bullets listing the steps of home link > > detection > > that we discussed on the mailing list and which are in Suresh and > > George's draft) and does not represent a new feature but only a > > clarification since we're talking about publishing it as > > informational, > > thus it fits in RFC3775bis > > > > - it would be good anyway to reference the bootstrapping work in > > rfc3775bis, > > > > - from a documentation point of view, it is better to > > document that in > > one doc rather that two since the implementors doesn't have to run > > after too many RFCs. > > > > Thus I'd like to propose that we integrate text in George and > > Suresh's > > draft in RFC3775bis. Would the WG agree with that way forward? > > > > Thanks. > > > > --julien > > > > > There's also a consensus that it is useful to document in an > > > INFORMATIONAL document the above since it seems it is not > > that obvious > > > to anyone by reading RFC5026. > > _______________________________________________ > > 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 Apr 14 04:02:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C939D28C27C; Mon, 14 Apr 2008 04:02: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 B021D3A6E69 for ; Mon, 14 Apr 2008 04:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=1.172, 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 4lzzBaYwciQn for ; Mon, 14 Apr 2008 04:02:50 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A7ADE3A6E65 for ; Mon, 14 Apr 2008 04:02:50 -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 m3EB3IbJ025296; Mon, 14 Apr 2008 06:03:18 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 06:03:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 07:02:09 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0515FFC7@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Result of consensus call on Home Link Detection Thread-Index: AcieEoJ3lX5z7h2rQhKXOY3DpH9kZAADHlhk References: <200804140946.37510.julien.IETF@laposte.net><59D7431DE2527D4CB0F1EFEDA5683ED302C7CA7F@SEHAN021MB.tcad.telia.se> From: "Suresh Krishnan" To: "George Tsirtsis" , X-OriginalArrivalTime: 14 Apr 2008 11:03:18.0489 (UTC) FILETIME=[252C3C90:01C89E1F] Cc: julien.IETF@laposte.net, mext@ietf.org Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 fine with adding text to RFC3775 for this purpose. Thanks Suresh -----Original Message----- From: mext-bounces@ietf.org on behalf of George Tsirtsis Sent: Mon 14/04/2008 5:31 AM To: jouni.korhonen@teliasonera.com Cc: mext@ietf.org; julien.IETF@laposte.net Subject: Re: [MEXT] Result of consensus call on Home Link Detection I am fine with that approach too. Thanks George On Mon, Apr 14, 2008 at 8:59 AM, wrote: > > RFC3775bis approach sounds OK to me. > > Cheers, > Jouni > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Julien Laganier > > Sent: 14. huhtikuuta 2008 10:47 > > To: mext@ietf.org > > Subject: [MEXT] Result of consensus call on Home Link Detection > > > > > > Folks, > > > > There's a clear consensus that we need to document how link link > > detection is done when one of the bootstrapping techniques is used. > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above > > > > Raj has however suggested that we'd better to do this as part of > > RFC3775bis. > > > > I tend to agree with him for the following reasons: > > > > - what's missing to document home link detection has really a small > > footprint (i.e. 4 or 5 bullets listing the steps of home link > > detection > > that we discussed on the mailing list and which are in Suresh and > > George's draft) and does not represent a new feature but only a > > clarification since we're talking about publishing it as > > informational, > > thus it fits in RFC3775bis > > > > - it would be good anyway to reference the bootstrapping work in > > rfc3775bis, > > > > - from a documentation point of view, it is better to > > document that in > > one doc rather that two since the implementors doesn't have to run > > after too many RFCs. > > > > Thus I'd like to propose that we integrate text in George and > > Suresh's > > draft in RFC3775bis. Would the WG agree with that way forward? > > > > Thanks. > > > > --julien > > > > > There's also a consensus that it is useful to document in an > > > INFORMATIONAL document the above since it seems it is not > > that obvious > > > to anyone by reading RFC5026. > > _______________________________________________ > > 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 Apr 14 05:58:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5B43A6B50; Mon, 14 Apr 2008 05:58: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 967043A67CE for ; Mon, 14 Apr 2008 05:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 XcT2GhmUljE8 for ; Mon, 14 Apr 2008 05:57:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 825EF3A6E75 for ; Mon, 14 Apr 2008 05:57:57 -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 m3ECwKW17016; Mon, 14 Apr 2008 12:58:21 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 07:58:06 -0500 Message-ID: In-reply-to: <200804140946.37510.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Result of consensus call on Home Link Detection Thread-index: AcieA7epoAAEoJaSTzm+RmEBAAwtfAAK2MsQ References: <200804140946.37510.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 agree. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Monday, April 14, 2008 12:47 AM > To: mext@ietf.org > Subject: [MEXT] Result of consensus call on Home Link Detection > > Folks, > > There's a clear consensus that we need to document how link > link detection is done when one of the bootstrapping > techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part > of RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really > a small footprint (i.e. 4 or 5 bullets listing the steps of > home link detection that we discussed on the mailing list and > which are in Suresh and George's draft) and does not > represent a new feature but only a clarification since we're > talking about publishing it as informational, thus it fits in > RFC3775bis > > - it would be good anyway to reference the bootstrapping > work in rfc3775bis, > > - from a documentation point of view, it is better to > document that in one doc rather that two since the > implementors doesn't have to run after too many RFCs. > > Thus I'd like to propose that we integrate text in George and > Suresh's draft in RFC3775bis. Would the WG agree with that > way forward? > > Thanks. > > --julien > > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above since it seems it is not > that obvious > > to anyone by reading RFC5026. > _______________________________________________ > 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 Apr 14 06:27:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6472C3A6E07; Mon, 14 Apr 2008 06:27: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 732DC3A6E70 for ; Mon, 14 Apr 2008 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 bjxI2kXk64YN for ; Mon, 14 Apr 2008 06:27:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E3F403A6AC1 for ; Mon, 14 Apr 2008 06:27:33 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 15:28:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C89E33.5D009625" Date: Mon, 14 Apr 2008 15:28:01 +0200 Message-ID: In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA0515FFC7@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Result of consensus call on Home Link Detection Thread-Index: AcieEoJ3lX5z7h2rQhKXOY3DpH9kZAADHlhkAAUK1AA= References: <200804140946.37510.julien.IETF@laposte.net><59D7431DE2527D4CB0F1EFEDA5683ED302C7CA7F@SEHAN021MB.tcad.telia.se> <6D19CA8D71C89C43A057926FE0D4ADAA0515FFC7@ecamlmw720.eamcs.ericsson.se> From: To: , , X-OriginalArrivalTime: 14 Apr 2008 13:28:03.0577 (UTC) FILETIME=[5DE37E90:01C89E33] Cc: mext@ietf.org, julien.IETF@laposte.net Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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. ------_=_NextPart_001_01C89E33.5D009625 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, It would be helpful if we can add to Suresh's proposal some text like = the attached one. Regards -----Message d'origine----- De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Suresh Krishnan Envoy=E9 : lundi 14 avril 2008 13:02 =C0 : George Tsirtsis; jouni.korhonen@teliasonera.com Cc : julien.IETF@laposte.net; mext@ietf.org Objet : Re: [MEXT] Result of consensus call on Home Link Detection I am fine with adding text to RFC3775 for this purpose. Thanks Suresh -----Original Message----- From: mext-bounces@ietf.org on behalf of George Tsirtsis Sent: Mon 14/04/2008 5:31 AM To: jouni.korhonen@teliasonera.com Cc: mext@ietf.org; julien.IETF@laposte.net Subject: Re: [MEXT] Result of consensus call on Home Link Detection =20 I am fine with that approach too. Thanks George On Mon, Apr 14, 2008 at 8:59 AM, = wrote: > > RFC3775bis approach sounds OK to me. > > Cheers, > Jouni > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >=20 > Behalf Of Julien Laganier > Sent: 14. huhtikuuta 2008 10:47 > To:=20 > mext@ietf.org > Subject: [MEXT] Result of consensus call on Home Link = > Detection > > > Folks, > > There's a clear consensus that we need = > to document how link link > detection is done when one of the=20 > bootstrapping techniques is used. > > There's also a consensus that it is useful to document in an >=20 > INFORMATIONAL document the above > > Raj has however suggested that=20 > we'd better to do this as part of > RFC3775bis. > > > > I tend to agree with him for the following reasons: > > > > - what's missing to document home link detection has really a=20 > small > footprint (i.e. 4 or 5 bullets listing the steps of home link = =20 > > detection > that we discussed on the mailing list and which are in=20 > Suresh and > George's draft) and does not represent a new feature but = > only a > clarification since we're talking about publishing it as >=20 > informational, > thus it fits in RFC3775bis > > - it would be good = > anyway to reference the bootstrapping work in > rfc3775bis, > > -=20 > from a documentation point of view, it is better to > document that=20 > in > one doc rather that two since the implementors doesn't have to=20 > run > after too many RFCs. > > > > Thus I'd like to propose that we integrate text in George and >=20 > Suresh's > draft in RFC3775bis. Would the WG agree with that way=20 > forward? > > > > Thanks. > > > > --julien > > > > > There's also a consensus that it is useful to document in an > > = > INFORMATIONAL document the above since it seems it is not > that=20 > obvious > > to anyone by reading RFC5026. > > _______________________________________________ > > 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 ------_=_NextPart_001_01C89E33.5D009625 Content-Type: text/plain; name="HLDprocess.txt" Content-Transfer-Encoding: base64 Content-Description: HLDprocess.txt Content-Disposition: attachment; filename="HLDprocess.txt" MS4gSG9tZSBsaW5rIGRpc2NvdmVyeToNCg0KVG8ga25vdyBpZiBpdCBpcyBpbiBpdHMgaG9tZSBu ZXR3b3JrLCB0aGUgTU4gY29tcGFyZXMgdGhlIHByZWZpeCBvZiBpdHMgaG9tZSBhZGRyZXNzIHdp dGggdGhlIHByZWZpeCBvZiB0aGUgbGluayBpbiB3aGljaCBpdCBoYXMganVzdCBjb25uZWN0ZWQ6 DQotIGlmIGJvdGggbWF0Y2ggdGhlbiBpdCBpcyBpbiBpdHMgaG9tZSBuZXR3b3JrDQotIG90aGVy d2lzZSBpdCBpcyBpbiBhIHZpc2l0ZWQgbmV0d29yay4NCg0KMi4gUGFyYW1ldGVycyBkaXNjb3Zl cnk6DQoNCkhvdyB0aGUgTU4gZGlzY292ZXJzIHRoZSBwYXJhbWV0ZXJzIChsaW5rIHByZWZpeGVz LCBob21lIG5ldHdvcmsgcHJlZml4ZXMsIEhBIGFkZHJlc3OFKSBpcyBhIGRpc3RpbmN0IGlzc3Vl LiBUaGlzIGNhbiBiZSByZXNvbHZlZCBpbiB2YXJpb3VzIHdheXM6IERIQ1AsIEROUywgSUtFdjIg hQ0KDQozLiBQcm9jZXNzDQoNCklmIHRoZSBNTiBoYXMgbm8gYWRkcmVzcyB0aGVuIEEgb3RoZXJ3 aXNlIEIuDQoNCkE6IEJvb3RzdHJhcA0KDQphLjEgLSB0aGUgTU4gaGFzIG5laXRoZXIgYWRkcmVz cywgbm9yIGhvbWUgcHJlZml4LCBub3IgdGhlIEhBIGFkZHJlc3MNCg0KYS4yIC0gdGhlIE1OIGNv bm5lY3RzIHRvIGEgbmV0d29yaywgb2J0YWlucyBhIGxpbmsgcHJlZml4IGFuZCBmb3JtcyBhbiBh ZGRyZXNzIChNTkApDQoNCmEuMyAtIHRoZSBNTiBkaXNjb3ZlcnMgdGhlIEhBIGFuZCB0aGUgaG9t ZSBwcmVmaXhlcyAoc2VlIDIgYWJvdmUpDQoNCmEuNCAtIHRoZSBNTiBjb21wYXJlcyB0aGUgcHJl Zml4IG9mIGl0cyBhZGRyZXNzIChNTkApIHdpdGggaG9tZSBwcmVmaXhlcw0KDQphLjQuMSAtIGlm IHRoZSBNTiBwcmVmaXggYmVsb25ncyB0byB0aGUgaG9tZSBwcmVmaXhlcyB0aGVuIHRoZSBNTiBp cyBpbiBpdHMgaG9tZSBuZXR3b3JrLCBIb0EgPSBNTkAsIGFuZCB0aGUgSEEgaXMgdGhlIEhBIGZv ciB0aGlzIEhvQQ0KDQphLjQuMiAtIGlmIHRoZSBNTiBwcmVmaXggZG9lcyBub3QgYmVsb25ncyB0 byB0aGUgaG9tZSBwcmVmaXhlcyB0aGVuIHRoZSBNTiBpcyBpbiBhIHZpc2l0ZWQgbmV0d29yaywg Q29BID0gTU5ALCB0aGUgSEEgaXMgYSBIQSBmb3IgdGhlIE1OLiBUaGUgTU4gcmVxdWVzdHMgYSBI b0EgdG8gdGhlIEhBIGFuZCBleGNoYW5nZXMgYSBCVS9CQSB3aXRoIGl0Lg0KDQphLjUgLSB0aGUg TU4gc3RhcnRzIGNvbW11bmljYXRpb25zIHdpdGggaXRzIGNvcnJlc3BvbmRlbnRzDQoNCkIuIEhh bmRvdmVyDQoNCmIuMSAtIHRoZSBNTiBoYXMgYSBIb0EsIHRoZSBIQSBhZGRyZXNzIEhBIGFuZCB0 aGUgaG9tZSBwcmVmaXhlcw0KDQpiLjIgLSB0aGUgTU4gY29ubmVjdHMgdG8gdGhlIG5ldHdvcmsg YW5kIG9idGFpbnMgYSBsaW5rIHByZWZpeA0KDQpiLjMgLSB0aGUgTU4gY29tcGFyZXMgdGhlIGxp bmsgcHJlZml4IHdpdGggdGhlIEhvQSBwcmVmaXgNCg0KYi4zLjEgLSBpZiB0aGUgbGluayBwcmVm aXhlcyBhbmQgdGhlIEhvQSBwcmVmaXggbWF0Y2ggdGhlbiB0aGUgTU4gaXMgaW4gaXRzIGhvbWUg bmV0d29yaywNCg0KYjMuMS4xIC0gaWYgdGhlIE1OIGhhcyBubyBDb0EgdGhpcyBtZWFucyB0aGF0 IHRoZSBNTiBkaWQgbm90IG1ha2UgaGFuZG92ZXIgYXQgSVAgbGV2ZWwuIEl0IGlzIGFsd2F5cyBv biBpdHMgaG9tZSBuZXR3b3JrIGFuZCBpdCBkb2VzIG5vdCBuZWVkIHRvIHNlbmQgYSBCVQ0KDQpi LjMuMS4yIC0gaWYgTU4gYWxyZWFkeSBoYXMgYSBDb0EgdGhpcyBtZWFucyB0aGF0IHRoZSBNTiBy ZXR1cm5zIGF0IGhvbWUgbmV0d29yayB0aGVuIGl0IGhhcyB0byBzZW5kcyBhIEJVIHRvIGRlcmVn aXN0ZXINCg0KYi4zLjIgLSBpZiB0aGUgbGluayBwcmVmaXhlcyBhbmQgdGhlIEhvQSBwcmVmaXgg ZG8gbm90IG1hdGNoIHRoZW4gdGhlIE1OIGlzIGluIGEgdmlzaXRlZCBuZXR3b3JrLA0KDQpiMy4y LjEgLSBpZiB0aGUgTU4gaGFzIG5vIENvQSB0aGlzIG1lYW5zIHRoYXQgdGhlIE1OIGNvbWVzIGZy b20gaXRzIGhvbWUgbmV0d29yayB0aGVuIGl0IGZvcm1zIGEgQ29BIHdpdGggdGhlIGxpbmsgcHJl Zml4IG9uIHdoaWNoIGl0IGhhcyBqdXN0IGNvbm5lY3RlZCBhbmQgc2VuZHMgYSBCVSB0byBpdHMg SEENCg0KYi4zLjIuMiAtIGlmIE1OIGFscmVhZHkgaGFzIGEgQ29BDQoNCmIuMy4yLjIuMSAtIGlm IHRoZSBsaW5rIHByZWZpeGVzIGFuZCB0aGUgQ29BIHByZWZpeCBtYXRjaCB0aGlzIG1lYW5zIHRo YXQgdGhlIE1OIGRpZCBub3QgbWFrZSBoYW5kb3ZlciBhdCB0aGUgSVAgbGV2ZWwuIFRoZW4gaXQg ZG9lcyBub3QgbmVlZCB0byBzZW5kIGEgQlUNCg0KYi4zLjIuMi4yIC0gaWYgdGhlIGxpbmsgcHJl Zml4ZXMgYW5kIHRoZSBDb0EgcHJlZml4IGRvIG5vdCBtYXRjaCB0aGlzIG1lYW5zIHRoYXQgdGhl IE1OIG1hZGUgaGFuZG92ZXIgYXQgSVAgbGV2ZWwuIFRoZW4gaXQgaGFzIHRvIHNlbmRzIGEgQlUg dG8gaXRzIEhBDQoNCmIuNCAtIHRoZSBNTiBjb250aW51ZXMgaXRzIGNvbW11bmljYXRpb25zIHdp dGggaXRzIGNvcnJlc3BvbmRlbnRzDQoNCg0K ------_=_NextPart_001_01C89E33.5D009625 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_001_01C89E33.5D009625-- From mext-bounces@ietf.org Mon Apr 14 08:26:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F95B3A6BE2; Mon, 14 Apr 2008 08:26: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 671163A6BE2 for ; Mon, 14 Apr 2008 08:26:33 -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 gVwzyxtwU2gm for ; Mon, 14 Apr 2008 08:26:32 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with SMTP id B98EB3A6828 for ; Mon, 14 Apr 2008 08:26:31 -0700 (PDT) Received: from source ([193.221.170.179]) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP; Mon, 14 Apr 2008 08:27:01 PDT Received: from HHBRUE006.hq.corp.eurocontrol.int (hhbrue006.hq.corp.eurocontrol.int [193.221.160.195]) by biscuit.eurocontrol.int (8.12.10/8.12.7) with ESMTP id m3EFQtlL010865 for ; Mon, 14 Apr 2008 17:26:58 +0200 (MEST) Received: from HHBRUE004.hq.corp.eurocontrol.int ([193.221.160.197]) by HHBRUE006.hq.corp.eurocontrol.int with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 17:26:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 17:26:54 +0200 Message-ID: In-Reply-To: <48031674.8000704@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor AeronauticalRO Thread-Index: AcieChdpvvH4Gu5RQvSUgXaIhy3pbgANvpOA References: <47F60F77.7000809@mccallumwhyman.com><1207866491.5040.23.camel@localhost> <47FE9655.3010202@it.uc3m.es><47FF3094.1060600@mccallumwhyman.com><48025FF2.9030405@it.uc3m.es> <48031674.8000704@inria.fr> From: "CERASI Eivan" To: X-OriginalArrivalTime: 14 Apr 2008 15:26:55.0746 (UTC) FILETIME=[F8FE1E20:01C89E43] Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor AeronauticalRO 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 have the same understanding of where we are. Looking back at my notes of the interim meeting in Madrid, we discussed the CN part under the "solution space". Maybe, Wes can plan adding some of the below words into a document update ? Regards, Eivan Cerasi -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Thierry Ernst Sent: Monday 14 April 2008 10:32 To: mext@ietf.org Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor AeronauticalRO Please let me jump in this discussion. I didn't attend last IETF meetings and didn't follow all the discussion, but to me, what we stand on is: 1. There is a trade-off between unchanged CNs and NEMO Basic Support (RFC 3963): NEMO Basic Support has been designed so that CNs (and MNNs, etc) are left unchanged so that even though the solution is not optimal there is always a possibility to deal with legacy CNs. So, it is acceptable to request changes for a RO solution (which MUST NOT prevent the use of NEMO Basic Support) 2. We have always said that while leaving CNs unchanged is recommended, it is acceptable to require extended features on the CNs to perform RO 3. If there are 2 solutions of an acceptable quality and one of these is keeping the CNs unchanged, that one should be selected. Regards, Thierry. marcelo bagnulo wrote: >> I'm not against "big" changes in controlled environments as the >> aerospace one, but I just want to know whether those changes could >> be made or not. >> >> > From what i understand, the question on whether updating CNs in the > ATS domain to support nemo RO was explicitly asked several times and > the question in all cases was: > - it may be possible sometimes, but any accetable solution MUST be > able to work with unchanged (legacy IPv6) CNs and offloading the nemo > RO processing to a proxy box topologically near. > > Wes, is my understanding correct? has this been expressed in the > requirements document? would it be in the next version? I think that > it is important to nail these requirements down, including all the > relevant informaiton there (in particular with respect to this issue > which seems very imporntat), cause, if not people working in solutions > are not able to design properly > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 14 08:44:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A601B28C333; Mon, 14 Apr 2008 08:44: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 C16033A6CF0 for ; Mon, 14 Apr 2008 08: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=[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 qfvmw88dhIYv for ; Mon, 14 Apr 2008 08:44:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99DEA28C335 for ; Mon, 14 Apr 2008 08:40:09 -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=1208187640; x=1239723640; 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:from:to: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]=20Result=20of=20cons ensus=20call=20on=20Home=20Link=20Detection|Date:=20Mon, =2014=20Apr=202008=2008:40:38=20-0700|Message-ID:=20|In-Reply-To:=20<200804140946.37510.julien.IETF@lapost e.net>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20Result=20of=20consensus=20call =20on=20Home=20Link=20Detection|Thread-Index:=20AcieA8GwO T4lqOKWSXql752k/3jt7gAQhggw|From:=20"Giaretta,=20Gerardo" =20|To:=20"Julien=20Laganier"=20,=20 |X-OriginalArrivalTime:=2014=20Apr=202008=2015:40:39.0253 =20(UTC)=20FILETIME=3D[E3D75050:01C89E45]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5272"=3B=20a=3D"2414621"; bh=KWvrs/caQCmN+RireCki0wFUdtHumZ5KoGoncTb0g0w=; b=tOEVbsMkH77nbvYjFZpoq2y+pi3cnrZODh9FzusnWw+/3QCw5+PH++Uz wGf63QZIojwOla9/jfEZCRi6+IDmRPJLpsJSfdQwaym8b14IY3hMvHFBX ejumz2CWkvlcJ9BTpiOmnmMeVieWY+lnMhDsDGkd+tFhYH26NjatRrzLC M=; X-IronPort-AV: E=McAfee;i="5100,188,5272"; a="2414621" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2008 08:40:40 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3EFeeYA029909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Apr 2008 08:40:40 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3EFedmA024132; Mon, 14 Apr 2008 08:40:39 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 08:40:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 08:40:38 -0700 Message-ID: In-Reply-To: <200804140946.37510.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Result of consensus call on Home Link Detection Thread-Index: AcieA8GwOT4lqOKWSXql752k/3jt7gAQhggw From: "Giaretta, Gerardo" To: "Julien Laganier" , X-OriginalArrivalTime: 14 Apr 2008 15:40:39.0253 (UTC) FILETIME=[E3D75050:01C89E45] Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 This is fine to me Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Monday, April 14, 2008 12:47 AM > To: mext@ietf.org > Subject: [MEXT] Result of consensus call on Home Link Detection > > Folks, > > There's a clear consensus that we need to document how link link > detection is done when one of the bootstrapping techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part of > RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really a small > footprint (i.e. 4 or 5 bullets listing the steps of home link detection > that we discussed on the mailing list and which are in Suresh and > George's draft) and does not represent a new feature but only a > clarification since we're talking about publishing it as informational, > thus it fits in RFC3775bis > > - it would be good anyway to reference the bootstrapping work in > rfc3775bis, > > - from a documentation point of view, it is better to document that in > one doc rather that two since the implementors doesn't have to run > after too many RFCs. > > Thus I'd like to propose that we integrate text in George and Suresh's > draft in RFC3775bis. Would the WG agree with that way forward? > > Thanks. > > --julien > > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above since it seems it is not that obvious > > to anyone by reading RFC5026. > _______________________________________________ > 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 Apr 14 08:45:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949AB28C333; Mon, 14 Apr 2008 08:45: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 E200928C370 for ; Mon, 14 Apr 2008 08:45:44 -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 CI+NM64yNYDS for ; Mon, 14 Apr 2008 08:45:43 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 22EBC28C342 for ; Mon, 14 Apr 2008 08:44:47 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3EFinJ8024396; Mon, 14 Apr 2008 18:45:16 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 18:42:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 10:42:06 -0500 Received: from 10.138.85.161 ([10.138.85.161]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Apr 2008 15:42:05 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 14 Apr 2008 10:42:50 -0500 From: Basavaraj Patil To: Julien Laganier , Message-ID: Thread-Topic: Result of consensus call on Home Link Detection Thread-Index: AcieRjHFcBL5owo5Ed2y8gARJNUNiA== In-Reply-To: <200804140946.37510.julien.IETF@laposte.net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Apr 2008 15:42:06.0438 (UTC) FILETIME=[17CEB060:01C89E46] X-Nokia-AV: Clean Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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 Agree with your recommendation for the way forward on the home link detection issue. -Raj On 4/14/08 2:46 AM, "ext Julien Laganier" wrote: > Folks, > > There's a clear consensus that we need to document how link link > detection is done when one of the bootstrapping techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part of > RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really a small > footprint (i.e. 4 or 5 bullets listing the steps of home link detection > that we discussed on the mailing list and which are in Suresh and > George's draft) and does not represent a new feature but only a > clarification since we're talking about publishing it as informational, > thus it fits in RFC3775bis > > - it would be good anyway to reference the bootstrapping work in > rfc3775bis, > > - from a documentation point of view, it is better to document that in > one doc rather that two since the implementors doesn't have to run > after too many RFCs. > > Thus I'd like to propose that we integrate text in George and Suresh's > draft in RFC3775bis. Would the WG agree with that way forward? > > Thanks. > > --julien > >> There's also a consensus that it is useful to document in an >> INFORMATIONAL document the above since it seems it is not that obvious >> to anyone by reading RFC5026. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 14 12:49:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B795F28C305; Mon, 14 Apr 2008 12:49: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 4D7F03A6DBA for ; Mon, 14 Apr 2008 12:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.614 X-Spam-Level: X-Spam-Status: No, score=-3.614 tagged_above=-999 required=5 tests=[AWL=1.588, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 xYPCqeyHGwAo for ; Mon, 14 Apr 2008 12:49:23 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id E9D3A28C305 for ; Mon, 14 Apr 2008 12:49:22 -0700 (PDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 36BCC7A9407; Mon, 14 Apr 2008 14:49:53 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id QYYAPntqVhZ3QXU8; Mon, 14 Apr 2008 14:49:53 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 14:49:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 14:49:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Changes in the CNs (was Re: A ProposedSolutionfor AeronauticalRO Thread-Index: AcieChdpvvH4Gu5RQvSUgXaIhy3pbgANvpOAAAm6eco= References: <47F60F77.7000809@mccallumwhyman.com><1207866491.5040.23.camel@localhost><47FE9655.3010202@it.uc3m.es><47FF3094.1060600@mccallumwhyman.com><48025FF2.9030405@it.uc3m.es><48031674.8000704@inria.fr> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "CERASI Eivan" , X-OriginalArrivalTime: 14 Apr 2008 19:49:53.0129 (UTC) FILETIME=[B50BB590:01C89E68] Subject: Re: [MEXT] Changes in the CNs (was Re: A ProposedSolutionfor AeronauticalRO 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="===============1240724497==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1240724497== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E68.B4DF2BF9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E68.B4DF2BF9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have the same understanding. I believe the current draft implies = this, but we can easily make it explicit in the update. Also, we need to be explicit = about the difference between PIES and ATS/AOS in this regard. ________________________________ From: mext-bounces@ietf.org on behalf of CERASI Eivan Sent: Mon 4/14/2008 10:26 AM To: mext@ietf.org Subject: Re: [MEXT] Changes in the CNs (was Re: A ProposedSolutionfor = AeronauticalRO Hi, I have the same understanding of where we are. Looking back at my notes of the interim meeting in Madrid, we discussed the CN part under the "solution space". Maybe, Wes can plan adding some of the below words into a document update ? Regards, Eivan Cerasi -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Thierry Ernst Sent: Monday 14 April 2008 10:32 To: mext@ietf.org Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor AeronauticalRO Please let me jump in this discussion. I didn't attend last IETF meetings and didn't follow all the discussion, but to me, what we stand on is: 1. There is a trade-off between unchanged CNs and NEMO Basic Support (RFC 3963): NEMO Basic Support has been designed so that CNs (and MNNs, etc) are left unchanged so that even though the solution is not optimal there is always a possibility to deal with legacy CNs. So, it is acceptable to request changes for a RO solution (which MUST NOT prevent the use of NEMO Basic Support) 2. We have always said that while leaving CNs unchanged is recommended, it is acceptable to require extended features on the CNs to perform RO 3. If there are 2 solutions of an acceptable quality and one of these is keeping the CNs unchanged, that one should be selected. Regards, Thierry. marcelo bagnulo wrote: >> I'm not against "big" changes in controlled environments as the >> aerospace one, but I just want to know whether those changes could >> be made or not. >> >> =20 > From what i understand, the question on whether updating CNs in the > ATS domain to support nemo RO was explicitly asked several times and > the question in all cases was: > - it may be possible sometimes, but any accetable solution MUST be > able to work with unchanged (legacy IPv6) CNs and offloading the nemo > RO processing to a proxy box topologically near. > > Wes, is my understanding correct? has this been expressed in the > requirements document? would it be in the next version? I think that > it is important to nail these requirements down, including all the > relevant informaiton there (in particular with respect to this issue > which seems very imporntat), cause, if not people working in solutions > are not able to design properly > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext ____ This message and any files transmitted with it are legally privileged = and intended for the sole use of the individual(s) or entity to whom = they are addressed. If you are not the intended recipient, please notify = the sender by reply and delete the message and any attachments from your = system. Any unauthorised use or disclosure of the content of this = message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal = commitment on the part of EUROCONTROL, unless it is confirmed by = appropriately signed hard copy. Any views expressed in this message are those of the sender. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C89E68.B4DF2BF9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [MEXT] Changes in the CNs (was Re: A = ProposedSolutionfor AeronauticalRO=0A= =0A= =0A= =0A=
=0A=
I have the = same understanding.  I believe the current draft implies this, but = we
=0A=
can easily = make it explicit in the update.  Also, we need to be explicit = about
=0A=
the = difference between PIES and ATS/AOS in this regard.
=0A=

=0A=
=0A= From: mext-bounces@ietf.org on = behalf of CERASI Eivan
Sent: Mon 4/14/2008 10:26 = AM
To: mext@ietf.org
Subject: Re: [MEXT] Changes in = the CNs (was Re: A ProposedSolutionfor = AeronauticalRO

=0A=
=0A=

Hi, I have the same understanding of where we = are.

Looking back at my notes of the interim meeting in Madrid, = we discussed
the CN part under the "solution space".

Maybe, = Wes can plan adding some of the below words into a document
update = ?

Regards,
Eivan Cerasi

-----Original = Message-----
From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = On Behalf Of
Thierry Ernst
Sent: Monday 14 April 2008 10:32
To: = mext@ietf.org
Subject: Re: [MEXT] Changes in the CNs (was Re: A = Proposed Solutionfor
AeronauticalRO


Please let me jump in = this discussion. I didn't attend last IETF
meetings and didn't follow = all the discussion, but to me, what we stand
on is:

1. There = is a trade-off between unchanged CNs and NEMO Basic Support
(RFC = 3963): NEMO Basic Support has been designed so that CNs (and = MNNs,
etc) are left unchanged so that even though the solution is not = optimal
there is always a possibility to deal with legacy CNs. So, it = is
acceptable to request changes for a RO solution (which MUST NOT = prevent
the use of NEMO Basic Support)

2. We have always said = that while leaving CNs unchanged is recommended,
it is acceptable to = require extended features on the CNs to perform RO

3. If there = are 2 solutions of an acceptable quality and one of these is
  = keeping the CNs unchanged, that one should be = selected.

Regards,
Thierry.

marcelo bagnulo = wrote:
>> I'm not against "big" changes in controlled = environments as the
>> aerospace one, but I just  want to = know whether those changes could
>> be made or = not.
>>
>>  
>  From what i = understand, the question on whether updating CNs in the
> ATS = domain to support nemo RO was explicitly asked several times and
> = the question in all cases was:
> - it may be possible sometimes, = but any accetable solution MUST be
> able to work with unchanged = (legacy IPv6) CNs and offloading the nemo
> RO processing to a = proxy box topologically near.
>
> Wes, is my understanding = correct? has this been expressed in the
> requirements document? = would it be in the next version? I think that
> it is important to = nail these requirements down, including all the
> relevant = informaiton there (in particular with respect to this issue
> = which seems very imporntat), cause, if not people working in = solutions

> are not able to design properly
>
> = Regards, marcelo
>
>
> = _______________________________________________
> MEXT mailing = list
> MEXT@ietf.org
> https://www.ietf.org/= mailman/listinfo/mext

____

This message and any files = transmitted with it are legally privileged and intended for the sole use = of the individual(s) or entity to whom they are addressed. If you are = not the intended recipient, please notify the sender by reply and delete = the message and any attachments from your system. Any unauthorised use = or disclosure of the content of this message is strictly prohibited and = may be unlawful.

Nothing in this e-mail message amounts to a = contractual or legal commitment on the part of EUROCONTROL, unless it is = confirmed by appropriately signed hard copy.

Any views expressed = in this message are those of the = sender.

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

------_=_NextPart_001_01C89E68.B4DF2BF9-- --===============1240724497== 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 --===============1240724497==-- From mext-bounces@ietf.org Mon Apr 14 18:42:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B71C3A689F; Mon, 14 Apr 2008 18:42: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 BD7D93A689E for ; Mon, 14 Apr 2008 18:42:38 -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 dpUJvbPUMdB7 for ; Mon, 14 Apr 2008 18:42:38 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 8628B3A689F for ; Mon, 14 Apr 2008 18:41:17 -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-maile14) with ESMTP id m3F1fc3b021053; Tue, 15 Apr 2008 10:41:38 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m3F1fcK24394; Tue, 15 Apr 2008 10:41:38 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m3F1fYi08338; Tue, 15 Apr 2008 10:41:35 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 09:40:59 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 15 Apr 2008 09:40:56 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 15 Apr 2008 09:40:56 +0800 From: "Benjamin Lim" To: "'Julien Laganier'" References: <200804140946.37510.julien.IETF@laposte.net> Date: Tue, 15 Apr 2008 09:40:55 +0800 Message-ID: <009601c89e99$bfb0a970$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200804140946.37510.julien.IETF@laposte.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcieA6Xh26HVTRN1SWuAglGm47Rw6wAlT5CA X-OriginalArrivalTime: 15 Apr 2008 01:40:59.0534 (UTC) FILETIME=[C19A02E0:01C89E99] Cc: mext@ietf.org Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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, Ok with me. Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Monday, April 14, 2008 3:47 PM > To: mext@ietf.org > Subject: [MEXT] Result of consensus call on Home Link Detection > > Folks, > > There's a clear consensus that we need to document how link > link detection is done when one of the bootstrapping > techniques is used. > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above > > Raj has however suggested that we'd better to do this as part > of RFC3775bis. > > I tend to agree with him for the following reasons: > > - what's missing to document home link detection has really > a small footprint (i.e. 4 or 5 bullets listing the steps of > home link detection that we discussed on the mailing list and > which are in Suresh and George's draft) and does not > represent a new feature but only a clarification since we're > talking about publishing it as informational, thus it fits in > RFC3775bis > > - it would be good anyway to reference the bootstrapping > work in rfc3775bis, > > - from a documentation point of view, it is better to > document that in one doc rather that two since the > implementors doesn't have to run after too many RFCs. > > Thus I'd like to propose that we integrate text in George and > Suresh's draft in RFC3775bis. Would the WG agree with that > way forward? > > Thanks. > > --julien > > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above since it seems it is not > that obvious > > to anyone by reading RFC5026. > _______________________________________________ > 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 Apr 14 22:54:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178C13A6D6A; Mon, 14 Apr 2008 22:54: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 371D63A6D50 for ; Mon, 14 Apr 2008 22:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r52MySMrCZPe for ; Mon, 14 Apr 2008 22:54:53 -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 E84263A6D44 for ; Mon, 14 Apr 2008 22:54:52 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k40so3070333wah.25 for ; Mon, 14 Apr 2008 22:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:subject:user-agent:organization:mime-version:content-type; bh=PDlXXqx8yT1X+5Dj9oI23j+BzC5H8x+cj4mM+fWN2/o=; b=nDkbgJyVARixGVMrBX/qdUTSDwbIBYPbxL8i1nrUsXtbetK3IV28EBJmzGTui7Ujd0S7lb36TfMy38ZUOTF5ebzcvUK9Z4rcy6PRZafIilSarabiPli7wiz8cYg92uH8s2lv54nXUShjuTLMwwbaYhgG7gDs+916mmIJbaC1rFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:subject:user-agent:organization:mime-version:content-type; b=IgcijevXDtwgcOx+aumekAxfD0YV/nFwdTfk5VIbEDFCSdTgZJoxTwpUb+e7GEmVwlsrKYIWZJtmXIl/ezPgrpfhWivULCbYo32zmuQhtJYIJEy5wSxHqz9qNRGJFtWG73tSE44aSl7rPx+cgzKKctgZt4PwDeZcPT9/wrn27yY= Received: by 10.114.59.1 with SMTP id h1mr7892508waa.39.1208238925056; Mon, 14 Apr 2008 22:55:25 -0700 (PDT) Received: from .gmail.com ( [61.200.198.68]) by mx.google.com with ESMTPS id v37sm16189223wah.12.2008.04.14.22.55.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Apr 2008 22:55:24 -0700 (PDT) Date: Tue, 15 Apr 2008 14:55:22 +0000 Message-ID: From: Ryuji Wakikawa To: mext@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) Organization: ToyotaITC/Keio Univ. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Subject: [MEXT] MCoA Update [pre07] 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, I revised the draft according to the discussions at the last IETF meeting. I haven't submitted this to the IETF, please fetch the document from http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6-multiplecoa-07.txt The diff from the previous draft is also available at http://www.sfc.wide.ad.jp/~ryuji/mcoadiff.html Please take a look and provide your comments. thanks, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 01:16:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9AB3A6AD5; Tue, 15 Apr 2008 01: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 6C1103A6AD5 for ; Tue, 15 Apr 2008 01:16:49 -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.049, 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 KA4SGlLfQ2zf for ; Tue, 15 Apr 2008 01:16:45 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 820103A6DB3 for ; Tue, 15 Apr 2008 01:16:45 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A65D3198787; Tue, 15 Apr 2008 11:17:15 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 65E44198784; Tue, 15 Apr 2008 11:17:15 +0300 (EEST) Message-ID: <4804648C.1000502@piuha.net> Date: Tue, 15 Apr 2008 11:17:16 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: mext@ietf.org References: <6964654.171781208238886134.JavaMail.weblogic@epml05> In-Reply-To: <6964654.171781208238886134.JavaMail.weblogic@epml05> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] FW: Summary for the changes in hiopt-13 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: This draft has progressed through the IESG and is about to be approved. The latest set of changes is as follows: Unless I hear objections in the next few days I will send out an approval notice. Jari Heejin Jang wrote: > Hi, Jari. > > The authors has submitted a new version of document, draft-ietf-mip6-hiopt-13.txt. > As a result of comments from Suresh, Pasi and Alfred, there were changes as below. > > 1) Dynamic discovery for dual-stacked HA was added. > - a new reference for RFC3344 (Mobile IPv4) was added > - a sub-option for FQDN (Sub-opt-code 5) was extended so that the MN can know > the provided HA is only for MIP6 or for dual-stacked. > - IANA section was changed to indicate a Dual-stack information in the sub-option for FQDN. > > 2) Merge a previous MIP6 Relay Agent sub-option & a Home Network > Information sub-option to a Common sub-option > - delete a MIP6 Relay agent sub-option and define a common option > (Section 3.1.1 and 3.2.1 were integrated into Section 3.3) > - modification of sub-opt-code definition in the body and IANA section. > > 3) Etc > - To place multiple options and in the order of preference in the Home Network > Information option. > - Reference to in the informative refereces > - Editorial revisions > > Thanks for your patience and kind help. > > - Best regards, > Heejin _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 02:26:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD2B3A6DFE; Tue, 15 Apr 2008 02:26:37 -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 9261B3A6C30 for ; Tue, 15 Apr 2008 02:26:35 -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 TpxRO9DVB05k for ; Tue, 15 Apr 2008 02:26:34 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id A97F93A6CB9 for ; Tue, 15 Apr 2008 02:26:30 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m3F9R1Hf029919; Tue, 15 Apr 2008 11:27:01 +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 m3F9R05m017087; Tue, 15 Apr 2008 11:27:00 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 11:26:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:26:48 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> In-Reply-To: <4804648C.1000502@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: Acie0WxG/FMyojkIQ2myRuUPr2INjAABZzAA References: <6964654.171781208238886134.JavaMail.weblogic@epml05> <4804648C.1000502@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" , X-OriginalArrivalTime: 15 Apr 2008 09:26:59.0753 (UTC) FILETIME=[DB30D990:01C89EDA] 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::080415112701-265B3BB0-7CF0255F/0-0/0-15 X-purgate-size: 2618/0 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, Heejin, > A Value of 0 in the Dual-stack field indicates > that the home agent specified by the following FQDN supports only > Mobile IPv6. A value of 1 means that the home agent supports both > Mobile IPv6 and Mobile IPv4. I would have expected that the dual stack support means support for DSMIP6. Anyway, now that we can indicate that the HA supports MIP4, I think it would be useful to add another bit indicating support for DSMIP6? Also the IPv4 home address/subnet option would be useful, otherwise the DSMIP6 MN on the home link would have to run IKE (or even BU/Back) to learn its IPv4 HoA. regards domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: 15. travanj 2008 10:17 > To: mext@ietf.org > Subject: [MEXT] FW: Summary for the changes in hiopt-13 > > FYI: This draft has progressed through the IESG and is about > to be approved. The latest set of changes is as follows: > > Unless I hear objections in the next few days I will send out > an approval notice. > > Jari > > Heejin Jang wrote: > > Hi, Jari. > > > > The authors has submitted a new version of document, > draft-ietf-mip6-hiopt-13.txt. > > As a result of comments from Suresh, Pasi and Alfred, there > were changes as below. > > > > 1) Dynamic discovery for dual-stacked HA was added. > > - a new reference for RFC3344 (Mobile IPv4) was added > > - a sub-option for FQDN (Sub-opt-code 5) was extended so > that the MN > > can know the provided HA is only for MIP6 or for dual-stacked. > > - IANA section was changed to indicate a Dual-stack > information in the sub-option for FQDN. > > > > 2) Merge a previous MIP6 Relay Agent sub-option & a Home Network > > Information sub-option to a Common sub-option > > - delete a MIP6 Relay agent sub-option and define a common option > > (Section 3.1.1 and 3.2.1 were integrated into Section 3.3) > > - modification of sub-opt-code definition in the body and > IANA section. > > > > 3) Etc > > - To place multiple options and in the order of preference > in the Home Network > > Information option. > > - Reference to in the > informative > > refereces > > - Editorial revisions > > > > Thanks for your patience and kind help. > > > > - Best regards, > > Heejin > > _______________________________________________ > 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 Apr 15 04:15:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1A43A6CDF; Tue, 15 Apr 2008 04: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 E1E773A6AD0 for ; Tue, 15 Apr 2008 04:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 i+2zI-b-kYcs for ; Tue, 15 Apr 2008 04:15:46 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DAA053A6979 for ; Tue, 15 Apr 2008 04:15:45 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id EF3AF198788; Tue, 15 Apr 2008 14:16:17 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A62371986D5; Tue, 15 Apr 2008 14:16:17 +0300 (EEST) Message-ID: <48048E82.6000402@piuha.net> Date: Tue, 15 Apr 2008 14:16:18 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: "Premec, Domagoj" References: <6964654.171781208238886134.JavaMail.weblogic@epml05> <4804648C.1000502@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 would have expected that the dual stack support means support for DSMIP6. Anyway, now that we can indicate that the HA supports MIP4, I think it would be useful to add another bit indicating support for DSMIP6? > This is actually a problem in -13 (I reviewed it myself after sending out the mail this morning). I think we need to be able to indicate (a) FQDNs, (b) IPv6 addresses, or (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to either IPv4 or IPv6 addresses or both... no flags needed. And I think this draft should only focus on Mobile IPv6. We get the Mobile IPv6 home agent's addresses (be it v4 or v6), not something else... Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 04:23:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50F63A6E3F; Tue, 15 Apr 2008 04:23: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 480C53A6BCF for ; Tue, 15 Apr 2008 04:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 1-d2wvGZmMcm for ; Tue, 15 Apr 2008 04:23:40 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 07AA63A6E3F for ; Tue, 15 Apr 2008 04:23:39 -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 1JljGj-0003q8-LK; Tue, 15 Apr 2008 21:24:09 +1000 Message-Id: From: Hesham Soliman To: Jari Arkko In-Reply-To: <48048E82.6000402@piuha.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 21:24:03 +1000 References: <6964654.171781208238886134.JavaMail.weblogic@epml05> <4804648C.1000502@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> <48048E82.6000402@piuha.net> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 15/04/2008, at 9:16 PM, Jari Arkko wrote: > >> I would have expected that the dual stack support means support for >> DSMIP6. Anyway, now that we can indicate that the HA supports MIP4, >> I think it would be useful to add another bit indicating support >> for DSMIP6? >> > > This is actually a problem in -13 (I reviewed it myself after sending > out the mail this morning). > > I think we need to be able to indicate (a) FQDNs, (b) IPv6 > addresses, or > (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to > either > IPv4 or IPv6 addresses or both... no flags needed. > > And I think this draft should only focus on Mobile IPv6. We get the > Mobile IPv6 home agent's addresses (be it v4 or v6), not something > else... => Agreed. Hesham > > > 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 Tue Apr 15 05:29:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854A33A6EBE; Tue, 15 Apr 2008 05:29: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 BC03728C3A7 for ; Tue, 15 Apr 2008 05:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.572, 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 wdaICCg9N8EI for ; Tue, 15 Apr 2008 05:29:11 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 1C23B3A6E84 for ; Tue, 15 Apr 2008 05:29:11 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2025453wfa.31 for ; Tue, 15 Apr 2008 05:29:44 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xJ1WuBPnCHzeYd8E9UUX0lVF2PYVGG0TuiR3EcBvZP8=; b=WGTEVpRpmCBOErYnZOcwZevxZ3X94w1cfQk71SFU28SKMUN2b3VQQ3wHtzaiZ0hg+3KN8Emr8kEnC5IFjEsNb6pogQ5Mw46Vre9K2VQ+W4JIVuyQoEo45d4ChQJCoFxR8SNR0RVTRyidB3Gb9EhErTkM84hhsQq6Qm9oFPkFTJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=cdDP4bjvQHsZEu1YCZIFJOHRGB4ejMRtPgV0w6C63Es3NDqGvEhxMgZ3eekcmhJpccsZjCFJH4nCEueajH43dAA8rU+S82Z9BGYCwJbSdjqZZXUXH5tTA3TSWv9NEcLSxOZKvzLOY8MTIao3gK5BgE3VAucrG+KfplFP87BJwjg= Received: by 10.142.188.4 with SMTP id l4mr2227897wff.151.1208262584022; Tue, 15 Apr 2008 05:29:44 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Tue, 15 Apr 2008 05:29:43 -0700 (PDT) Message-ID: Date: Tue, 15 Apr 2008 13:29:43 +0100 From: "George Tsirtsis" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkgUnl1amksCgpUaGlzIGxvb2tzIHJlYWxseSBnb29kLgpJIGhhdmUgYSBudW1iZXIgb2YgZGV0 YWlsZWQgY29tbWVudHMgd2hpY2ggc2hvdWxkIGJlIGVhc3kgdG8gcmVzb2x2ZSwKCjEpIFlvdSBt YXkgd2FudCB0byB1c2UgdGhlIElQdjYgcHJlZml4ICgyMDAxOkRCODo6LzMyKSByZXNlcnZlZCBm b3IKZG9jdW1lbnRhdGlvbiAoc2VlIFJGQzM4NDkpCjIpIEkgYW0gc3VnZ2VzdGluZyB0aGF0IHdo ZW4gdGhlIEggZmxhZyBpcyBzZXQgaW4gdGhlIEJVLCBpdCBzaG91bGQgYmUKdmlld2VkIGFzIGEg cmVnaXN0cmF0aW9uLCByYXRoZXIgdGhhbiBkZS1yZWdpc3RyYXRpb24uCgpNb3JlIGNvbW1lbnRz IGlubGluZS4uLgoKVGhhbmtzCkdlb3JnZQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKMy4gIFByb3RvY29sIE92ZXJ2aWV3CuKApgogICAxLiAgVGhlIG1vYmlsZSBub2RlIHVz ZXMgb25seSB0aGUgaW50ZXJmYWNlIHdpdGggd2hpY2ggaXQgYXR0YWNoZXMgdG8KICAgICAgIHRo ZSBob21lIGxpbmsgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDIuICBJdCBkZS1yZWdpc3RlcnMgYWxs CiAgICAgICBiaW5kaW5ncyByZWxhdGVkIHRvIGFsbCBjYXJlLW9mIGFkZHJlc3NlcyB0byB0aGUg aG9tZSBhZ2VudC4gIFRoZQogICAgICAgaW50ZXJmYWNlcyBzdGlsbCBhdHRhY2hlZCB0byB0aGUg dmlzaXRlZCBsaW5rKHMpIGFyZSBubyBsb25nZXIKICAgICAgIGdvaW5nIHRvIGJlIHJlY2Vpdmlu ZyBhbnkgZW5jYXBzdWxhdGVkIHRyYWZmaWMgZnJvbSB0aGUgaG9tZQogICAgICAgYWdlbnQuICBP biB0aGUgb3RoZXIgaGFuZCwgdGhlIG1vYmlsZSBub2RlIGNhbiBjb250aW51ZQogICAgICAgY29t bXVuaWNhdGluZyB3aXRoIHRoZSBjb3JyZXNwb25kZW50IG5vZGUgZnJvbSB0aGUgb3RoZXIKICAg ICAgIGludGVyZmFjZXMgYXR0YWNoZWQgdG8gZm9yZWlnbiBsaW5rcyBieSB1c2luZyByb3V0ZSBv cHRpbWl6YXRpb24uCiAgICAgICBFdmVuIGlmIHRoZSBtb2JpbGUgbm9kZSBpcyBhdHRhY2hlZCB0 byB0aGUgaG9tZSBsaW5rLCBpdCBjYW4KICAgICAgIHN0aWxsIHNlbmQgQmluZGluZyBVcGRhdGVz IGZvciBvdGhlciBhY3RpdmUgY2FyZS1vZiBhZGRyZXNzZXMKICAgICAgIChDb0EyIGFuZCBDb0Ez KSB0byBjb3JyZXNwb25kZW50IG5vZGVzLiAgU2luY2UgdGhlIGNvcnJlc3BvbmRlbnQKICAgICAg IG5vZGUgaGFzIGJpbmRpbmdzLCBwYWNrZXRzIGFyZSByb3V0ZWQgdG8gZWFjaCBDYXJlLW9mIEFk ZHJlc3NlcwogICAgICAgZGlyZWN0bHkuCgogICAgICAgICAgICAgICAgICAgICstLS0tKwogICAg ICAgICAgICAgICAgICAgIHwgQ04gfAogICAgICAgICAgICAgICAgICAgICstLSstKwogICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICstLS0rLS0tLS0tKyAgICAgICAg ICArLS0tLSsKICAgICAgICAgICAgKy0tLS0tLSsgSW50ZXJuZXQgfC0tLS0tLS0tLS0rIEhBIHwK ICAgICAgICAgICAgfCAgICAgICstLS0tLS0tLSstKyAgICAgICAgICArLS0rLSsKICAgICAgICBD b0EyfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgSG9tZSBMaW5rCiAgICAgICAg ICstLSstLSsgICAgICAgICAgICB8ICAgICAgICAgLS0rLS0tKy0tLS0tLQogICAgICAgICB8ICBN TiArPT09PT09PT0rICAgfCAgICAgICAgICAgfAogICAgICAgICArLS0rLS0rICAgICAgICB8ICAg fCAgICAgICAgICAgfAogICAgICAgIENvQTN8ICAgICAgICAgICArLS0tfC0tLS0tLS0tLS0tKwog ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKICAgICBCaW5kaW5nIENhY2hlIERhdGFiYXNl OgogICAgICAgIGhvbWUgYWdlbnQncyBiaW5kaW5nCiAgICAgICAgICAgICAgbm9uZQogICAgICAg IGNvcnJlc3BvbmRlbnQgbm9kZSdzIGJpbmRpbmcKICAgICAgICAgICAgICBiaW5kaW5nIFthOmI6 YzpkOjpFVUkgIGNhcmUtb2YgYWRkcmVzczIgIEJJRDJdCiAgICAgICAgICAgICAgYmluZGluZyBb YTpiOmM6ZDo6RVVJICBjYXJlLW9mIGFkZHJlc3MzICBCSUQzXQoKICAgICAgICAgICAgIEZpZ3Vy ZSAyOiBVc2luZyBvbmx5IEludGVyZmFjZSBBdHRhY2hlZCB0byBIb21lIExpbmsKCgpHVD4gV2h5 IGlzIHRoaXMgZmlndXJlIGRpZmZlcmVudCB0aGFuIHRoZSBvdGhlcnMgYmVsb3c/IElzIHRoZSBo b21lCmxpbmsgY3Jvc3Npbmcgb3ZlciB0aGUgQ29BMyBsaW5rLCBuZWNlc3Nhcnk/IFRoZSBmaWd1 cmUgY291bGQgYmUgc2hvd24KYXMgdGhlIG9uY2UgYmVsb3cgbm8/CgoK4oCmCiAgIDMuICBUaGUg bW9iaWxlIG5vZGUgbWF5IHNpbXVsdGFuZW91c2x5IHVzZSBib3RoIHRoZSBpbnRlcmZhY2UKICAg ICAgIGF0dGFjaGVkIHRvIHRoZSBob21lIGxpbmsgYW5kIHRoZSBpbnRlcmZhY2VzIHN0aWxsIGF0 dGFjaGVkIHRvCiAgICAgICB0aGUgdmlzaXRlZCBsaW5rKHMpIGFzIHNob3duIGluIEZpZ3VyZSA0 LiAgVGhlcmUgYXJlIHR3byBwb3NzaWJsZQogICAgICAgdG9wb2xvZ2llcyB3aGV0aGVyIHRoZSBo b21lIGFnZW50IGlzIHNpbmdsZSByb3V0ZXIgYXQgdGhlIGhvbWUKICAgICAgIGxpbmsgb3Igbm90 LiAgVGhlIG9wZXJhdGlvbiBvZiBOZWlnaGJvciBEaXNjb3ZlcnkgW1JGQy0yNDYxXSBpcwogICAg ICAgZGlmZmVyZW50IGluIHRoZSB0d28gdG9wb2xvZ2llcy4gIFRoZSBob21lIGFnZW50IGFuZCB0 aGUKICAgICAgIGNvcnJlc3BvbmRlbnQgbm9kZSBoYXZlIHRoZSBiaW5kaW5nIGVudHJpZXMgbGlz dGVkIGluIEZpZ3VyZSA0IGluCiAgICAgICB0aGVpciBiaW5kaW5nIGNhY2hlIGRhdGFiYXNlIGlu IGJvdGggdG9wb2xvZ2llcy4gIFRoZSBob21lIGFnZW50CiAgICAgICBhbHNvIGtub3dzIHRoYXQg dGhlIG1vYmlsZSBub2RlIGhhcyBhdHRhY2hlZCB0byB0aGUgaG9tZSBsaW5rLgogICAgICAgQWxs IHRoZSB0cmFmZmljIGZyb20gdGhlIEludGVybmV0IGFyZSBpbnRlcmNlcHRlZCBieSB0aGUgaG9t ZQoKR1Q+IC8vYXJlL2lzCgogICAgICAgYWdlbnQgZmlyc3QgYW5kIHJvdXRlZCB0byBlaXRoZXIg dGhlIGludGVyZmFjZSBhdHRhY2hlZCB0byB0aGUKICAgICAgIGhvbWUgbGluayBvciB0aGUgb25l IGF0dGFjaGVkIHRvIHRoZSBmb3JlaWduIGxpbmtzLiAgSG93IHRvIG1ha2UKCkdUPiAvLyB0aGUg b25lIGF0dGFjaGVkIHRvIHRoZSBmb3JlaWduIGxpbmtzLi90byBvbmUgb2YgdGhlIGZvcmVpZ24g bGlua3MuCgogICAgICAgdGhlIGRlY2lzaW9uIGlzIG91dCBvZiBzY29wZSBpbiB0aGlzIGRvY3Vt ZW50LgoKCgoKCgoKCgoKCgoKV2FraWthd2EgKEVkaXRvciksIGV0IGFsLiAgRXhwaXJlcyBPY3Rv YmVyIDE3LCAyMDA4ICAgICAgICAgICAgW1BhZ2UgMTBdCgpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgTUNvQSAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDgKCgogICBU b3BvbG9neS1hKQogICAgICAgICAgICAgICAgICAgICstLS0tKwogICAgICAgICAgICAgICAgICAg IHwgQ04gfAogICAgICAgICAgICAgICAgICAgICstLSstKwogICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICstLS0rLS0tLS0tKyAgICAgICAgICArLS0tLSsKICAgICAg ICAgICAgKy0tLS0tLSsgSW50ZXJuZXQgfC0tLS0tLS0tLS0rIEhBIHwKICAgICAgICAgICAgfCAg ICAgICstLS0tKy0tLS0tKyAgICAgICAgICArLS0rLSsKICAgICAgICBDb0EyfCAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICB8ICAgSG9tZSBMaW5rCiAgICAgICAgICstLSstLSsgICAgICAg IHwgICAgICAgICAgICAgLS0rLS0tKy0tLS0tLQogICAgICAgICB8ICBNTiArPT09PT09PT0rICAg ICAgICAgICAgICAgfAogICAgICAgICArLS0rLS0rIENvQTEgICAgICAgICAgICAgICAgICAgfAog ICAgICAgQ29BMyB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgVG9wb2xvZ3ktYikKICAgICAgICAgICAgICAg ICAgICArLS0tLSsKICAgICAgICAgICAgICAgICAgICB8IENOIHwKICAgICAgICAgICAgICAgICAg ICArLS0rLSsKICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICArLS0t Ky0tLS0tLSsgICAgUm91dGVyICAgICstLS0tKwogICAgICAgICAgICArLS0tLS0tKyBJbnRlcm5l dCB8LS0tLS0tLVIgICAgICB8IEhBIHwKICAgICAgICAgICAgfCAgICAgICstLS0tKy0tLS0tKyAg ICAgICB8ICAgICAgKy0tKy0rCiAgICAgICAgQ29BMnwgICAgICAgICAgIHwgICAgICAgICAgICAg fCAgICAgICAgIHwgICBIb21lIExpbmsKICAgICAgICAgKy0tKy0tKyAgICAgICAgfCAgICAgICAg ICAgLS0rLSstLS0tLS0tKy0tLS0tLQogICAgICAgICB8ICBNTiArPT09PT09PT0rICAgICAgICAg ICAgICAgfAogICAgICAgICArLS0rLS0rIENvQTEgICAgICAgICAgICAgICAgICAgfAogICAgICAg Q29BMyB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwoKCkdUPiBJIHRoaW5rIHRoZSBDb0EzIHNob3duIGluIHRoaXMg ZmlndXJlcyBzaG91bGQgbm90IGJlIHRoZXJlLCB0aWdodD8KCgogICAgIEJpbmRpbmcgQ2FjaGUg RGF0YWJhc2U6CiAgICAgICAgaG9tZSBhZ2VudCdzIGJpbmRpbmcKICAgICAgICAgICAgICBiaW5k aW5nIFthOmI6YzpkOjpFVUkgIGNhcmUtb2YgYWRkcmVzczEgIEJJRDFdCiAgICAgICAgICAgICAg YmluZGluZyBbYTpiOmM6ZDo6RVVJICBjYXJlLW9mIGFkZHJlc3MyICBCSUQyXQogICAgICAgIGNv cnJlc3BvbmRlbnQgbm9kZSdzIGJpbmRpbmcKICAgICAgICAgICAgICBiaW5kaW5nIFthOmI6Yzpk OjpFVUkgIGNhcmUtb2YgYWRkcmVzczEgIEJJRDFdCiAgICAgICAgICAgICAgYmluZGluZyBbYTpi OmM6ZDo6RVVJICBjYXJlLW9mIGFkZHJlc3MyICBCSUQyXQoKCiAgICAgICAgICAgIEZpZ3VyZSA0 OiBTaW11bHRhbmVvdXMgSG9tZSBhbmQgVmlzaXRlZCBMaW5rIE9wZXJhdGlvbgoKCgoKCgoKCgoK V2FraWthd2EgKEVkaXRvciksIGV0IGFsLiAgRXhwaXJlcyBPY3RvYmVyIDE3LCAyMDA4ICAgICAg ICAgICAgW1BhZ2UgMTFdCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTUNvQSAg ICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDgKCgo0LiAgTW9iaWxlIElQdjYgRXh0ZW5z aW9ucwoKICAgVGhpcyBzZWN0aW9uIHN1bW1hcml6ZXMgdGhlIGV4dGVuc2lvbnMgdG8gTW9iaWxl IElQdjYgbmVjZXNzYXJ5IGZvcgogICBtYW5hZ2UgbXVsdGlwbGUgYmluZGluZ3MuCgo0LjEuICBC aW5kaW5nIENhY2hlIFN0cnVjdHVyZSBhbmQgQmluZGluZyBVcGRhdGUgTGlzdAoKICAgVGhlIEJJ RCBpcyByZXF1aXJlZCB0byBiZSBzdG9yZWQgaW4gdGhlIGJpbmRpbmcgY2FjaGUgYW5kIGJpbmRp bmcKICAgdXBkYXRlIGxpc3Qgc3RydWN0dXJlLgoKICAgVGhlIHNlcXVlbmNlIG51bWJlciB2YWx1 ZSBTSE9VTEQgYmUgc2hhcmVkIGFtb25nIGFsbCB0aGUgYmluZGluZwogICB1cGRhdGUgbGlzdC4g IFdoZW5ldmVyIGEgbW9iaWxlIG5vZGUgc2VuZHMgZWl0aGVyIGluZGl2aWR1YWwgb3IgYnVsawog ICBiaW5kaW5nIHVwZGF0ZSwgdGhlIHNlcXVlbmNlIG51bWJlciBpcyBpbmNyZW1lbnRlZCB0aGUg dmFsdWUgb2YgdGhlCiAgIHByZXZpb3VzIHNlcXVlbmNlIG51bWJlci4KCkdUPi8vIGlzIGluY3Jl bWVudGVkIHRoZSB2YWx1ZSBvZiB0aGUgcHJldmlvdXMgc2VxdWVuY2UgbnVtYmVyLiAvLyBpcwpp bmNyZW1lbnRlZC4KCiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgYSBtb2JpbGUgbm9kZQogICBtYW5h Z2VzIGFuIGluZGl2aWR1YWwgc2VxdWVuY2UgdmFsdWUgcGVyIGJpbmRpbmcgdXBkYXRlIGxpc3Qs IGEKICAgbW9iaWxlIG5vZGUgU0hPVUxEIGNhcmVmdWxseSBzZWxlY3QgdGhlIHNlcXVlbmNlIG51 bWJlciB2YWx1ZSBmb3IgdGhlCiAgIGJ1bGsgYmluZGluZyB1cGRhdGUuICBUaGlzIGlzIGJlY2F1 c2UgYWxsIHRoZSBidWxrLXJlZ2lzdGVyZWQKICAgYmluZGluZ3MgdXNlIHRoZSBzYW1lIFNlcXVl bmNlIE51bWJlciBzcGVjaWZpZWQgaW4gdGhlIEJpbmRpbmcKICAgVXBkYXRlLiAgSWYgZWFjaCBi aW5kaW5nIHVzZXMgZGlmZmVyZW50IHNlcXVlbmNlIG51bWJlciwgYSBtb2JpbGUKICAgbm9kZSBN VVNUIHVzZSB0aGUgbGFyZ2VzdCBzZXF1ZW5jZSBudW1iZXIgZnJvbSB0aGUgQmluZGluZyBVcGRh dGUKICAgbGlzdCBlbnRyaWVzIHVzZWQgZm9yIHRoZSBidWxrIHJlZ2lzdHJhdGlvbi4gIElmIHRo ZSBtb2JpbGUgbm9kZQogICBjYW5ub3Qgc2VsZWN0IGEgc2VxdWVuY2UgbnVtYmVyIGZvciBhbGwg dGhlIGJpbmRpbmdzIGR1ZSB0byBzZXF1ZW5jZQogICBudW1iZXIgb3V0IG9mIHdpbmRvdywgaXQg TVVTVCBOT1QgdXNlIHRoZSBidWxrIHJlZ2lzdHJhdGlvbiBmb3IgdGhlCiAgIGJpbmRpbmcgd2hv c2Ugc2VxdWVuY2UgbnVtYmVyIGlzIG91dCBvZiB3aW5kb3cuICBBIHNlcGFyYXRlIEJpbmRpbmcK ICAgVXBkYXRlIHNob3VsZCBiZSBzZW50IGZvciB0aGUgYmluZGluZy4KCjQuMi4gIEJpbmRpbmcg SWRlbnRpZmllciBNb2JpbGl0eSBPcHRpb24KCiAgIFRoZSBCaW5kaW5nIElkZW50aWZpZXIgbW9i aWxpdHkgb3B0aW9uIGlzIGluY2x1ZGVkIGluIHRoZSBCaW5kaW5nCiAgIFVwZGF0ZSwgQmluZGlu ZyBBY2tub3dsZWRnZW1lbnQsIEJpbmRpbmcgUmVmcmVzaCBSZXF1ZXN0LCBhbmQgQ2FyZS1vZgog ICBUZXN0IEluaXQgYW5kIENhcmUtb2YgVGVzdCBtZXNzYWdlLgoKICAgICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgVHlwZSA9IFRCRCAgfCAgICAgTGVuZ3RoICAgIHwKICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAg ICB8ICAgICAgIEJpbmRpbmcgSUQgKEJJRCkgICAgICAgIHwgICAgIFN0YXR1cyAgICB8Q3xPfEh8 RHxSZXNydmQgfAogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgICA6ICAgICAg ICAgICAgICAgICBJUHY0IG9yIElQdjYgY2FyZS1vZiBhZGRyZXNzIChDb0EpICAgICAgICAgICAg OgogICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICsKICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAg IEZpZ3VyZSA1OiBCSUQgTW9iaWxpdHkgT3B0aW9uCgoKCgoKCldha2lrYXdhIChFZGl0b3IpLCBl dCBhbC4gIEV4cGlyZXMgT2N0b2JlciAxNywgMjAwOCAgICAgICAgICAgIFtQYWdlIDEyXQoKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE1Db0EgICAgICAgICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA4CgoKICAgVHlwZQoKICAgICAgVHlwZSB2YWx1ZSBmb3IgQmluZGluZyBJZGVu dGlmaWVyIGlzIFRCRAoKICAgTGVuZ3RoCgogICAgICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAg TGVuZ3RoIG9mIHRoZSBvcHRpb24sIGluIG9jdGV0cywKICAgICAgZXhjbHVkaW5nIHRoZSBUeXBl IGFuZCBMZW5ndGggZmllbGRzLiAgSXQgTVVTVCBiZSBzZXQgdG8gNCB3aGVuCiAgICAgIHRoZSAn QycgZmxhZyBpcyB1bnNldC4gIE90aGVyd2lzZSwgdGhlIExlbmd0aCB2YWx1ZSBNVVNUIGJlIHNl dCB0bwogICAgICBlaXRoZXIgOCBvciAyMCBkZXBlbmRpbmcgb24gdGhlICdEJyAoRFNNSVB2Nikg ZmxhZy4KCiAgIEJpbmRpbmcgSUQgKEJJRCkKCiAgICAgIFRoZSBCSUQgd2hpY2ggaXMgYXNzaWdu ZWQgdG8gdGhlIGJpbmRpbmcgaW5kaWNhdGVkIGJ5IHRoZSBjYXJlLW9mCiAgICAgIGFkZHJlc3Mg aW4gdGhlIEJpbmRpbmcgVXBkYXRlIG9yIHRoZSBCSUQgbW9iaWxpdHkgb3B0aW9uLiAgVGhlIEJJ RAogICAgICBpcyBhIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIHZhbHVlIG9mIHplcm8g aXMgcmVzZXJ2ZWQgYW5kCiAgICAgIE1VU1QgTk9UIGJlIHVzZWQuCgogICBTdGF0dXMKCiAgICAg IFdoZW4gdGhlIEJpbmRpbmcgSWRlbnRpZmllciBtb2JpbGl0eSBvcHRpb24gaXMgaW5jbHVkZWQg aW4gYQogICAgICBCaW5kaW5nIEFja25vd2xlZGdlbWVudCwgdGhpcyBmaWVsZCBvdmVyd3JpdGVz IHRoZSBzdGF0dXMgZmllbGQgaW4KICAgICAgdGhlIEJpbmRpbmcgQWNrbm93bGVkZ2VtZW50LiAg SWYgdGhpcyBmaWVsZCBpcyB6ZXJvLCB0aGUgcmVjZWl2ZXIKICAgICAgTVVTVCB1c2UgdGhlIHJl Z2lzdHJhdGlvbiBzdGF0dXMgc3RvcmVkIGluIHRoZSBCaW5kaW5nCiAgICAgIEFja25vd2xlZGdl bWVudCBtZXNzYWdlLiAgVGhpcyBTdGF0dXMgZmllbGQgaXMgYWxzbyB1c2VkIHRvIGNhcnJ5CiAg ICAgIGVycm9yIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIGNhcmUtb2YgYWRkcmVzcyB0ZXN0 IGluIHRoZQogICAgICBDYXJlLW9mIFRlc3QgbWVzc2FnZS4gIFRoZSBzdGF0dXMgaXMgOC1iaXQg dW5zaWduZWQgaW50ZWdlci4gIFRoZQogICAgICBwb3NzaWJsZSBzdGF0dXMgY29kZXMgYXJlIHRo ZSBzYW1lIGFzIHRoZSBzdGF0dXMgY29kZXMgb2YgQmluZGluZwogICAgICBBY2tub3dsZWRnZW1l bnQuCgogICBDYXJlLW9mIGFkZHJlc3MgKEMpIGZsYWcKCiAgICAgIFdoZW4gdGhpcyBmbGFnIGlz IHNldCwgaXQgaW5kaWNhdGVzIHRoYXQgYSB2YWxpZCBjYXJlLW9mIGFkZHJlc3MKICAgICAgaXMg cHJlc2VudCBpbiB0aGUgY2FyZS1vZiBhZGRyZXNzIGZpZWxkIGluIHRoZSBCSUQgbW9iaWxpdHkK ICAgICAgb3B0aW9uLiAgVGhpcyBmbGFnIE1VU1QgYmUgc2V0IHdoZW5ldmVyIHRoZSBtb2JpbGUg bm9kZSBzZW5kcwogICAgICBtdWx0aXBsZSBjYXJlLW9mIGFkZHJlc3NlcyBpbiBhIHNpbmdsZSBC aW5kaW5nIFVwZGF0ZSwgaS5lLiwgYnVsawogICAgICByZWdpc3RyYXRpb24uICBJdCBNQVkgYWxz byB1c2VkIGFzIGEgc3Vic3RpdHV0ZSBmb3IgYWx0ZXJuYXRlCgpHVD4gLy9JdCBNQVkgYWxzbyB1 c2VkL0l0IE1BWSBhbHNvIGJlIHVzZWQKCiAgICAgIGNhcmUtb2YgYWRkcmVzcyBvcHRpb24gZXZl biBmb3IgQmluZGluZyBVcGRhdGVzIHRoYXQgYXJlIHNlbnQgb25seQogICAgICBmb3Igb25lIGNh cmUtb2YgYWRkcmVzcy4gIFRoaXMgZmxhZyBpcyB2YWxpZCBvbmx5IGZvciBCaW5kaW5nCiAgICAg IFVwZGF0ZSBzZW50IHRvIHRoZSBob21lIGFnZW50LgoKICAgT3ZlcndyaXRlIChPKSBmbGFnCgog ICAgICBXaGVuIHRoaXMgZmxhZyBpcyBzZXQsIGEgbW9iaWxlIG5vZGUgcmVxdWVzdHMgdGhlIHJl Y2lwaWVudCB0bwogICAgICByZXBsYWNlIGFsbCB0aGUgYmluZGluZ3MgdG8gYmluZGluZyBlbnRy aWVzIHN0b3JlZCBpbiBhIEJpbmRpbmcKICAgICAgVXBkYXRlLgoKCgoKCldha2lrYXdhIChFZGl0 b3IpLCBldCBhbC4gIEV4cGlyZXMgT2N0b2JlciAxNywgMjAwOCAgICAgICAgICAgIFtQYWdlIDEz XQoKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE1Db0EgICAgICAgICAgICAgICAg ICAgICAgICBBcHJpbCAyMDA4CgoKICAgU2ltdWx0YW5lb3VzIEhvbWUgYW5kIEZvcmVpZ24gQmlu ZGluZyAoSCkgZmxhZwoKICAgICAgVGhpcyBmbGFnIGluZGljYXRlcyB0aGF0IHRoZSBtb2JpbGUg bm9kZSByZWdpc3RlcnMgbXVsdGlwbGUKICAgICAgYmluZGluZ3MgdG8gdGhlIGhvbWUgYWdlbnQg d2hpbGUgaXMgYXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluay4KICAgICAgVGhpcyBmbGFnIGlzIHZh bGlkIG9ubHkgZm9yIGEgQmluZGluZyBVcGRhdGUgc2VudCB0byB0aGUgaG9tZQogICAgICBhZ2Vu dC4KCiAgIERTTUlQdjYgKEQpIGZsYWcKCiAgICAgIFRoaXMgZmxhZyBpbmRpY2F0ZXMgdGhhdCB0 aGUgY2FyZS1vZiBhZGRyZXNzIGlzIGFuIElQdjQgYWRkcmVzcy4KICAgICAgV2hlbiB0aGlzIGZs YWcgaXMgc2V0LCB0aGUgY2FyZS1vZiBhZGRyZXNzIGZpZWxkIE1VU1QgY29udGFpbiBhbgogICAg ICBJUHY0IGFkZHJlc3MuCgoKR1Q+IEkgY2FuIG5vdCByZW1lbWJlciBpZiB0aGlzIHdhcyBldmVy IGRpc2N1c3NlZCBidXQgZG8gd2UgcmVhbGx5Cm5lZWQgZmxhZ3MgQyBhbmQgRD8gSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGUgTGVuZ3RoIGZpZWxkIGNhbiBiZSA0IChDb0EKbm90IGluY2x1ZGVkKSwg MTIgKHY0Q29BKSwgb3IgMjAgKHY2Q29BKSwgd2hpY2ggcHJvdmlkZXMgYWxsIHRoZSBpbmZvCndl IG5lZWQuCgogICBSZXNlcnZlZAoKICAgICAgNSBiaXRzIFJlc2VydmVkIGZpZWxkLiAgVGhlIHJl c2VydmVkIGZpZWxkIE1VU1QgYmUgemVyby4KCiAgIENhcmUtb2YgQWRkcmVzcwoKICAgICAgVGhp cyBmaWVsZCBoYXMgdGhlIHZhcmlhYmxlIGxlbmd0aCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmll ZAogICAgICBmbGFncy4gIFdoZW4gdGhlICdDJyBmbGFnIGlzIHNldCBhbmQgdGhlICdEJyBmbGFn IGlzIG5vdCwgYW4gSVB2NgogICAgICBjYXJlLW9mIGFkZHJlc3MgZm9yIHRoZSBjb3JyZXNwb25k aW5nIEJJRCBpcyBzdG9yZWQgaW4gdGhpcyBmaWVsZC4KICAgICAgSWYgYm90aCAnQycgYW5kICdE JyBmbGFncyBhcmUgc2V0LCBhbiBJUHY0IENhcmUtb2YgQWRkcmVzcyBpcwogICAgICBjYXJyaWVk IGluIHRoaXMgZmllbGQuICBUaGlzIGZpZWxkIE1VU1QgTk9UIGJlIHVzZWQgaWYgYSBCaW5kaW5n CiAgICAgIElkZW50aWZpZXIgbW9iaWxpdHkgb3B0aW9uIGlzIGluY2x1ZGVkIGluIGFueSBvdGhl ciBtZXNzYWdlIG90aGVyCiAgICAgIHRoYW4gYSBCaW5kaW5nIFVwZGF0ZSBvciBpZiB0aGUgJ0Mn IGZsYWcgaXMgbm90IHNldC4KCuKApgo0LjQuICBMaW5rIExheWVyIEFkZHJlc3MgTW9iaWxpdHkg T3B0aW9uCgogICBUaGUgTGluayBMYXllciBBZGRyZXNzIG1vYmlsaXR5IG9wdGlvbiBpcyBpbmNs dWRlZCBvbmx5IGluIHRoZQogICBkZXJlZ2lzdHJhdGlvbiBCaW5kaW5nIFVwZGF0ZSB3aGVuIGEg bW9iaWxlIG5vZGUgcmV0dXJucyBob21lIHdpdGgKICAgc2ltdWx0YW5lb3VzIGhvbWUgYW5kIGZv cmVpZ24gYXR0YWNobWVudCBzdXBwb3J0IGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDUuNi4zLiAg VGhpcyBvcHRpb24gY29udGFpbnMgdGhlIGxpbmstbGF5ZXIgYWRkcmVzcyBvZiB0aGUKICAgc2Vu ZGVyIG9mIHRoZSBCaW5kaW5nIFVwZGF0ZSAoaS5lLiBhIG1vYmlsZSBub2RlKS4gIFRoaXMgb3B0 aW9uIE1VU1QKICAgYmUgc2lsZW50bHkgaWdub3JlZCBmb3Igb3RoZXIgbW9iaWxpdHkgaGVhZGVy IG1lc3NhZ2VzLgoKR1Q+IEkgdGhpbmsgdGhlIHRlcm0gP3NpbGVudGx5PyBpcyB1c2VkIGluIHRo ZSBjb250ZXh0IG9mIGRyb3BwaW5nIGEKcGFja2V0L21lc3NhZ2UgaS5lLiwgP3NpbGVudGx5IGRp c2NhcmQ/LiBJbiB0aGlzIGNhc2UgbWF5YmUgd2Ugc2hvdWxkCmp1c3Qgc2F5ID9pZ25vcmVkPy4K CgogICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMKICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICBUeXBlID0gVEJEICB8ICAgICBMZW5ndGggICAgfAog ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKICAgICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgICA6ICAgICAgICAgICAgICAgICAg ICAgICAgTGluayBMYXllciBhZGRyZXNzICAgICAgICAgICAgICAgICAgICAgOgogICAgICAgKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICsKICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA2OiBC SUQgTW9iaWxpdHkgT3B0aW9uCgoKR1Q+IEZpZ3VyZSBjYXB0aW9uIHNlZW1zIHdyb25nLiBBbHNv LCBoYXMgc3VjaCBvcHRpb24gbmV2ZXIgYmVlbgpkZWZpbmVkIGZvciBNSVB2NiBiZWZvcmU/IEkg c2VlIHRoYXQgUE1JUHY2IGRyYWZ0IGFsc28gZGVmaW5lZCB0aGUKc2FtZSBvcHRpb24uIEkgd291 bGQgaG9wZSB0aGF0IG9ubHkgb25lIHN1Y2ggb3B0aW9uIGlzIG5lZWRlZCBmb3IgYWxsCmZsYXZv cnMgb2YgTUlQdjY/CgrigKYKNS42LiAgUmV0dXJuaW5nIEhvbWUKCiAgIFRoZSBtb2JpbGUgbm9k ZSBtYXkgcmV0dXJuIHRvIHRoZSBob21lIGxpbmssIGJ5IGF0dGFjaGluZyB0byB0aGUgaG9tZQog ICBsaW5rIHRocm91Z2ggb25lIG9mIGl0cyBpbnRlcmZhY2VzLiAgV2hlbiB0aGUgbW9iaWxlIG5v ZGUgd2FudHMgdG8KICAgcmV0dXJuIGhvbWUsIGl0IHNob3VsZCBiZSBjb25maWd1cmVkIHdpdGgg aW5mb3JtYXRpb24gb24gd2hhdAogICBpbnRlcmZhY2UgaXQgbmVlZHMgdG8gdXNlLiAgVGhlIG1v YmlsZSBub2RlIG1heSB1c2Ugb25seSB0aGUKICAgaW50ZXJmYWNlIHdpdGggd2hpY2ggaXQgaXMg YXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluaywgb25seSB0aGUKICAgaW50ZXJmYWNlcyBzdGlsbCBh dHRhY2hlZCB0byB0aGUgdmlzaXRlZCBsaW5rIG9yIHVzZSBib3RoIGludGVyZmFjZXMKCkdUPiAv LyB2aXNpdGVkIGxpbmsvIHZpc2l0ZWQgbGluayhzKQoKICAgYXR0YWNoZWQgdG8gdGhlIGhvbWUg bGluayBhbmQgdmlzaXRlZCBsaW5rIHNpbXVsdGFuZW91c2x5LiAgVGhlCgpHVD4gLy8gdmlzaXRl ZCBsaW5rLyB2aXNpdGVkIGxpbmsocykKCgpXYWtpa2F3YSAoRWRpdG9yKSwgZXQgYWwuICBFeHBp cmVzIE9jdG9iZXIgMTcsIDIwMDggICAgICAgICAgICBbUGFnZSAxOV0KCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBNQ29BICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAw OAoKCiAgIGZvbGxvd2luZyBkZXNjcmliZXMgZWFjaCBvcHRpb24gaW4gbW9yZSBkZXRhaWwuCgo1 LjYuMS4gIFVzaW5nIG9ubHkgSW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBIb21lIExpbmsKCiAg IFRoZSBtb2JpbGUgbm9kZSByZXR1cm5zIGhvbWUgYW5kIGRlLXJlZ2lzdGVycyBhbGwgdGhlIGJp bmRpbmdzIGFzCiAgIHNob3duIGluIEZpZ3VyZSAyIGFuZCBhcyBkZWZpbmVkIGluIFtSRkMtMzc3 NV0uICBEZS1yZWdpc3RlcmluZyBhbGwKICAgdGhlIGJpbmRpbmdzIGlzIHRoZSBzYW1lIGFzIGJp bmRpbmcgZGUtcmVnaXN0cmF0aW9uIGZyb20gZm9yZWlnbiBsaW5rCgpHVD4gZGVsZXRlID9mcm9t IGZvcmVpZ24gbGluaz8KCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuNS4gIEFmdGVyIHRoZSBk ZS1yZWdpc3RyYXRpb24gc3RlcCwgYWxsIHRoZQogICBwYWNrZXRzIHJvdXRlZCBieSB0aGUgaG9t ZSBhZ2VudCBhcmUgb25seSBmb3J3YXJkZWQgdG8gdGhlIGludGVyZmFjZQogICBhdHRhY2hlZCB0 byB0aGUgaG9tZSBsaW5rLCBldmVuIGlmIHRoZXJlIGFyZSBvdGhlciBhY3RpdmUgaW50ZXJmYWNl cwogICBhdHRhY2hlZCB0byB0aGUgdmlzaXRlZCBsaW5rLiAgV2hpbGUgdGhlIG1vYmlsZSBub2Rl IGRlLXJlZ2lzdGVycyBhbGwKCkdUPiAvLyB2aXNpdGVkIGxpbmsvIHZpc2l0ZWQgbGluayhzKQoK ICAgdGhlIGJpbmRpbmdzIGZyb20gdGhlIGhvbWUgYWdlbnQsIGl0IG1heSBjb250aW51ZSByZWdp c3RlcmluZwogICBiaW5kaW5ncyBmb3IgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHZpc2l0ZWQgbGlu ayB0byB0aGUgY29ycmVzcG9uZGVudAoKR1Q+IC8vaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHZpc2l0 ZWQgbGluay8gaW50ZXJmYWNlKHMpIGF0dGFjaGVkIHRvCnZpc2l0ZWQgbGluayhzKQoKICAgbm9k ZSBhcyBzaG93biBpbiBGaWd1cmUgMi4KCjUuNi4yLiAgVXNpbmcgb25seSBJbnRlcmZhY2UgYXR0 YWNoZWQgdG8gdGhlIFZpc2l0ZWQgTGluawoKICAgVGhlIG1vYmlsZSBub2RlIHJldHVybnMgaG9t ZSBhbmQgc2h1dHMgZG93biB0aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvCiAgIHRoZSBob21lIGxp bmsgYXMgc2hvd24gaW4gRmlndXJlIDMuICBCZWZvcmUgc2h1dHRpbmcgZG93biB0aGUKICAgaW50 ZXJmYWNlLCBhbnkgYmluZGluZyBmb3IgdGhlIGNhcmUtb2YgYWRkcmVzcyBwcmV2aW91c2x5IGFz c29jaWF0ZWQKICAgd2l0aCB0aGUgaW50ZXJmYWNlIHNob3VsZCBiZSBkZWxldGVkLiBUbyBkZWxl dGUgdGhlIGJpbmRpbmcgY2FjaGUKICAgZW50cnksIHRoZSBtb2JpbGUgbm9kZSBTSE9VTEQgc2Vu ZCBhIGRlLXJlZ2lzdHJhdGlvbiBCaW5kaW5nIFVwZGF0ZQogICB3aXRoIHRoZSBsaWZldGltZSBz ZXQgdG8gemVybyBhbmQgaW5jbHVkZSB0aGUgY29ycmVzcG9uZGluZyBCSUQKICAgaW5mb3JtYXRp b24uICBJZiB0aGUgbW9iaWxlIG5vZGUgZG9lcyBub3Qgc2VuZCBhIGRlLXJlZ2lzdHJhdGlvbgog ICBCaW5kaW5nIFVwZGF0ZSwgdGhlIGJpbmRpbmcgZm9yIHRoZSBjYXJlLW9mIGFkZHJlc3MgcHJl dmlvdXNseQogICBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlIHJlbWFpbnMgYXQgdGhlIGhvbWUg YWdlbnQuCgpHVD4gLy8gYXQgdGhlIGhvbWUgYWdlbnQvIGF0IHRoZSBob21lIGFnZW50IHVudGls IGl0cyBsaWZldGltZSBleHBpcmVzCgogVGhpcyBiaW5kaW5nIGlzCiAgIGRlbGV0ZWQgb25seSB3 aGVuIGl0IGV4cGlyZXMuICBJbiBvcmRlciB0byBhdm9pZCB0aGlzLCB0aGUgbW9iaWxlCiAgIG5v ZGUgU0hPVUxEIHNlbmQgYSBkZS1yZWdpc3RyYXRpb24gYmluZGluZyB1cGRhdGUgZm9yIHRoZSBp bnRlcmZhY2UKICAgYXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluay4KCkdUPiBJIHRoaW5rIHRoZSBh Ym92ZSBjYW4gYmUgcmVtb3ZlZCAodGhlIFNIT1VMRCBpcyByZXBlYXRlZCBhYm92ZSBhbmQKdGhl IHJlc3QgaXMgYWxyZWFkeSBleHBsYWluZWQpLgoKCiAgIFRoaXMgc2NlbmFyaW8gaXMgbm90IHRo ZSBtb3N0IGVmZmljaWVudCBiZWNhdXNlIGFsbCB0aGUgdHJhZmZpYyB0bwogICBhbmQgZnJvbSB0 aGUgbW9iaWxlIG5vZGUgaXMgZ29pbmcgdGhyb3VnaCB0aGUgYmktZGlyZWN0aW9uYWwgdHVubmVs LAogICB3aGVyZWFzIHRoZSBtb2JpbGUgbm9kZSBpcyBub3cgYWNjZXNzaWJsZSBhdCBvbmUgaG9w IG9uIHRoZSBob21lIGxpbmsKICAgZnJvbSBpdHMgaG9tZSBhZ2VudC4KCkdUPiBUbyBhdm9pZCBq dWRnbWVudCBjYWxscyBtYXliZSB3ZSBjYW4gcmV2aXNlIHRoaXMgdG8gdGhlIGZvbGxvd2luZzoK PyAgIEluIHRoaXMgc2NlbmFyaW8sIGRlc3BpdGUgdGhlIGZhY2UgdGhhdCB0aGUgbW9iaWxlIG5v ZGUgaXMKY29ubmVjdGVkIHRvIGl0cyBob21lIGxpbmssIGFsbCBvZiBpdHMgdHJhZmZpYyBpcyBz ZW5kIGFuZCByZWNlaXZlZAp2aWEgdGhlIEhBIGFuZCBpdHMgZm9yZWlnbiBsaW5rcy4/CgoKCjUu Ni4zLiAgU2ltdWx0YW5lb3VzIEhvbWUgYW5kIFZpc2l0ZWQgTGluayBPcGVyYXRpb24KCgogICBb UHJvYmxlbXMgb2YgU2ltdWx0YW5lb3VzIEhvbWUgYW5kIEZvcmVpZ24gQXR0YWNobWVudHNdCgog ICBUaGUgbW9iaWxlIG5vZGUgcmV0dXJucyBob21lIGFuZCBjb250aW51ZXMgdXNpbmcgYWxsIHRo ZSBpbnRlcmZhY2VzCiAgIGF0dGFjaGVkIHRvIGJvdGggZm9yZWlnbiBhbmQgaG9tZSBsaW5rcyBh cyBzaG93biBpbiBGaWd1cmUgNC4gIFRoZQogICBtb2JpbGUgbm9kZSBpbmRpY2F0ZXMgdGhpcyBi eSBzZXR0aW5nIHRoZSAnSCcgZmxhZyBpbiB0aGUgQklECiAgIG1vYmlsaXR5IG9wdGlvbiBhcyBk ZWZpbmVkIGJlbG93LiAgVGhlcmUgYXJlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzCiAgIG9uIHRo ZSBSZXR1cm5pbmcgSG9tZSBwcm9jZWR1cmVzIGZvciBwb3NzaWJsZSBOZWlnaGJvciBEaXNjb3Zl cnkKICAgc3RhdGVzIGNvbmZsaWN0cyBhdCB0aGUgaG9tZSBsaW5rLgoKICAgSW4gW1JGQy0zNzc1 XSwgdGhlIGhvbWUgYWdlbnQgaW50ZXJjZXB0cyBwYWNrZXRzIG1lYW50IGZvciB0aGUgbW9iaWxl CgoKCldha2lrYXdhIChFZGl0b3IpLCBldCBhbC4gIEV4cGlyZXMgT2N0b2JlciAxNywgMjAwOCAg ICAgICAgICAgIFtQYWdlIDIwXQoKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE1D b0EgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDA4CgoKICAgbm9kZSB1c2luZyB0aGUg UHJveHkgTmVpZ2hib3IgRGlzY292ZXJ5IFtSRkMtMjQ2MV0gd2hpbGUgdGhlIG1vYmlsZQogICBu b2RlIGlzIGF3YXkgZnJvbSB0aGUgaG9tZSBsaW5rLiAgV2hlbiB0aGUgbW9iaWxlIG5vZGUgcmV0 dXJucyBob21lLAogICB0aGUgaG9tZSBhZ2VudCBkZWxldGVzIHRoZSBiaW5kaW5nIGNhY2hlIGFu ZCBzdG9wcyBwcm94eWluZyBmb3IgdGhlCiAgIGhvbWUgYWRkcmVzcyBzbyB0aGF0IGEgbW9iaWxl IG5vZGUgY2FuIGNvbmZpZ3VyZSBpdHMgaG9tZSBhZGRyZXNzIG9uCiAgIHRoZSBpbnRlcmZhY2Ug YXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluay4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgYQogICBt b2JpbGUgbm9kZSBtYXkgcmV0dXJuIGhvbWUsIGNvbmZpZ3VyZSB0aGUgaG9tZSBhZGRyZXNzIG9u IHRoZQogICBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluaywgYnV0IHN0aWxsIHVz ZSB0aGUgaW50ZXJmYWNlcwogICBhdHRhY2hlZCB0byB0aGUgZm9yZWlnbiBsaW5rcy4gIEluIHRo aXMgY2FzZSwgYSBwb3NzaWJsZSBjb25mbGljdAogICBhcmlzZXMgd2hlbiB0aGUgYm90aCB0aGUg aG9tZSBhZ2VudCBhbmQgdGhlIG1vYmlsZSBub2RlIHRyeSB0byBkZWZlbmQKICAgdGhlIGhvbWUg YWRkcmVzcy4gIElmIHRoZSBob21lIGFnZW50IHN0b3BzIHByb3h5aW5nIGZvciB0aGUgaG9tZQog ICBhZGRyZXNzLCB0aGUgcGFja2V0cyBhcmUgYWx3YXlzIHJvdXRlZCB0byB0aGUgaW50ZXJmYWNl IGF0dGFjaGVkIHRvCiAgIHRoZSBob21lIGxpbmsgYW5kIGFyZSBuZXZlciByb3V0ZWQgdG8gdGhl IGludGVyZmFjZXMgYXR0YWNoZWQgdG8gdGhlCiAgIHZpc2l0ZWQgbGlua3MuICBJdCBpcyByZXF1 aXJlZCB0byBhdm9pZCB0aGUgY29uZmxpY3QgYmV0d2VlbiB0aGUgaG9tZQogICBhZ2VudCBhbmQg dGhlIG1vYmlsZSBub2RlLCB3aGlsZSBzdGlsbCBhbGxvd2luZyB0aGUgc2ltdWx0YW5lb3VzIHVz ZQogICBvZiBob21lIGFuZCBmb3JlaWduIGxpbmtzLiAgVGhlIGZvbGxvd2luZyBkZXNjcmliZXMg dGhlIG1lY2hhbmlzbSBmb3IKICAgYWNoaWV2aW5nIHRoaXMuCgoKICAgW092ZXJ2aWV3IGFuZCBB cHByb2FjaF0KCiAgIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlIGhvbWUgYWdlbnQgTVVTVCBp bnRlcmNlcHQgYWxsIHRoZSBwYWNrZXRzCiAgIG1lYW50IGZvciB0aGUgbW9iaWxlIG5vZGUgYW5k IGRlY2lkZSB3aGV0aGVyIHRvIHNlbmQgdGhlIHRyYWZmaWMKICAgZGlyZWN0bHkgdG8gdGhlIGhv bWUgYWRkcmVzcyBvbiB0aGUgbGluayBvciB0dW5uZWwgdG8gdGhlIGNhcmUtb2YKICAgYWRkcmVz cy4gIFRoZSBob21lIGFnZW50IGludGVyY2VwdHMgYWxsIHRoZSBwYWNrZXRzIGV2ZW4gd2hlbiB0 aGUKICAgbW9iaWxlIG5vZGUgaXMgYXR0YWNoZWQgdG8gdGhlIGhvbWUgbGluayB0aHJvdWdoIG9u ZSBvZiBpdHMKICAgaW50ZXJmYWNlcy4gIFRoZSBob21lIGFnZW50IHdvdWxkIG1ha2UgdGhpcyBk ZWNpc2lvbiBiYXNlZCBvbiB0aGUKICAgdHlwZSBvZiBwYWNrZXRzIGFuZCBmbG93cy4gIEhvdyB0 byBtYWtlIHRoaXMgZGVjaXNpb24gaXMgb3V0IG9mIHNjb3BlCiAgIGluIHRoaXMgZG9jdW1lbnQu CgogICBFdmVuIHdoZW4gdGhlIG1vYmlsZSBub2RlIHJldHVybnMgaG9tZSwgaG93IGNhbiBob21l IGFnZW50IGludGVyY2VwdAogICB0aGUgcGFja2V0cyBtZWFudCBmb3IgdGhlIG1vYmlsZSBub2Rl IGF0IHRoZSBob21lIGxpbmsgb24gYmVoYWxmIG9mCiAgIHRoZSBtb2JpbGUgbm9kZT8KCkdUPiBU aGUgcXVlc3Rpb24gYWJvdmUgY2FuIGJlIHJlbW92ZWQuCgogV2UgaW50cm9kdWNlIHR3byBwb3Nz aWJsZSBzY2VuYXJpb3MsIGlsbHVzdHJhdGVkIGluCgpHVD4gLy9XZSBpbnRyb2R1Y2UgdHdvIHBv c3NpYmxlIHNjZW5hcmlvcywgaWxsdXN0cmF0ZWQgLyBUd28gc2NlbmFyaW9zCmFyZSBpbGx1c3Ry YXRlZAoKICAgRmlndXJlIDQsIGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSBIb21lIEFnZW50IGlz IGEgc2luZ2xlIHJvdXRlciBhdAogICB0aGUgaG9tZSBsaW5rIG9yIG5vdC4gIFRoZSBkaWZmZXJl bmNlIGlzIHdobyB3aWxsIGRlZmVuZCB0aGUgaG9tZQogICBhZGRyZXNzIGJ5IChQcm94eSkgTmVp Z2hib3IgRGlzY292ZXJ5IG9uIHRoZSBob21lIGxpbmsuCgogICAxLiAgTW9iaWxlIG5vZGUgZGVm ZW5kcyB0aGUgaG9tZSBhZGRyZXNzIGJ5IHRoZSByZWd1bGFyIE5laWdoYm9yCiAgICAgICBEaXNj b3ZlcnkgUHJvdG9jb2wgKGlsbHVzdHJhdGVkIGFzIHRvcG9sb2d5LWEgaW4gRmlndXJlIDQpLiAg VGhlCiAgICAgICBob21lIGFnZW50IGlzIHRoZSBzaW5nbGUgcm91dGVyIHRvIHRoZSBJbnRlcm5l dCBvbiB0aGUgaG9tZSBsaW5rLgogICAgICAgVGhlcmVmb3JlIHRoZSBob21lIGFnZW50IGlzIGNh cGFibGUgb2YgaW50ZXJjZXB0aW5nIHBhY2tldHMKICAgICAgIHdpdGhvdXQgcmVseWluZyBvbiB0 aGUgcHJveHkgTmVpZ2hib3IgRGlzY292ZXJ5IHByb3RvY29sIGFuZCB0aGUKICAgICAgIG1vYmls ZSBub2RlIGNhbiBtYW5hZ2UgdGhlIE5laWdoYm9yIENhY2hlIGVudHJ5IG9mIHRoZSBob21lCiAg ICAgICBhZGRyZXNzIG9uIHRoZSBob21lIGxpbmsgYXMgYSByZWd1bGFyIElQdjYgbm9kZS4KCiAg IDIuICBIb21lIGFnZW50IGNvbnRpbnVlIGludGVyY2VwdGluZyB0aGUgbW9iaWxlIG5vZGUncyBw YWNrZXRzIHVzaW5nCiAgICAgICBwcm94eSBOZWlnaGJvciBEaXNjb3ZlcnkgZXZlbiBhZnRlciB0 aGUgbW9iaWxlIG5vZGUncyByZXR1cm5pbmcKICAgICAgIGhvbWUgKGlsbHVzdHJhdGVkIGFzIHRv cG9sb2d5LWIgaW4gRmlndXJlIDQpLiAgVGhlIGhvbWUgYWdlbnQKICAgICAgIGNhbm5vdCBpbnRl cmNlcHQgYWxsIHRoZSBwYWNrZXRzIG1lYW50IGZvciB0aGUgbW9iaWxlIG5vZGUgYnkgSVAKCgoK V2FraWthd2EgKEVkaXRvciksIGV0IGFsLiAgRXhwaXJlcyBPY3RvYmVyIDE3LCAyMDA4ICAgICAg ICAgICAgW1BhZ2UgMjFdCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTUNvQSAg ICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDgKCgogICAgICAgcm91dGluZyBkdWUgdG8g bXVsdGlwbGUgcm91dGVycyBvbiB0aGUgaG9tZSBsaW5rLiAgRHVlIHRvIHRoZQogICAgICAgcG9z c2libGUgY29tcGV0aW5nIG5laWdoYm9yIGNhY2hlIHN0YXRlIGZvciB0aGUgaG9tZSBhZGRyZXNz LCB0aGUKICAgICAgIG1vYmlsZSBub2RlIFNIT1VMRCBOT1Qgb3BlcmF0ZSBOZWlnaGJvciBEaXNj b3ZlcnkgcHJvdG9jb2wgZm9yCiAgICAgICB0aGUgaG9tZSBhZGRyZXNzIG9uIHRoZSBob21lIGxp bmsuIFRoZSBwcm9ibGVtIGFyaXNlcyB3aGVuIHRoZQogICAgICAgaG9tZSBhZ2VudCBwZXJmb3Jt IHRoZSBuZWlnaGJvciBkaXNjb3ZlcnkgdG8gcmVzb2x2ZSB0aGUgbGluay0KICAgICAgIGxheWVy IGFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBub2RlIG9uIHRoZSBob21lIGxpbmsuICBTaW5jZSB0aGUK ICAgICAgIG1vYmlsZSBub2RlIG5ldmVyIGFuc3dlcnMgdG8gdGhlIE5laWdoYm9yIERpc2NvdmVy eSBwYWNrZXRzIGZvcgogICAgICAgdGhlIGhvbWUgYWRkcmVzcywgdGhlIGhvbWUgYWdlbnQgd291 bGQgbmVlZCB0byBrbm93IHRoZSBMaW5rLQogICAgICAgTGF5ZXIgYWRkcmVzcyBvZiB0aGUgaW50 ZXJmYWNlIHdpdGggd2hpY2ggdGhlIG1vYmlsZSBub2RlIGlzCiAgICAgICBhdHRhY2hlZCB0byB0 aGUgaG9tZSBsaW5rIGluIG90aGVyIHdheS4KCgpHVD4gSSByZS13cm90ZSB0aGUgYWJvdmUgdG8g bWFrZSBpdCBjbGVhcmVyOgoiVGhlIGhvbWUgYWdlbnQgY2Fubm90IG5hdHVyYWxseSBpbnRlcmNl cHQgYWxsIHRoZSBwYWNrZXRzIG1lYW50IGZvcgp0aGUgbW9iaWxlIG5vZGUgYnkgSVAgcm91dGlu ZyBkdWUgdG8gbXVsdGlwbGUgcm91dGVycyBvbiB0aGUgaG9tZQpsaW5rLiBJbiB0aGlzIGNhc2Us IHRoZSBtb2JpbGUgbm9kZSBNVVNUIE5PVCBvcGVyYXRlIE5laWdoYm9yCkRpc2NvdmVyeSBwcm90 b2NvbCBmb3IgdGhlIGhvbWUgYWRkcmVzcyBvbiB0aGUgaG9tZSBsaW5rLiBUaGlzIGFsbG93cwp0 aGUgaG9tZSBhZ2VudCB0byBrZWVwIHVzaW5nIHByb3h5IG5laWdoYm9yIGRpc2NvdmVyeSBhbmQg dGh1cyBpdAprZWVwcyByZWNlaXZpbmcgYWxsIHRoZSBwYWNrZXRzIHNlbnQgdG8gdGhlIG1vYmls ZSBub2RlJ3MgaG9tZQphZGRyZXNzLiBJZiB0aGUgaG9tZSBhZ2VudCwgYWNjb3JkaW5nIHRvIGl0 cyBsb2NhbCBwb2xpY3ksIG5lZWRzIHRvCmRlbGl2ZXIgcGFja2V0cyB0byB0aGUgbW9iaWxlIG5v ZGUgb3ZlciB0aGUgaG9tZSBsaW5rLCBhbiBpc3N1ZSBhcmlzZXMKd2l0aCByZXNwZWN0IHRvIGhv dyB0aGUgaG9tZSBhZ2VudCBkaXNjb3ZlcnMgdGhlIG1vYmlsZSBub2RlJ3MgbGluawpsb2NhbCBh ZGRyZXNzLiIKCgogICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uCiAgICAgICBpbnRyb2R1Y2VzIGEg bmV3IExpbmstTGF5ZXIgQWRkcmVzcyBtb2JpbGl0eSBvcHRpb24gY2FycnlpbmcgdGhlCiAgICAg ICBtb2JpbGUgbm9kZSdzIGxpbmstbGF5ZXIgYWRkcmVzcyBpbiB0aGUgQmluZGluZyBVcGRhdGUu CiAgICAgICBMaWtld2lzZSwgdGhlIG1vYmlsZSBub2RlIHdvdWxkIGFsc28ga25vdyB0aGUgbGlu ay1sYXllciBhZGRyZXNzCiAgICAgICBvZiB0aGUgZGVmYXVsdCByb3V0ZXIgYWRkcmVzcyB0byBz ZW5kIHBhY2tldHMgZnJvbSB0aGUgaG9tZSBsaW5rCiAgICAgICB3aXRob3V0IE5laWdoYm9yIERp c2NvdmVyeS4gIFRoZSBsaW5rLWxheWVyIGFkZHJlc3MgaXMgdXNlZCB0bwogICAgICAgdHJhbnNt aXQgcGFja2V0cyBmcm9tIGFuZCB0byB0aGUgbW9iaWxlIG5vZGUgb24gdGhlIGhvbWUgbGluay4K ICAgICAgIFRoZSBwYWNrZXRzIGFyZSB0cmFuc21pdHRlZCB3aXRob3V0IHRoZSBOZWlnaGJvciBE aXNjb3ZlcnkKICAgICAgIHByb3RvY29sIGJ5IGNvbnN0cnVjdGluZyB0aGUgbGluay1sYXllciBo ZWFkZXIgbWFudWFsbHkuICBUaGlzCiAgICAgICBvcGVyYXRpb24gaXMgc2ltaWxhciB0byBNb2Jp bGUgSVB2NiBbUkZDLTM3NzVdIHdoZW4gYSBtb2JpbGUgbm9kZQogICAgICAgc2VuZHMgYSBkZXJl Z2lzdHJhdGlvbiBiaW5kaW5nIHVwZGF0ZSB0byB0aGUgaG9tZSBhZ2VudCdzIGxpbmstCiAgICAg ICBsYXllciBhZGRyZXNzIGluIHJldHVybmluZyBob21lIG9wZXJhdGlvbi4KCgoKCgoKICAgW1Nl bmRpbmcgRGVyZWdpc3RyYXRpb24gQmluZGluZyBVcGRhdGVdCgoKICAgbyAgQXMgc29vbiBhcyBh IG1vYmlsZSBub2RlIHJldHVybnMgaG9tZSwgaXQgc2VuZHMgYSBkZS1yZWdpc3RyYXRpb24KICAg ICAgQmluZGluZyBVcGRhdGUgdG8gdGhlIGhvbWUgYWdlbnQgZnJvbSB0aGUgaW50ZXJmYWNlIGF0 dGFjaGVkIHRvCiAgICAgIHRoZSBob21lIGxpbmsuCgpHVD4gSSB0aGluayB0aHJvdWdob3V0IHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGlzIG1vZGUgb2Ygb3BlcmF0aW9uIHRoZQpNTiBzZW5kcyBhICpy ZWdpc3RyYXRpb24qIG5vdCBhICpkZS1yZWdpc3RyYXRpb24qLiBJbiBmYWN0IHlvdSBzaG91bGQK YWRkIHNvbWV3aGVyZSB0aGF0ICJBIEJVIHdpdGggSCBmbGFnIHNldCBNVVNUIGhhdmUgYSBub24t emVybwpMaWZldGltZSIKCgoKICAgbyAgVGhlIG1vYmlsZSBub2RlIE1VU1QgaW5jbHVkZSB0aGUg QklEIG1vYmlsaXR5IG9wdGlvbiBzcGVjaWZ5aW5nCiAgICAgIHRoZSBCSUQgdGhlIG1vYmlsZSBu b2RlIGhhZCBwcmV2aW91c2x5IGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgICAgaW50ZXJmYWNlIGF0 dGFjaGVkIHRvIHRoZSBob21lIGxpbmsuICBUaGUgJ0gnIGZsYWcgTVVTVCBiZSBzZXQgaW4KICAg ICAgdGhlIEJJRCBtb2JpbGl0eSBvcHRpb24uICBUaGUgJ0MnIGZsYWcgTVVTVCBOT1QgYmUgc2V0 IGFuZCB0aGUKICAgICAgY2FyZS1vZiBhZGRyZXNzIGZpZWxkIE1VU1QgTk9UIGJlIGluY2x1ZGVk LiAgV2hlbiB0aGUgJ0gnIGZsYWcgaXMKICAgICAgc2V0LCB0aGUgaG9tZSBhZ2VudCByZWNvZ25p emVzIHRoYXQgdGhlIG1vYmlsZSBub2RlIHdhbnRzIHRvCiAgICAgIGNvbnRpbnVlIHVzaW5nIGlu dGVyZmFjZXMgYXR0YWNoZWQgdG8gYm90aCBob21lIGFuZCB2aXNpdGVkIGxpbmtzLgogICAgICBO b3RlIHRoYXQgSCBmbGFnIE1VU1QgYmUgc2V0IGZvciBhbGwgdGhlIGJpbmRpbmcgdXBkYXRlcyBz ZW50IGZyb20KICAgICAgdGhlIG1vYmlsZSBub2RlIChleC4gIEJpbmRpbmcgVXBkYXRlIGZvciB0 aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvCiAgICAgIHRoZSBmb3JlaWduIGxpbmspLgoKR1Q+Ly8g Zm9yIHRoZSBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gdGhlIGZvcmVpZ24gbGluaykuLyBmb3IgdGhl CmludGVyZmFjZShzKSBhdHRhY2hlZCB0byBmb3JlaWduIGxpbmsocykpLgoKCgogICBvICBUaGUg bW9iaWxlIG5vZGUgU0hPVUxEIGluY2x1ZGUgdGhlIExpbmstTGF5ZXIgYWRkcmVzcyBtb2JpbGl0 eQogICAgICBvcHRpb24gdG8gbm90aWZ5IHRoZSBtb2JpbGUgbm9kZSdzIGxpbmstbGF5ZXIgYWRk cmVzcyB0byB0aGUgaG9tZQogICAgICBhZ2VudCwgdG9vLiAgVGhpcyBsaW5rLWxheWVyIGFkZHJl c3MgaXMgcmVxdWlyZWQgZm9yIHRoZSBob21lCiAgICAgIGFnZW50IHRvIHNlbmQgdGhlIEJpbmRp bmcgQWNrbm93bGVkZ2VtZW50IGFuZCB0byBmb3J3YXJkIHRoZQogICAgICBtb2JpbGUgbm9kZSdz IHBhY2tldC4KCiAgIG8gIEFjY29yZGluZyB0byBbUkZDLTM3NzVdLCB0aGUgbW9iaWxlIG5vZGUg TVVTVCBzdGFydCByZXNwb25kaW5nIHRvCiAgICAgIE5laWdoYm9yIFNvbGljaXRhdGlvbiBmb3Ig aXRzIGhvbWUgYWRkcmVzcyByaWdodCBhZnRlciBpdCBzZW5kcwoKCgpXYWtpa2F3YSAoRWRpdG9y KSwgZXQgYWwuICBFeHBpcmVzIE9jdG9iZXIgMTcsIDIwMDggICAgICAgICAgICBbUGFnZSAyMl0K CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBNQ29BICAgICAgICAgICAgICAgICAg ICAgICAgQXByaWwgMjAwOAoKCiAgICAgIHRoZSBkZXJlZ2lzdHJhdGlvbiBCaW5kaW5nIFVwZGF0 ZSB0byB0aGUgaG9tZSBhZ2VudC4gIEhvd2V2ZXIsIGluCiAgICAgIHRoaXMgc3BlY2lmaWNhdGlv biwgdGhlIG1vYmlsZSBub2RlIE1VU1QgTk9UIHJlc3BvbmQgdG8gTmVpZ2hib3IKICAgICAgU29s aWNpdGF0aW9uIGJlZm9yZSByZWNlaXZpbmcgYSBCaW5kaW5nIEFja25vd2xlZGdlbWVudCwgc2lu Y2UgdGhlCiAgICAgIGhvbWUgYWdlbnQgbWF5IGNvbnRpbnVlIHByb3h5aW5nIGZvciB0aGUgaG9t ZSBhZGRyZXNzLgoKR1Q+IHRoZSBNTiBtdXN0IG5vdCByZXNwb25kIHRvIE5TIG1lc3NhZ2VzIGJl Zm9yZSBhbmQgKmFmdGVyKgpyZWNlaXZpbmcgdGhlIEJBLCByaWdodD8KCgogICBbU2VuZGluZyBC aW5kaW5nIEFja25vd2xlZGdlbWVudF0KCiAgIG8gIFdoZW4gdGhlIGhvbWUgYWdlbnQgc2VuZHMg dGhlIEJpbmRpbmcgQWNrbm93bGVkZ2VtZW50IGFmdGVyCiAgICAgIHN1Y2NlZWRpbmcgdGhlIGJp bmRpbmcgZGUtcmVnaXN0cmF0aW9uLCBpdCBNVVNUIHNldCB0aGUgc3RhdHVzCiAgICAgIHZhbHVl IHRvIGVpdGhlciAwIFtCaW5kaW5nIFVwZGF0ZSBBY2NlcHRlZF0gb3IgdG8gW01DT0FSRVRVUk5I T01FCiAgICAgIFdPL05EUCAoVEJEKV0gaW4gdGhlIEJJRCBtb2JpbGl0eSBvcHRpb24gZGVwZW5k aW5nIG9uIGhvbWUgYWdlbnQKICAgICAgY29uZmlndXJhdGlvbiBhdCB0aGUgaG9tZSBsaW5rLiAg VGhlIG5ldyB2YWx1ZXMgYXJlOgoKICAgICAgKiAgQmluZGluZyBVcGRhdGUgQWNjZXB0ZWQgKDAp OiBORFAgaXMgcGVybWl0dGVkIGZvciB0aGUgaG9tZQogICAgICAgICBhZGRyZXNzIGF0IHRoZSBo b21lIGxpbmsuICBUaGlzIGlzIHJlZ3VsYXIgcmV0dXJuaW5nIGhvbWUKICAgICAgICAgb3BlcmF0 aW9uIG9mIFtSRkMtMzc3NV0KCiAgICAgICogIE1DT0EgUkVUVVJOSE9NRSBXTy9ORFAgKFRCRCk6 IE5EUCBpcyBwcm9oaWJpdGVkIGZvciB0aGUgaG9tZQogICAgICAgICBhZGRyZXNzIGF0IHRoZSBo b21lIGxpbmsKCiAgICAgIElmIHRoZSBiaW5kaW5nIHVwZGF0ZSBpcyByZWplY3RlZCwgdGhlIGFw cHJvcHJpYXRlIGVycm9yIHZhbHVlCiAgICAgIE1VU1QgYmUgc2V0IHRvIHRoZSBzdGF0dXMgZmll bGQuICBJbiB0aGlzIGNhc2UsIHRoZSBob21lIGFnZW50CiAgICAgIG9wZXJhdGlvbiBpcyBzYW1l IGFzIFtSRkMtMzc3NV0uCgogICBvICBJZiB0aGUgaG9tZSBhZ2VudCBpcyB0aGUgb25seSByb3V0 ZXIgYXQgdGhlIGhvbWUgbGluaywgaXQgc3RvcHMKICAgICAgcHJveHkgTmVpZ2hib3IgRGlzY292 ZXIgZm9yIHRoZSByZXF1ZXN0ZWQgaG9tZSBhZGRyZXNzIGFuZAogICAgICByZXNwb25kcyB3aXRo IHRoZSBbQmluZGluZyBVcGRhdGUgQWNjZXB0ZWRdIHN0YXR1cyB2YWx1ZSB0byB0aGUKICAgICAg bW9iaWxlIG5vZGUuICBTaW5jZSB0aGUgbW9iaWxlIG5vZGUgd2lsbCBub3QgcmVwbHkgdG8gTmVp Z2hib3IKICAgICAgU29saWNpdGF0aW9uIGZvciB0aGUgaG9tZSBhZGRyZXNzIGJlZm9yZSByZWNl aXZpbmcgdGhlIEJpbmRpbmcKICAgICAgQWNrbm93bGVkZ2VtZW50LCB0aGUgaG9tZSBhZ2VudCBT SE9VTEQgdXNlIHRoZSBsaW5rLWxheWVyIGFkZHJlc3MKICAgICAgY2FycmllZCBieSB0aGUgTGlu ayBMYXllciBBZGRyZXNzIG1vYmlsaXR5IG9wdGlvbiBpbiB0aGUgcmVjZWl2ZWQKICAgICAgQmlu ZGluZyBVcGRhdGUuICBBZnRlciB0aGUgY29tcGxldGlvbiBvZiB0aGUgYmluZGluZwogICAgICBk ZXJlZ2lzdHJhdGlvbiwgdGhlIG1vYmlsZSBub2RlIHN0YXJ0cyByZWd1bGFyIE5laWdoYm9yIERp c2NvdmVyeQogICAgICBvcGVyYXRpb25zIGZvciB0aGUgaG9tZSBhZGRyZXNzIG9uIHRoZSBob21l IGxpbmsuICBUaGUgbmVpZ2hib3IKICAgICAgY2FjaGUgZW50cnkgZm9yIHRoZSBob21lIGFkZHJl c3MgaXMgY3JlYXRlZCBieSB0aGUgcmVndWxhcgogICAgICBleGNoYW5nZSBvZiBOZWlnaGJvciBT b2xpY2l0YXRpb24gYW5kIE5laWdoYm9yIEFkdmVydGlzZW1lbnQuCgogICBvICBPbiB0aGUgb3Ro ZXIgaGFuZCwgaWYgdGhlIGhvbWUgYWdlbnQgaXMgbm90IHRoZSBvbmx5IHJvdXRlciBvbiB0aGUK ICAgICAgaG9tZSBsaW5rLCBpdCByZXR1cm5zIFtNQ09BIFJFVFVSTkhPTUUgV08vTkRQXSB2YWx1 ZSBpbiB0aGUgU3RhdHVzCiAgICAgIGZpZWxkIG9mIHRoZSBCSUQgbW9iaWxpdHkgb3B0aW9uLiAg VGhlIGhvbWUgYWdlbnQgbGVhcm5zIHRoZQogICAgICBtb2JpbGUgbm9kZSdzIGxpbmstbGF5ZXIg YWRkcmVzcyBieSByZWNlaXZpbmcgdGhlIGxpbmstbGF5ZXIKICAgICAgYWRkcmVzcyBtb2JpbGl0 eSBvcHRpb24gY2FycmllZCBieSB0aGUgQmluZGluZyBVcGRhdGUuICBJdCBzdG9yZXMKICAgICAg dGhlIGxpbmstbGF5ZXIgYWRkcmVzcyBhcyBhIG5laWdoYm9yIGNhY2hlIGVudHJ5IGZvciB0aGUg bW9iaWxlCiAgICAgIG5vZGUgc28gdGhhdCBpdCBjYW4gc2VuZCB0aGUgcGFja2V0cyB0byB0aGUg bW9iaWxlIG5vZGUncyBsaW5rLQogICAgICBsYXllciBhZGRyZXNzLgoKCkdUPiBJdCBzaG91bGQg YmUgY2xhcmlmaWVkIHRoYXQgZXZlbiBpZiB0aGUgSEEgaXMgdGhlIG9ubHkgcm91dGVyIG9uCnRo ZSBsaW5rLCBpdCBtaWdodCBzdGlsbCBtYWtlIHNlbnNlIHRvIGNvbnRpbnVlIFByb3h5LU5EUCBh cyBub3JtYWwuCk9uIHNoYXJlZCBsaW5rcywgdGhpcyBpcyBwcm9iYWJseSB0aGUgZWFzaWVzdCB3 YXkgb2YgaW50ZXJjZXB0aW5nCnBhY2tldHMsIGFzIG9wcG9zZWQgdG8gc25vb3BpbmcuIEluIGFu eSBjYXNlLCBpdCBpcyBhbiBpbXBsZW1lbnRhdGlvbgpjaG9pY2UuCgoKCgoKV2FraWthd2EgKEVk aXRvciksIGV0IGFsLiAgRXhwaXJlcyBPY3RvYmVyIDE3LCAyMDA4ICAgICAgICAgICAgW1BhZ2Ug MjNdCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTUNvQSAgICAgICAgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDgKCgogICBvICBJZiBCSUQgb3B0aW9uIGlzIG1pc3NlZCBpbiB0 aGUgQmluZGluZyBBY2tub3dsZWRnZW1lbnQsIHRoZSBob21lCiAgICAgIGFnZW50IG1pZ2h0IG5v dCByZWNvZ25pemUgdGhlIHNpbXVsdGFuZW91cyBob21lIGFuZCBmb3JlaWduCiAgICAgIGF0dGFj aG1lbnQuICBUaGUgaG9tZSBhZ2VudCBtaWdodCBwcm9jZXNzIHRoZSBkZS1yZWdpc3RyYXRpb24K ICAgICAgQmluZGluZyBVcGRhdGUgYXMgb25lIG9mIFtSRkMtMzc3NV0gYW5kIGRlbGV0ZXMgYWxs IHRoZSByZWdpc3RlcmVkCiAgICAgIGJpbmRpbmcgY2FjaGUgZW50cmllcyBmb3IgdGhlIG1vYmls ZSBub2RlLiAgVGh1cywgdGhlIG1vYmlsZSBub2RlCiAgICAgIFNIT1VMRCBzdG9wIHVzaW5nIHRo ZSBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gZm9yZWlnbiBsaW5rIGFuZCB1c2UKICAgICAgb25seSB0 aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBob21lIGxpbmsuCgoKICAgW1NlbmRpbmcgUGFj a2V0cyBmcm9tIHRoZSBIb21lIExpbmtdCgogICBvICBXaGVuIHRoZSBtb2JpbGUgbm9kZSByZWNl aXZlcyB0aGUgQmluZGluZyBBY2tub3dsZWRnZW1lbnQgd2hpY2gKICAgICAgc3RhdHVzIHZhbHVl IGlzIFtCaW5kaW5nIFVwZGF0ZSBBY2NlcHRlZF0gYW5kIEJJRCBvcHRpb24sIGl0IGNhbgogICAg ICBjb25maWd1cmUgaXRzIGhvbWUgYWRkcmVzcyB0byB0aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRv IHRoZSBob21lCiAgICAgIGxpbmsgYW5kIHN0YXJ0IG9wZXJhdGluZyBOZWlnaGJvciBEaXNjb3Zl cnkgZm9yIHRoZSBob21lIGFkZHJlc3MKICAgICAgb24gdGhlIGhvbWUgbGluay4gIFBhY2tldHMg Y2FuIGJlIHRyYW5zbWl0dGVkIGZyb20gYW5kIHRvIHRoZQogICAgICBtb2JpbGUgbm9kZSBhcyBp ZiB0aGUgbW9iaWxlIG5vZGUgaXMgYSByZWd1bGFyIElQdjYgbm9kZS4KCiAgIG8gIElmIHRoZSBt b2JpbGUgbm9kZSByZWNlaXZlcyB0aGUgW01DT0EgUkVUVVJOSE9NRSBXTy9ORFBdLCBpdCBNVVNU CiAgICAgIE5PVCBvcGVyYXRlIE5laWdoYm9yIERpc2NvdmVyeSBmb3IgdGhlIGhvbWUgYWRkcmVz cy4gIFdoZW4gdGhlCiAgICAgIG1vYmlsZSBub2RlIHNlbmRzIHBhY2tldHMgZnJvbSB0aGUgaW50 ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBob21lCiAgICAgIGxpbmssIGl0IE1VU1QgbGVhcm4gdGhl IGxpbmstbGF5ZXIgYWRkcmVzcyBvZiB0aGUgbmV4dCBob3AgKGkuZS4KICAgICAgZGVmYXVsdCBy b3V0ZXIgb2YgdGhlIG1vYmlsZSBub2RlKS4gIEEgbW9iaWxlIG5vZGUgbGVhcm5zIHRoZQogICAg ICBkZWZhdWx0IHJvdXRlcidzIGxpbmstbGF5ZXIgYWRkcmVzcyBmcm9tIGEgU291cmNlIExpbmst TGF5ZXIKICAgICAgQWRkcmVzcyBvcHRpb24gaW4gUm91dGVyIEFkdmVydGlzZW1lbnRzLiAgVGhl IG1vYmlsZSBub2RlIHNlbmRzCiAgICAgIHBhY2tldHMgZGlyZWN0bHkgdG8gdGhlIGRlZmF1bHQg cm91dGVyJ3MgbGluay1sYXllciBhZGRyZXNzLiAgVGhpcwogICAgICBpcyBkb25lIGJ5IGNvbnN0 cnVjdGluZyB0aGUgcGFja2V0IGluY2x1ZGluZyBsaW5rLWxheWVyIGhlYWRlcgogICAgICB3aXRo IHRoZSBsZWFybmVkIGxpbmstbGF5ZXIgYWRkcmVzcyBvZiB0aGUgZGVmYXVsdCByb3V0ZXIuICBU aGUKICAgICAgaG9tZSBhZ2VudCBhbHNvIGZvcndhcmRzIHRoZSBwYWNrZXQgdG8gdGhlIG1vYmls ZSBub2RlIG9uIHRoZSBob21lCiAgICAgIGxpbmsgYnkgdXNpbmcgdGhlIG1vYmlsZSBub2RlJ3Mg bGluay1sYXllciBhZGRyZXNzLiAgVGhlIGxpbmstCiAgICAgIGxheWVyIGFkZHJlc3MgU0hPVUxE IGJlIGNhY2hlZCB3aGVuIHRoZSBob21lIGFnZW50IHJlY2VpdmVkIHRoZQogICAgICBkZXJlZ2lz dHJhdGlvbiBCaW5kaW5nIFVwZGF0ZSBtZXNzYWdlLgoKCiAgIFtMZWF2aW5nIGZyb20gdGhlIEhv bWUgTGlua10KCiAgIG8gIFdoZW4gdGhlIG1vYmlsZSBub2RlIGRldGFjaGVzIGZyb20gdGhlIGhv bWUgbGluaywgaXQgU0hPVUxECiAgICAgIGltbWVkaWF0ZWx5IHNlbmQgYSBiaW5kaW5nIHVwZGF0 ZSBmb3Igb25lIG9mIGFjdGl2ZSBjYXJlLW9mCiAgICAgIGFkZHJlc3Mgd2l0aCBIIGZsYWcgdW5z ZXQuICBXaGVuIHRoZSAnSCcgZmxhZyBvZiBCSUQgb3B0aW9uIGlzCiAgICAgIHVuc2V0IGluIGFu eSBCaW5kaW5nIFVwZGF0ZSwgdGhlIGhvbWUgYWdlbnQgc3RvcCBmb3J3YXJkaW5nIHRoZQogICAg ICBtb2JpbGUgbm9kZSdzIHBhY2tldCB0byB0aGUgaG9tZSBsaW5rLgoKICAgbyAgT24gdGhlIG90 aGVyIGhhbmQsIGlmIHRoZSBtb2JpbGUgbm9kZSBkb2VzIG5vdCBoYXZlIGFueSBhY3RpdmUKICAg ICAgY2FyZS1vZiBhZGRyZXNzIHRvIHNlbmQgYSBCaW5kaW5nIFVwZGF0ZSBhbmQgbGVhdmVzIHRo ZSBob21lIGxpbmsKICAgICAgKGkuZS4gdGhlIG1vYmlsZSBub2RlIGlzIGNvbXBsZXRlbHkgZGlz Y29ubmVjdGVkKSwgdGhlIGhvbWUgYWdlbnQKICAgICAgY29udGludWVzIGZvcndhcmRpbmcgcGFj a2V0cyB0byB0aGUgbW9iaWxlIG5vZGUgdW50aWwgdGhlCiAgICAgIGV4cGlyYXRpb24gb2YgYWxs IHRoZSBiaW5kaW5nIGNhY2hlIGVudHJpZXMgZm9yIHRoZSBob21lIGFkZHJlc3MuCiAgICAgIE9u Y2UgYWxsIHRoZSBiaW5kaW5ncyBhcmUgZXhwaXJlZCwgdGhlIG1vYmlsZSBub2RlIGlzIGFzc3Vt ZWQgdG8KCgoKV2FraWthd2EgKEVkaXRvciksIGV0IGFsLiAgRXhwaXJlcyBPY3RvYmVyIDE3LCAy MDA4ICAgICAgICAgICAgW1BhZ2UgMjRdCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgTUNvQSAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDgKCgogICAgICBiZSBkaXNj b25uZWN0ZWQgY29tcGxldGVseSBmcm9tIG5ldHdvcmtzLgoKCgogICBbQ2hhbmdpbmcgQmVoYXZp b3IgZHVyaW5nIHRoZSBhdHRhY2htZW50IHRvIHRoZSBob21lIGxpbmtdCgogICBXaGVuIGEgbW9i aWxlIG5vZGUgd291bGQgY2hhbmdlIHRoZSBob21lIG9wZXJhdGlvbiB0byBTZWN0aW9uIDUuNi4x CiAgIG9yIFNlY3Rpb24gNS42LjIsIGZvbGxvd2luZyBwcm9jZWR1cmUgc2hvdWxkIGJlIHRha2Vu LgoKR1Q+IFJlbW92ZSB0aGUgYWJvdmUgc2VudGVuY2UKCiAgIElmIGEgbW9iaWxlIG5vZGUgZGVj aWRlcyB0byByZXR1cm4gaG9tZSBjb21wbGV0ZWx5IHdpdGhvdXQgYW55IGFjdGl2ZQogICBmb3Jl aWduIGxpbmsgYXR0YWNobWVudCwgaXQgc2ltcGx5IHNlbmRzIGEgZGVyZWdpc3RyYXRpb24gYmlu ZGluZwogICB1cGRhdGUgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS42LjEuICBPbmNlIHRoZSBo b21lIGFnZW50IHJlY2VpdmVzCiAgIHN1Y2ggZGUtcmVnaXN0cmF0aW9uIGJpbmRpbmcgdXBkYXRl LCB0aGUgaG9tZSBhZ2VudCBjbGVhcnMgYWxsIHRoZQogICBiaW5kaW5nIGFuZCBzdGF0ZXMgZm9y IHRoZSBtb2JpbGUgbm9kZS4KCiAgIElmIGEgbW9iaWxlIG5vZGUgd291bGQgc3RvcCB1c2luZyB0 aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBob21lCgpHVD4vLyBJZiBhIG1vYmlsZSBub2Rl IHdvdWxkLyBJZiBhIG1vYmlsZSBub2RlIGRlY2lkZXMgdG8gLwoKIGxpbmssIGl0IHNpbXBseSBz ZW5kcyBhIGJpbmRpbmcgdXBkYXRlIGZyb20gdGhlIG9uZSBvZiBhY3RpdmUgY2FyZS1vZgogICBh ZGRyZXNzLiAgSW4gdGhlIEJpbmRpbmcgVXBkYXRlLCB0aGUgbW9iaWxlIG5vZGUgc2hvdWxkIGlu Y2x1ZGUgdGhlCiAgIEJJRCBvcHRpb24gZm9yIHRoZSBjYXJlLW9mIGFkZHJlc3MgYW5kIHVuc2V0 IHRoZSBIIGZsYWcgb2YgQklECiAgIG9wdGlvbi4gIFRoZSBob21lIGFnZW50IGNsZWFycyB0aGUg c3RhdGVzIG9mIHRoZSBtb2JpbGUgbm9kZSBmb3IgdGhlCiAgIGludGVyZmFjZSBhdHRhY2hlZCB0 byB0aGUgaG9tZSBsaW5rIGFuZCBzdG9wIGZvcndhcmRpbmcgdGhlIHBhY2tldHMKICAgdG8gdGhl IG1vYmlsZSBub2RlIG9uIHRoZSBob21lIGxpbmsuCgoKCgpPbiBUdWUsIEFwciAxNSwgMjAwOCBh dCAzOjU1IFBNLCBSeXVqaSBXYWtpa2F3YQo8cnl1amkud2FraWthd2FAZ21haWwuY29tPiB3cm90 ZToKPgo+ICBIZWxsbyBhbGwsCj4KPiAgSSByZXZpc2VkIHRoZSBkcmFmdCBhY2NvcmRpbmcgdG8g dGhlIGRpc2N1c3Npb25zCj4gIGF0IHRoZSBsYXN0IElFVEYgbWVldGluZy4KPiAgSSBoYXZlbid0 IHN1Ym1pdHRlZCB0aGlzIHRvIHRoZSBJRVRGLCBwbGVhc2UKPiAgZmV0Y2ggdGhlIGRvY3VtZW50 IGZyb20KPgo+ICBodHRwOi8vd3d3LnNmYy53aWRlLmFkLmpwL35yeXVqaS9kcmFmdC1pZXRmLW1v bmFtaTYtbXVsdGlwbGVjb2EtMDcudHh0Cj4KPiAgVGhlIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg ZHJhZnQgaXMgYWxzbyBhdmFpbGFibGUgYXQKPiAgaHR0cDovL3d3dy5zZmMud2lkZS5hZC5qcC9+ cnl1amkvbWNvYWRpZmYuaHRtbAo+Cj4gIFBsZWFzZSB0YWtlIGEgbG9vayBhbmQgcHJvdmlkZSB5 b3VyIGNvbW1lbnRzLgo+Cj4gIHRoYW5rcywKPiAgcnl1amkKPgo+Cj4KPgo+Cj4gIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gIE1FWFQgbWFpbGluZyBs aXN0Cj4gIE1FWFRAaWV0Zi5vcmcKPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0Cj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KTUVYVCBtYWlsaW5nIGxpc3QKTUVYVEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21leHQK From LeighappropriateSilver@fedex.com Tue Apr 15 05:39:35 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 C3B6328C3D5; Tue, 15 Apr 2008 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.976 X-Spam-Level: X-Spam-Status: No, score=-31.976 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_12_24=2.189, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_AU=0.327, HOST_EQ_MODEMCABLE=1.368, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 FasJEhaRboM9; Tue, 15 Apr 2008 05:39:34 -0700 (PDT) Received: from gamelord.gex.ncable.net.au (185.86.99.122.cable.dyn.gex.ncable.com.au [122.99.86.185]) by core3.amsl.com (Postfix) with SMTP id 17D7B28C3DB; Tue, 15 Apr 2008 05:39:32 -0700 (PDT) Received: from 17033952754133186.11643851631912355.19347928925871080.15521856628602263 (HELO localhost.localdomain) (15155579584601776.14673120401189749.18615042167926204.16925331853323591) by 10123258756606100.16863906536827806.19897849273823875.19819674395168760 with SMTP; Tue, 15 Apr 2008 22:38:22 -1000 Date: Tue, 15 Apr 2008 22:38:22 -1000 Message-Id: <7IX505EJXVWDA922@fedex.com> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 294721 X-Header-Versions: Hewlett-Packard.0t9bn8nd3.fk@us.newsgram.hp.com X-FID: 00E76DBC-4837-39AF-B2E6-55CDEA27DCB1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Cc: , , , From: "Mona Waddell" Subject: Highly secure 256bit order processing In 2 Weeks You Can See Surprising Results. Success Is Certain. http://buenbieat.com/ From mext-bounces@ietf.org Tue Apr 15 05:42:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC393A6CAB; Tue, 15 Apr 2008 05:42: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 2798E3A6A29 for ; Tue, 15 Apr 2008 05:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.551, 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 SqqQgN-9Pmo7 for ; Tue, 15 Apr 2008 05:42:43 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by core3.amsl.com (Postfix) with ESMTP id 27A8C3A6BCB for ; Tue, 15 Apr 2008 05:42:42 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id v27so178383ele.14 for ; Tue, 15 Apr 2008 05:43:15 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SsinYlNpvr4v6Mkska7NqEHLvAo/EXfs8jrMRoRF+FU=; b=PQFFQyWpYY9yyI3hYn48e7PS8M15o0wUJQnN3h/2qMxSd4/4jHWwJeb4PO4yyvy0inCOrcB5/Vy50jcOyHmoEpWrAg9Af17CxvJJ11bvavJezq6UNgfV9XSwbEibF8RRzsSnsNakIh6l4KtJp/sG2nPLVBDJu3lyyh5b8KlqTjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=lmm+1fkcXLle22NSNAR0TMLbqziLUTMlB98bpvblSCi/2VsOA+WMt2IT1Y6Yj5sB2flnXUVL2lmHzqVeVhQ6n6UaqPtKa03Ap+7JglB7Uwg3zNN7UwFJyLDFKDprny1GgYKf0ZHk2Q9iJOsqDg6pY2XpCSVw0mQpSlI8R/H9gdE= Received: by 10.142.69.14 with SMTP id r14mr1360254wfa.255.1208263395537; Tue, 15 Apr 2008 05:43:15 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Tue, 15 Apr 2008 05:43:15 -0700 (PDT) Message-ID: Date: Tue, 15 Apr 2008 13:43:15 +0100 From: "George Tsirtsis" To: "Hesham Soliman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <6964654.171781208238886134.JavaMail.weblogic@epml05> <4804648C.1000502@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> <48048E82.6000402@piuha.net> Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 a bit confused with the discussion about MIPv4. This draft is only about MIPv6 is it not? In which case support for DualStack-MIPv6 (DSMIPv6) is indicated indirectly by either the FQDN returning A as well as AAAA records for the HA, or by the fact that an IPv4 address netowork parameter is included in the DHCP message. For this reason no flags are needed. Is the above correct? George On Tue, Apr 15, 2008 at 12:24 PM, Hesham Soliman wrote: > > On 15/04/2008, at 9:16 PM, Jari Arkko wrote: > > > >> I would have expected that the dual stack support means support for > >> DSMIP6. Anyway, now that we can indicate that the HA supports MIP4, > >> I think it would be useful to add another bit indicating support > >> for DSMIP6? > >> > > > > This is actually a problem in -13 (I reviewed it myself after sending > > out the mail this morning). > > > > I think we need to be able to indicate (a) FQDNs, (b) IPv6 > > addresses, or > > (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to > > either > > IPv4 or IPv6 addresses or both... no flags needed. > > > > And I think this draft should only focus on Mobile IPv6. We get the > > Mobile IPv6 home agent's addresses (be it v4 or v6), not something > > else... > > => Agreed. > > Hesham > > > > > > > > > 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 05:51:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D382F28C23C; Tue, 15 Apr 2008 05:51: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 A4B203A6B9B for ; Tue, 15 Apr 2008 05:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 L9+kRRriSN0A for ; Tue, 15 Apr 2008 05:51:08 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A690C3A6979 for ; Tue, 15 Apr 2008 05:51:08 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 254BC198805; Tue, 15 Apr 2008 15:51:41 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C9956198759; Tue, 15 Apr 2008 15:51:40 +0300 (EEST) Message-ID: <4804A4DD.3000207@piuha.net> Date: Tue, 15 Apr 2008 15:51:41 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: George Tsirtsis References: <6964654.171781208238886134.JavaMail.weblogic@epml05> <4804648C.1000502@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B8145C@zagh223a.ww300.siemens.net> <48048E82.6000402@piuha.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 Tsirtsis kirjoitti: > I am a bit confused with the discussion about MIPv4. This draft is > only about MIPv6 is it not? > MIPv6 only. > In which case support for DualStack-MIPv6 (DSMIPv6) is indicated > indirectly by either the FQDN returning A as well as AAAA records for > the HA, or by the fact that an IPv4 address netowork parameter is > included in the DHCP message. For this reason no flags are needed. > > Is the above correct? > Yes. I've asked for a new draft revision to fix this... Jari > George > > On Tue, Apr 15, 2008 at 12:24 PM, Hesham Soliman > wrote: > >> On 15/04/2008, at 9:16 PM, Jari Arkko wrote: >> > >> >> I would have expected that the dual stack support means support for >> >> DSMIP6. Anyway, now that we can indicate that the HA supports MIP4, >> >> I think it would be useful to add another bit indicating support >> >> for DSMIP6? >> >> >> > >> > This is actually a problem in -13 (I reviewed it myself after sending >> > out the mail this morning). >> > >> > I think we need to be able to indicate (a) FQDNs, (b) IPv6 >> > addresses, or >> > (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to >> > either >> > IPv4 or IPv6 addresses or both... no flags needed. >> > >> > And I think this draft should only focus on Mobile IPv6. We get the >> > Mobile IPv6 home agent's addresses (be it v4 or v6), not something >> > else... >> >> => Agreed. >> >> Hesham >> >> >> >> > >> > >> > 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 >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 06:33:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BE928C0D8; Tue, 15 Apr 2008 06:33: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 9B0D13A6C69 for ; Tue, 15 Apr 2008 06:33:42 -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=1.575, 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 I6ghxGMV7IPG for ; Tue, 15 Apr 2008 06:33:38 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7C09F28C3CD for ; Tue, 15 Apr 2008 06:33:37 -0700 (PDT) Received: from dummyhost13.it.uc3m.es (unknown [163.117.139.42])by smtp01.uc3m.es (Postfix) with ESMTP id 6D461582712;Tue, 15 Apr 2008 15:34:09 +0200 (CEST) Message-ID: <4804AED1.2020800@it.uc3m.es> Date: Tue, 15 Apr 2008 15:34:09 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Thierry Ernst References: <47F60F77.7000809@mccallumwhyman.com><1207866491.5040.23.camel@l ocalhost> <47FE9655.3010202@it.uc3m.es><47FF3094.1060600@mccallumwhyman.com><48025FF2.9030405@it.uc3m.es> <48031674.8000704@inria.fr> In-Reply-To: <48031674.8000704@inria.fr> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-26.4703 TC:1F TRN:52 TV:5.0.1023(15850.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: mext@ietf.org Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor AeronauticalRO 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 Thierry, I think we have a small difference on the level of the requirement. I understood from comments of the aero community that in some cases it = would simply be impossible to update the CNs (while there would some = cases where it would be possible to do that) So, afaiu, the requirement was that a solution for being suitable for = the aero community must be possible to run it in a proxy for the CN, so, = that unchanged CNs are supported. This is not a nice to have feature to compare two solutions, but that a = solution that doesn't have this is simply a non starter. But i may have misunderstood what people expressed (BTW this is what i = recall from the madrid interim, no disucssion on this particular itme in = philly) Regards, marcelo Thierry Ernst escribi=F3: > > Please let me jump in this discussion. I didn't attend last IETF = > meetings and didn't follow all the discussion, but to me, what we = > stand on is: > > 1. There is a trade-off between unchanged CNs and NEMO Basic Support = > (RFC 3963): NEMO Basic Support has been designed so that CNs (and = > MNNs, etc) are left unchanged so that even though the solution is not = > optimal there is always a possibility to deal with legacy CNs. So, it = > is acceptable to request changes for a RO solution (which MUST NOT = > prevent the use of NEMO Basic Support) > > 2. We have always said that while leaving CNs unchanged is = > recommended, it is acceptable to require extended features on the CNs = > to perform RO > > 3. If there are 2 solutions of an acceptable quality and one of these = > is keeping the CNs unchanged, that one should be selected. > > Regards, > Thierry. > > marcelo bagnulo wrote: >>> I'm not against "big" changes in controlled environments as the >>> aerospace one, but I just want to know whether those changes could be >>> made or not. >>> >>> = >> From what i understand, the question on whether updating CNs in the = >> ATS domain to support nemo RO was explicitly asked several times and = >> the question in all cases was: >> - it may be possible sometimes, but any accetable solution MUST be = >> able to work with unchanged (legacy IPv6) CNs and offloading the nemo = >> RO processing to a proxy box topologically near. >> >> Wes, is my understanding correct? has this been expressed in the = >> requirements document? would it be in the next version? I think that = >> it is important to nail these requirements down, including all the = >> relevant informaiton there (in particular with respect to this issue = >> which seems very imporntat), cause, if not people working in = >> solutions are not able to design properly >> >> 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 Apr 15 07:09:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568673A69D1; Tue, 15 Apr 2008 07:09: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 BA8A23A69D1 for ; Tue, 15 Apr 2008 07:09:14 -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=1.397, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 aADAJ15zkWMm for ; Tue, 15 Apr 2008 07:09:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E7A2C3A698D for ; Tue, 15 Apr 2008 07:09:10 -0700 (PDT) Received: from dummyhost13.it.uc3m.es (unknown [163.117.139.42])by smtp03.uc3m.es (Postfix) with ESMTP id BE87739F3B6;Tue, 15 Apr 2008 16:09:33 +0200 (CEST) Message-ID: <4804B71D.3050102@it.uc3m.es> Date: Tue, 15 Apr 2008 16:09:33 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Tony Whyman , Thierry Ernst , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "Eddy, Wesley M. (GRC-RCN0)[VZ]" , mext X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.4855 TC:01 TRN:17 TV:5.0.1023(15850.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) Subject: [MEXT] changes in the CNs 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, People have pointed out ot me offline what are the constraints expressed during the interim meeting by the aero people. The limitation is not related with software update for the CNs, but with establishing trust with all of them. This is already covered by the current draft, which states: It is also reasonable to assume trust relationshiops between each MR and a number of mobility anchor points topologically near to its CNs (these anchor points may be owned by the service providers), but it is not reasonable to assume that trust relationships can be established between an MR and any given CN itself. So, at this point, i think that the requirements w.r.t. the changes in the CNs is as Thierry nicely expressed in his email, but there is the other constrain, which is the one i have pointed out above. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 08:14:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBFE3A6B7D; Tue, 15 Apr 2008 08:14: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 6F36E3A67FE for ; Tue, 15 Apr 2008 08:14:47 -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.369, 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 bA1HjWzMEoPW for ; Tue, 15 Apr 2008 08:14:43 -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 6A35728C1D3 for ; Tue, 15 Apr 2008 08:14:40 -0700 (PDT) Received: (qmail 14391 invoked by uid 60001); 15 Apr 2008 15:15:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=z++Ca0WEspil5QK871kGRHd4bEOe1MoIqoeu8j/P1EhvaHUHLWIAwOMelvsjVQZpB2YV5N9QlhDy0nlHNmWAwI5lRMpt2lghhSvo49k0CoELomcyFqhB5AStRt4YIhw2wQTpGI4Eyj0s/mlRJ4W21nXgW+KMymfzDH+SVFXcGxc=; X-YMail-OSG: mMHuMiYVM1kGxo2sSgDKAmpPRWJq8y5OFRnvMvNjkvZFmaPZajoElrN.qpOfsqeTbElfHWEtC45PQHFDQShjpm4ddJDGjKw- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Tue, 15 Apr 2008 08:15:13 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Tue, 15 Apr 2008 08:15:13 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <461769.13747.qm@web84315.mail.re1.yahoo.com> Subject: Re: [MEXT] Result of consensus call on Home Link Detection 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="===============0156813893==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0156813893== Content-Type: multipart/alternative; boundary="0-1711222189-1208272513=:13747" --0-1711222189-1208272513=:13747 Content-Type: text/plain; charset=us-ascii If this (MIP6 operation over SDO links) is the only issue overlooked by the previous work of RFC 3775 and the bootstrapping docs, I am OK with it. However, I am not sure. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org Sent: Monday, April 14, 2008 2:46:37 AM Subject: [MEXT] Result of consensus call on Home Link Detection Folks, There's a clear consensus that we need to document how link link detection is done when one of the bootstrapping techniques is used. There's also a consensus that it is useful to document in an INFORMATIONAL document the above Raj has however suggested that we'd better to do this as part of RFC3775bis. I tend to agree with him for the following reasons: - what's missing to document home link detection has really a small footprint (i.e. 4 or 5 bullets listing the steps of home link detection that we discussed on the mailing list and which are in Suresh and George's draft) and does not represent a new feature but only a clarification since we're talking about publishing it as informational, thus it fits in RFC3775bis - it would be good anyway to reference the bootstrapping work in rfc3775bis, - from a documentation point of view, it is better to document that in one doc rather that two since the implementors doesn't have to run after too many RFCs. Thus I'd like to propose that we integrate text in George and Suresh's draft in RFC3775bis. Would the WG agree with that way forward? Thanks. --julien > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1711222189-1208272513=:13747 Content-Type: text/html; charset=us-ascii
If this (MIP6 operation over SDO links) is the only issue overlooked by the previous work of RFC 3775 and the bootstrapping docs, I am OK with it.
However, I am not sure.

Regards,

Behcet
----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org
Sent: Monday, April 14, 2008 2:46:37 AM
Subject: [MEXT] Result of consensus call on Home Link Detection

Folks,

There's a clear consensus that we need to document how link link
detection is done when one of the bootstrapping techniques is used.
There's also a consensus that it is useful to document in an
INFORMATIONAL document the above

Raj has however suggested that we'd better to do this as part of
RFC3775bis.

I tend to agree with him for the following reasons:

- what's missing to document home link detection has really a small
footprint (i.e. 4 or 5 bullets listing the steps of home link detection
that we discussed on the mailing list and which are in Suresh and
George's draft) and does not represent a new feature but only a
clarification since we're talking about publishing it as informational,
thus it fits in RFC3775bis

- it would be good anyway to reference the bootstrapping work in
rfc3775bis,

- from a documentation point of view, it is better to document that in
one doc rather that two since the implementors doesn't have to run
after too many RFCs.

Thus I'd like to propose that we integrate text in George and Suresh's
draft in RFC3775bis. Would the WG agree with that way forward?

Thanks.

--julien

> There's also a consensus that it is useful to document in an
> INFORMATIONAL document the above since it seems it is not that obvious
> to anyone by reading RFC5026.
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-1711222189-1208272513=:13747-- --===============0156813893== 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 --===============0156813893==-- From mext-bounces@ietf.org Tue Apr 15 08:21:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9B23A6830; Tue, 15 Apr 2008 08:21: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 7DB923A6768 for ; Tue, 15 Apr 2008 08:21:24 -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_53=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 OkDzoumFSuoY for ; Tue, 15 Apr 2008 08:21:19 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 3E7313A6830 for ; Tue, 15 Apr 2008 08:21:16 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so708335tid.25 for ; Tue, 15 Apr 2008 08:21:49 -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=y9Sqsxqs6gFZA/gMNTCs3nwjhpW+sXgx/RwuJ8qJr3k=; b=ex3rFQLf8/7baOg+XP7Byh42RCujdkNqRhMNiuytg1hg1jucORoNPwVqG+GytHr4X4hncNTm4TyuaSQYmVk/sq4YWVTl8S6mEmbBjSV8h4qswge63O6eHBXfSRUWXVuVBv2FDskNhqJ5MSCokc3tB2eYFMWN7RmmfKqNyVb+3Y0= 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=sth0WJImb5qoV/nPg1GFfynTtxTWi6aBNguT3U1LwpaEsqHmlWdTpGGCp8SQXSLrtdgeDHE/8i77bUjJJLrPP6Y3Bg6S7WrI2QnuPLIk58/WYC/fomD3uvH6zOcf7CF3r8vKm5J1dxhYvYiT9JBBZ10aJzEL/tUxmrAz3Y1eAmM= Received: by 10.110.92.8 with SMTP id p8mr624129tib.24.1208272908897; Tue, 15 Apr 2008 08:21:48 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Tue, 15 Apr 2008 08:21:48 -0700 (PDT) Message-ID: <1d38a3350804150821kd1d3438xd4ff33c9d0b2a159@mail.gmail.com> Date: Tue, 15 Apr 2008 23:21:48 +0800 From: "Hui Deng" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 for my late reply, I will reply Vijay's comment in the other email, for Ryuji's reply: >1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN, Since RFC 4306 do require check based on the destination address. In that case, MCOA may be able to use only 1 CoA for this direction packet delivery. If this is true, MCOA could support multiple interfaces for MN to HA direction, but could support only 1 HA to MN connection. Would be better if it could be described more clearly. Ryuji>Why?? The destination address will be home address, no? Hui> Here we talked about packet other than BU/BA message, so CoA is involved. Even for BU/BA, normally, IKE SA need be refreshed every regular time, so it is also related to which CoA is going to be used. >2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA, >From reading, it seems fine without source address checking. But I am not sure whethere there is already implementation which could verify it is workable or not. The implementation must be updated... Hui> OK >3) about which interface MIP6 will use in MCOA scenario, it is mainly about how to operate SPD, but this document may lack basic description about it. Do you want the detail description (example) of SPD? Hui> Here need further clarification more than description of SPD. >4) As the basic RFC 3775, RFC 4877 lacks interface between MIP6 and IKEv2 this document may also need consider it. right. this is universal issue:-) Hui> thanks, This is PF-KEY should be gather eyeball asap, other than leave it empty but move lots of work forward, Regards, -Hui 2008/4/15 Ryuji Wakikawa : > > Hello all, > > I revised the draft according to the discussions > at the last IETF meeting. > I haven't submitted this to the IETF, please > fetch the document from > > http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6-multiplecoa-07.txt > > The diff from the previous draft is also available at > http://www.sfc.wide.ad.jp/~ryuji/mcoadiff.html > > Please take a look and provide your comments. > > thanks, > ryuji > > > > > > _______________________________________________ > 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 Apr 15 08:34:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB328C3F9; Tue, 15 Apr 2008 08:34: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 5159328C401 for ; Tue, 15 Apr 2008 08:34:46 -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_53=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 2bZisvBQJpKx for ; Tue, 15 Apr 2008 08:34:45 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 2B22D28C3FA for ; Tue, 15 Apr 2008 08:34:44 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so710191tid.25 for ; Tue, 15 Apr 2008 08:35:17 -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=TowRgXFxS29EHxGif49TH44X8UwHtAl86p56HZFkp1c=; b=oKGhYTC9qNvAbtgZ26iGZ4atu/yE0XOUPDgEVkueNyYMRoEcXLYdJ6k6yCWYvsjLwCEegFoZ/VM04B7BTOv0znKNneR0MSFwunaXcW7hsSEfVxBuH7N+prZWCd+97poj/PYHAij9Kqmno0/Af3C59cz1u9AtLGS9tC2tFH3fjT4= 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=jIbzhlrPdqAuUZ1NIcCralRJlqCIToXv8pN3h2pYAFCXlhpUKT/evrYFhYUB2flxMwGo/dkg4pzBIALqe3EaKzd8Szhf3caf8k60By/gmNtynXFTsKrQib6od5pgDXZ6+XphVY3ahF9MMNT5aNdbQYyADwymOFn+6f6FlRYAy3A= Received: by 10.110.92.8 with SMTP id p8mr624543tib.24.1208273116929; Tue, 15 Apr 2008 08:25:16 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Tue, 15 Apr 2008 08:25:16 -0700 (PDT) Message-ID: <1d38a3350804150825t1f6dd53aqc4a157d3beddadf7@mail.gmail.com> Date: Tue, 15 Apr 2008 23:25:16 +0800 From: "Hui Deng" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 is my reply to Vijay's comments, >1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN, Since RFC 4306 do require check based on the destination address. In that case, MCOA may be able to use only 1 CoA for this direction packet delivery. If this is true, MCOA could support multiple interfaces for MN to HA direction, but could support only 1 HA to MN connection. Would be better if it could be described more clearly. Ryuji> Why?? The destination address will be home address, no? Vijay> You have think about the sequence of operations in more detail. One possible sequence is explained below. - The HA receives packets for the MN's home address - The HA determines which binding to use for the particular flow. The binding will determine what CoA to use. - Then the packets hit the SPD. If the filters match, IPsec tunnel encryption will be applied. You should be careful not to put the CoA in the SPD. SPD lookup will be based on the home address. Hui> As I replied to Ryuji's email, CoA does exist in the SPD >2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA, >From reading, it seems fine without source address checking. But I am not sure whethere there is already implementation which could verify it is workable or not. The implementation must be updated... >3) about which interface MIP6 will use in MCOA scenario, it is mainly about how to operate SPD, but this document may lack basic description about it. Do you want the detail description (example) of SPD? Vijay>SPD does not have the CoA information. So I ma not sure what we can explain better. Hui> Same as above, Thanks -Hui 2008/4/15 Ryuji Wakikawa : > > Hello all, > > I revised the draft according to the discussions > at the last IETF meeting. > I haven't submitted this to the IETF, please > fetch the document from > > http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6-multiplecoa-07.txt > > The diff from the previous draft is also available at > http://www.sfc.wide.ad.jp/~ryuji/mcoadiff.html > > Please take a look and provide your comments. > > thanks, > ryuji > > > > > > _______________________________________________ > 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 Apr 15 09:21:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4E63A6E4D; Tue, 15 Apr 2008 09:21: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 5DF3C3A6C07 for ; Tue, 15 Apr 2008 09:21: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 TBfz3D81XmtN for ; Tue, 15 Apr 2008 09:21:21 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 4A79C3A6E57 for ; Tue, 15 Apr 2008 09:21:18 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m3FGLnqn012931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 17:21:49 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m3FGLltD010445; Tue, 15 Apr 2008 17:21:48 +0100 Message-ID: <4804D61E.7090605@mccallumwhyman.com> Date: Tue, 15 Apr 2008 17:21:50 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: marcelo bagnulo References: <4804B71D.3050102@it.uc3m.es> In-Reply-To: <4804B71D.3050102@it.uc3m.es> Cc: mext , =?ISO-8859-1?Q?Carlos_Jes=FA?=@core3.amsl.com Subject: Re: [MEXT] changes in the CNs 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, Seems an odd assumption to me. The one thing that you can usually assume in ATC is that there is a trust relationship between an aircraft (MR) and the ATC Centre (CN). Regards Tony marcelo bagnulo wrote: > Hi, > > People have pointed out ot me offline what are the constraints > expressed during the interim meeting by the aero people. > > The limitation is not related with software update for the CNs, but > with establishing trust with all of them. > > This is already covered by the current draft, which states: > > It is also reasonable to assume trust relationshiops between each MR > and a number of mobility anchor points topologically near to its CNs > (these anchor points may be owned by the service providers), but it > is not reasonable to assume that trust relationships can be > established between an MR and any given CN itself. > > So, at this point, i think that the requirements w.r.t. the changes in > the CNs is as Thierry nicely expressed in his email, but there is the > other constrain, which is the one i have pointed out above. > > Regards, marcelo > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 09:27:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8FD3A6B74; Tue, 15 Apr 2008 09:27: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 D3D5E3A6B74 for ; Tue, 15 Apr 2008 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=1.522, 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 Z+OkeE9ndb4U for ; Tue, 15 Apr 2008 09:27:53 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C2DBF3A6A30 for ; Tue, 15 Apr 2008 09:27:52 -0700 (PDT) Received: from dummyhost13.it.uc3m.es (unknown [163.117.139.42])by smtp01.uc3m.es (Postfix) with ESMTP id D9267582788;Tue, 15 Apr 2008 18:28:15 +0200 (CEST) Message-ID: <4804D79F.1010700@it.uc3m.es> Date: Tue, 15 Apr 2008 18:28:15 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Tony Whyman References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com> In-Reply-To: <4804D61E.7090605@mccallumwhyman.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.6445 TC:1F TRN:34 TV:5.0.1023(15852.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: mext Subject: Re: [MEXT] changes in the CNs 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 FWIW, i am just repeating what people have expressed in the meeting. below... Tony Whyman escribi=F3: > Marcelo, > > Seems an odd assumption to me. The one thing that you can usually = > assume in ATC is that there is a trust relationship between an = > aircraft (MR) and the ATC Centre (CN). > right, there is trust between the MR and the ATC center, but not with = every CN within the network, since it seemed that the provision of trust = (like provisioning of certificates) would be hard for every CN. It is = acceptable though t provision a certificate for a single node within a = given network that acts like a proxy for the CNs topologically close, = makes sense? regards, marcelo > Regards > > Tony > > marcelo bagnulo wrote: >> Hi, >> >> People have pointed out ot me offline what are the constraints = >> expressed during the interim meeting by the aero people. >> >> The limitation is not related with software update for the CNs, but = >> with establishing trust with all of them. >> >> This is already covered by the current draft, which states: >> >> It is also reasonable to assume trust relationshiops between each MR >> and a number of mobility anchor points topologically near to its CNs >> (these anchor points may be owned by the service providers), but it >> is not reasonable to assume that trust relationships can be >> established between an MR and any given CN itself. >> >> So, at this point, i think that the requirements w.r.t. the changes = >> in the CNs is as Thierry nicely expressed in his email, but there is = >> the other constrain, which is the one i have pointed out above. >> >> Regards, marcelo >> >> >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 09:42:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DEC28C42F; Tue, 15 Apr 2008 09:42: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 DF3FA28C164 for ; Tue, 15 Apr 2008 09:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.457 X-Spam-Level: X-Spam-Status: No, score=-4.457 tagged_above=-999 required=5 tests=[AWL=2.142, 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 FZpVQ+1hJJgc for ; Tue, 15 Apr 2008 09:42:15 -0700 (PDT) Received: from ndjsbar01.ndc.nasa.gov (ndjsbar01.ndc.nasa.gov [198.120.25.38]) by core3.amsl.com (Postfix) with ESMTP id A385528C446 for ; Tue, 15 Apr 2008 09:40:47 -0700 (PDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id D9E3789E592; Tue, 15 Apr 2008 11:41:20 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov with ESMTP id 1BJqEH1iN3njRQt9; Tue, 15 Apr 2008 11:41:20 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 11:41:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:41:19 -0500 Message-ID: In-Reply-To: <4804D79F.1010700@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: changes in the CNs Thread-Index: AcifFbzSgT7xgTbzR3u/qZ7wFmeISwAAOotA References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "marcelo bagnulo" , "Tony Whyman" X-OriginalArrivalTime: 15 Apr 2008 16:41:20.0855 (UTC) FILETIME=[88D16E70:01C89F17] Cc: mext Subject: Re: [MEXT] changes in the CNs 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 >-----Original Message----- >From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] = >Sent: Tuesday, April 15, 2008 12:28 PM > >FWIW, i am just repeating what people have expressed in the meeting. > >below... > >Tony Whyman escribi=F3: >> Marcelo, >> >> Seems an odd assumption to me. The one thing that you can usually = >> assume in ATC is that there is a trust relationship between an = >> aircraft (MR) and the ATC Centre (CN). I think the consensus was that in the long-term, what Tony says will be the case, but in the nearer-term (next several years), the PKI will not yet be deployed and it is unclear how long it will take to get it rolled out globally to all ANSPs and equipment. This is a parallel/supporting effort whose website and minutes may be of interest: https://www.jcg.aero/index.php Hugh Mote, who has been participating in MEXT meetings is active there. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 10:29:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3CD28C34C; Tue, 15 Apr 2008 10:29: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 60F923A6EA4 for ; Tue, 15 Apr 2008 10:29:53 -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 w-48fuF9QTCX for ; Tue, 15 Apr 2008 10:29:52 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A970E3A6B45 for ; Tue, 15 Apr 2008 10:29:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m3FHU78D000089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Apr 2008 10:30:12 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m3FHU7ko022572; Tue, 15 Apr 2008 12:30:07 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m3FHU0Q2022156; Tue, 15 Apr 2008 12:30:06 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 10:30:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 10:29:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDFE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] changes in the CNs thread-index: AcifFbzSgT7xgTbzR3u/qZ7wFmeISwAAOotAAAGseTA= References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com><4804D79F.1010700@it.uc3m.es> From: "Templin, Fred L" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "marcelo bagnulo" , "Tony Whyman" X-OriginalArrivalTime: 15 Apr 2008 17:30:06.0525 (UTC) FILETIME=[58A73ED0:01C89F1E] Cc: mext Subject: Re: [MEXT] changes in the CNs 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 Wesley, >I think the consensus was that in the long-term, what Tony says will >be the case, but in the nearer-term (next several years), the PKI >will not yet be deployed and it is unclear how long it will take to >get it rolled out globally to all ANSPs and equipment. I don't have much knowledge in this space, but I am wondering about the PKI. Would it be feasible to deploy pre-placed keys even before a PKI becomes generally available? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 11:13:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8C63A6ABA; Tue, 15 Apr 2008 11:13: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 A01493A6ABA for ; Tue, 15 Apr 2008 11:13: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 PNh7iU6NIrO4 for ; Tue, 15 Apr 2008 11:13:37 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 7C7783A69CD for ; Tue, 15 Apr 2008 11:13:37 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m3FIE6dc013827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 19:14:07 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m3FIE4xF011036; Tue, 15 Apr 2008 19:14:06 +0100 Message-ID: <4804F070.5030104@mccallumwhyman.com> Date: Tue, 15 Apr 2008 19:14:08 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> In-Reply-To: Cc: mext Subject: Re: [MEXT] changes in the CNs 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 Wesley, Thanks for clarifying that. The moto of the ATC Business is "if it ain't broke don't fix it" and I = would expect any deployment of ATN-IP to respect this and follow the = same roll out pattern as ATN-OSI - after all if it worked once... That model started with years of prototypes and trials, followed by a = deployment programme that recruited a core set of pioneer airlines in = Europe around a single ATC Centre, in order to help prove the system and = give the vendors a chance to develop stable products. Only now has the = full roll out programme begun, backed by a mandate that will apply to = all aircraft flying above FL280. Start to finish was around 16 years. Expect the same to happen with an ATN-IP. There will be several years of = trials and prototypes before some pioneer airlines start to use it. Only = once the system is proven and demonstrated to be at least as safe as the = current system, would full roll out begin. Hopefully the experience = gained first time around would be used to speed the process up - but how = much is another matter. During the trials and prototypes phase only a local PKI is required and = expect it to be refined several times during the learning process. Even = during the pioneer phase, only a local PKI would be required, but its = implementation should anticipate the later roll out to first regional = use and then global. So, you can see why I have a relaxed view about PKI deployment. Regards Tony Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> -----Original Message----- >> From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] = >> Sent: Tuesday, April 15, 2008 12:28 PM >> >> FWIW, i am just repeating what people have expressed in the meeting. >> >> below... >> >> Tony Whyman escribi=F3: >> = >>> Marcelo, >>> >>> Seems an odd assumption to me. The one thing that you can usually = >>> assume in ATC is that there is a trust relationship between an = >>> aircraft (MR) and the ATC Centre (CN). >>> = > > > I think the consensus was that in the long-term, what Tony says will > be the case, but in the nearer-term (next several years), the PKI > will not yet be deployed and it is unclear how long it will take to > get it rolled out globally to all ANSPs and equipment. > > This is a parallel/supporting effort whose website and minutes may be > of interest: > https://www.jcg.aero/index.php > Hugh Mote, who has been participating in MEXT meetings is active there. > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 15 19:25:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97603A6A04; Tue, 15 Apr 2008 19:25: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 D20C13A6A04 for ; Tue, 15 Apr 2008 19:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMLodO2NzDrR for ; Tue, 15 Apr 2008 19:25:26 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 063843A6A62 for ; Tue, 15 Apr 2008 19:25:22 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE00HVCBX0GJ@mailout2.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 11:22:13 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE009RHBX0K2@ms5.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 11:22:12 +0900 (KST) Content-return: prohibited Date: Wed, 16 Apr 2008 02:22:12 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <22124704.234881208312532747.JavaMail.weblogic@epml14> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080416022152888@heejin.jang X-MTR: 20080416022152888@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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. Please see below. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, April 15, 2008 8:16 PM > To: Premec, Domagoj > Cc: heejin.jang@samsung.com; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > > > I would have expected that the dual stack support means > support for DSMIP6. Anyway, now that we can indicate that the > HA supports MIP4, I think it would be useful to add another > bit indicating support for DSMIP6? > > > > This is actually a problem in -13 (I reviewed it myself after > sending out the mail this morning). > > I think we need to be able to indicate (a) FQDNs, (b) IPv6 > addresses, or > (c) IPv4 addresses. DNS is quite capable of resolving an FQDN > to either > IPv4 or IPv6 addresses or both... no flags needed. Ok. for FQDN sub-opt-code, I'll fallback to the previous version. (v12). > And I think this draft should only focus on Mobile IPv6. We > get the Mobile IPv6 home agent's addresses (be it v4 or v6), > not something else... " focus on Mobile IPv6..not something else..." means there is no need to add what Premec suggested, that is IPv4 HoA, IPv4 subnet? For clarity, then I'll revise as below. (Your previous mail was also considered.) OLD: Sub-opt-code 0 Reserved 1 Home network identifier (only admitted in a Home Network Information option) 2 IPv6 home network prefix 3 IPv6 home agent address 4 IPv4 address of the dual-stacked home agent 5 Home agent FQDN 6 .. (2^16-1) Reserved NEW: 0 Reserved 1 Home network identifier (only admitted in a Home Network Information option) 2 IPv6 home network prefix 3 IPv6 home agent address 4 Home agent FQDN 5 .. (2^16-1) Reserved /* Node that the below is for IPv6 address sub-opt-code, not for FQDN sub-opt-code*/ When the Sub-opt-code is set to 3, the Home Network Parameter field MUST consist of a Flags octet followed by the 128-bit IPv6 address of the home agent. The most significant bit of the Flags octet encodes a DSMIP field, and the seven remaining bits are Reserved (must be set to 0 and ignored on receipt). A Value of 1 in the DSMIP field indicates that the home agent specified by the following IPv6 address has an IPv4 address and has a capability to support DSMIPv6 [DSMIPv6]. A value of 0 means that the home agent only supports Mobile IPv6. Kindly let me know my understanding is right or not. - Best regards, Heejin _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 01:21:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5374028C416; Wed, 16 Apr 2008 01:21: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 8FBE328C413 for ; Wed, 16 Apr 2008 01:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 FHH7aXc2zoY8 for ; Wed, 16 Apr 2008 01:21:31 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5283C28C3F9 for ; Wed, 16 Apr 2008 01:21:31 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9D5BE198774; Wed, 16 Apr 2008 11:22:04 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5F4C51986D5; Wed, 16 Apr 2008 11:22:04 +0300 (EEST) Message-ID: <4805B72D.8000603@piuha.net> Date: Wed, 16 Apr 2008 11:22:05 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <22124704.234881208312532747.JavaMail.weblogic@epml14> In-Reply-To: <22124704.234881208312532747.JavaMail.weblogic@epml14> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 Heejin, >> This is actually a problem in -13 (I reviewed it myself after >> sending out the mail this morning). >> >> I think we need to be able to indicate (a) FQDNs, (b) IPv6 >> addresses, or >> (c) IPv4 addresses. DNS is quite capable of resolving an FQDN >> to either >> IPv4 or IPv6 addresses or both... no flags needed. >> > > Ok. for FQDN sub-opt-code, I'll fallback to the previous version. (v12). > > >> And I think this draft should only focus on Mobile IPv6. We >> get the Mobile IPv6 home agent's addresses (be it v4 or v6), >> not something else... >> > > " focus on Mobile IPv6..not something else..." means there is no need to > add what Premec suggested, that is IPv4 HoA, IPv4 subnet? > The IPv6 network prefix is there presumably because we want to enable the use of the HA anycast address. There is nothing corresponding in IPv4, so we don't need a prefix. And this draft does not give us IPv6 home addresses, so there is no need for IPv4 home addresses either. > For clarity, then I'll revise as below. (Your previous mail was also considered.) > > OLD: > Sub-opt-code > > 0 Reserved > 1 Home network identifier (only admitted > in a Home Network Information option) > 2 IPv6 home network prefix > 3 IPv6 home agent address > 4 IPv4 address of the dual-stacked home agent > 5 Home agent FQDN > 6 .. (2^16-1) Reserved > NEW: > 0 Reserved > 1 Home network identifier (only admitted > in a Home Network Information option) > 2 IPv6 home network prefix > 3 IPv6 home agent address > 4 Home agent FQDN > 5 .. (2^16-1) Reserved > No, this is wrong. You *do* need to have IPv4 address of the Mobile IPv6 home agent as well. Don't change this part, just change the parts where you talked about Mobile IPv4... these options will give you access to the Mobile IPv6 service, be it over IPv4, IPv6 or whatever. But these options do not give you access to Mobile IPv4 service. > /* Node that the below is for IPv6 address sub-opt-code, not for FQDN sub-opt-code*/ > > When the Sub-opt-code is set to 3, the Home Network Parameter field > MUST consist of a Flags octet followed by the 128-bit IPv6 address > of the home agent. The most significant bit of the Flags octet encodes > a DSMIP field, and the seven remaining bits are Reserved (must be set to 0 and > ignored on receipt). A Value of 1 in the DSMIP field indicates that > the home agent specified by the following IPv6 address has an IPv4 address > and has a capability to support DSMIPv6 [DSMIPv6]. A value of 0 means that > the home agent only supports Mobile IPv6. > I don't see a need for this. You will deliver one or several of: IPv4 address, IPv6 address, IPv6 prefix, FQDN. Depending on what you get and how the FQDN is resolved, you will either have or not have IPv4 addresses in your final set. If you do, that means that server should be contactable by IPv4 using DSMIP. No flag needed. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 01:40:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525D928C3B7; Wed, 16 Apr 2008 01:40: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 9934B28C40B for ; Wed, 16 Apr 2008 01:40: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 d1JGGpFpKbkq for ; Wed, 16 Apr 2008 01:40:25 -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 0CC993A6F23 for ; Wed, 16 Apr 2008 01:40:12 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so1368275and.122 for ; Wed, 16 Apr 2008 01:40:48 -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=Cz7qM6xQrE07YGphj10WlMMBrKNZlmawBbtP3+rKXZw=; b=PEOC2K6TlqBTJyobm7hudX/rXI4TboG7ychoNWbddxH/XaisoM/r25V9IdIJihrzBFf7AAGoWkd4pfNFAtuEqPgQ1EQ77Nz2J4b5Ar26V6d1rPgwi+RJAW09i7WMGPWXw9PJNHaEPF1ERyFzYZptwmXbwvX7BxFPsYsrhUC+/3M= 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=PsoHJmD5SCrwgagkqrB+WfkK3q5qIcv90N2uTyXY3fue+WylEtF4+Pd5d3c7LFPhDKlNrrnlhUdhZ2tPki7Wrj/FNP03yX3YSITgu/D4YnQ8F7YvlC3j/L8GPdVfDzTTTE2RtBgW6ewrAU3dwQ+B+IppzZ0LrDR+5y18h4Q0HvE= Received: by 10.100.249.9 with SMTP id w9mr16942605anh.63.1208335247883; Wed, 16 Apr 2008 01:40:47 -0700 (PDT) Received: from ?58.98.38.35? ( [58.98.38.35]) by mx.google.com with ESMTPS id g9sm19219244wra.10.2008.04.16.01.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Apr 2008 01:40:46 -0700 (PDT) From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 17:40:37 +0900 X-Mailer: Apple Mail (2.919.2) Cc: Ryuji Wakikawa , mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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-2022-jp" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello George, Thanks for comments! It looks like your comments are more editorial one. Can I assume you mostly agree on the changes? I will revise the document quickly and post it again to MEXT. On 2008/04/15, at 21:29, George Tsirtsis wrote: > Hi Ryuji, > > This looks really good. > I have a number of detailed comments which should be easy to resolve, > > 1) You may want to use the IPv6 prefix (2001:DB8::/32) reserved for > documentation (see RFC3849) I will update the doc. I wasn't aware of this reserved prefix:) > 2) I am suggesting that when the H flag is set in the BU, it should be > viewed as a registration, rather than de-registration. OK. But I have some comments on this. Please find my comments inline below. > More comments inline... > > Thanks > George > -------------------------------------------------------------------------------------------- > > 3. Protocol Overview > $B!D(B > 1. The mobile node uses only the interface with which it attaches > to > the home link illustrated in Figure 2. It de-registers all > bindings related to all care-of addresses to the home agent. > The > interfaces still attached to the visited link(s) are no longer > going to be receiving any encapsulated traffic from the home > agent. On the other hand, the mobile node can continue > communicating with the correspondent node from the other > interfaces attached to foreign links by using route > optimization. > Even if the mobile node is attached to the home link, it can > still send Binding Updates for other active care-of addresses > (CoA2 and CoA3) to correspondent nodes. Since the correspondent > node has bindings, packets are routed to each Care-of Addresses > directly. > > +----+ > | CN | > +--+-+ > | > +---+------+ +----+ > +------+ Internet |----------+ HA | > | +--------+-+ +--+-+ > CoA2| | | Home Link > +--+--+ | --+---+------ > | MN +========+ | | > +--+--+ | | | > CoA3| +---|-----------+ > +---------------+ > > Binding Cache Database: > home agent's binding > none > correspondent node's binding > binding [a:b:c:d::EUI care-of address2 BID2] > binding [a:b:c:d::EUI care-of address3 BID3] > > Figure 2: Using only Interface Attached to Home Link > > > GT> Why is this figure different than the others below? Is the home > link crossing over the CoA3 link, necessary? The figure could be shown > as the once below no? No necessary... These figures were located at the appendix in the previous version and just be reused. I will update the figure. > $B!D(B > 3. The mobile node may simultaneously use both the interface > attached to the home link and the interfaces still attached to > the visited link(s) as shown in Figure 4. There are two > possible > topologies whether the home agent is single router at the home > link or not. The operation of Neighbor Discovery [RFC-2461] is > different in the two topologies. The home agent and the > correspondent node have the binding entries listed in Figure 4 > in > their binding cache database in both topologies. The home agent > also knows that the mobile node has attached to the home link. > All the traffic from the Internet are intercepted by the home > > GT> //are/is > > agent first and routed to either the interface attached to the > home link or the one attached to the foreign links. How to make > > GT> // the one attached to the foreign links./to one of the foreign > links. > > the decision is out of scope in this document. > > > > > > > > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 10] > > Internet-Draft MCoA April > 2008 > > > Topology-a) > +----+ > | CN | > +--+-+ > | > +---+------+ +----+ > +------+ Internet |----------+ HA | > | +----+-----+ +--+-+ > CoA2| | | Home Link > +--+--+ | --+---+------ > | MN +========+ | > +--+--+ CoA1 | > CoA3 | | > +---------------------------+ > > Topology-b) > +----+ > | CN | > +--+-+ > | > +---+------+ Router +----+ > +------+ Internet |-------R | HA | > | +----+-----+ | +--+-+ > CoA2| | | | Home Link > +--+--+ | --+-+-------+------ > | MN +========+ | > +--+--+ CoA1 | > CoA3 | | > +---------------------------+ > > > GT> I think the CoA3 shown in this figures should not be there, tight? > you are right. will fix this, too. > Binding Cache Database: > home agent's binding > binding [a:b:c:d::EUI care-of address1 BID1] > binding [a:b:c:d::EUI care-of address2 BID2] > correspondent node's binding > binding [a:b:c:d::EUI care-of address1 BID1] > binding [a:b:c:d::EUI care-of address2 BID2] > > > Figure 4: Simultaneous Home and Visited Link Operation > > > > > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 11] > > Internet-Draft MCoA April > 2008 > > > 4. Mobile IPv6 Extensions > > This section summarizes the extensions to Mobile IPv6 necessary for > manage multiple bindings. > > 4.1. Binding Cache Structure and Binding Update List > > The BID is required to be stored in the binding cache and binding > update list structure. > > The sequence number value SHOULD be shared among all the binding > update list. Whenever a mobile node sends either individual or bulk > binding update, the sequence number is incremented the value of the > previous sequence number. > > GT>// is incremented the value of the previous sequence number. // is > incremented. > > On the other hand, if a mobile node > manages an individual sequence value per binding update list, a > mobile node SHOULD carefully select the sequence number value for > the > bulk binding update. This is because all the bulk-registered > bindings use the same Sequence Number specified in the Binding > Update. If each binding uses different sequence number, a mobile > node MUST use the largest sequence number from the Binding Update > list entries used for the bulk registration. If the mobile node > cannot select a sequence number for all the bindings due to sequence > number out of window, it MUST NOT use the bulk registration for the > binding whose sequence number is out of window. A separate Binding > Update should be sent for the binding. > > 4.2. Binding Identifier Mobility Option > > The Binding Identifier mobility option is included in the Binding > Update, Binding Acknowledgement, Binding Refresh Request, and Care- > of > Test Init and Care-of Test message. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Type = TBD | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Binding ID (BID) | Status |C|O|H|D| > Resrvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-------------------------------+ > > + + > : IPv4 or IPv6 care-of address > (CoA) : > > + + > > +---------------------------------------------------------------+ > > Figure 5: BID Mobility Option > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 12] > > Internet-Draft MCoA April > 2008 > > > Type > > Type value for Binding Identifier is TBD > > Length > > 8-bit unsigned integer. Length of the option, in octets, > excluding the Type and Length fields. It MUST be set to 4 when > the 'C' flag is unset. Otherwise, the Length value MUST be set > to > either 8 or 20 depending on the 'D' (DSMIPv6) flag. > > Binding ID (BID) > > The BID which is assigned to the binding indicated by the care-of > address in the Binding Update or the BID mobility option. The > BID > is a 16-bit unsigned integer. The value of zero is reserved and > MUST NOT be used. > > Status > > When the Binding Identifier mobility option is included in a > Binding Acknowledgement, this field overwrites the status field > in > the Binding Acknowledgement. If this field is zero, the receiver > MUST use the registration status stored in the Binding > Acknowledgement message. This Status field is also used to carry > error information related to the care-of address test in the > Care-of Test message. The status is 8-bit unsigned integer. The > possible status codes are the same as the status codes of Binding > Acknowledgement. > > Care-of address (C) flag > > When this flag is set, it indicates that a valid care-of address > is present in the care-of address field in the BID mobility > option. This flag MUST be set whenever the mobile node sends > multiple care-of addresses in a single Binding Update, i.e., bulk > registration. It MAY also used as a substitute for alternate > > GT> //It MAY also used/It MAY also be used > > care-of address option even for Binding Updates that are sent > only > for one care-of address. This flag is valid only for Binding > Update sent to the home agent. > > Overwrite (O) flag > > When this flag is set, a mobile node requests the recipient to > replace all the bindings to binding entries stored in a Binding > Update. > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 13] > > Internet-Draft MCoA April > 2008 > > > Simultaneous Home and Foreign Binding (H) flag > > This flag indicates that the mobile node registers multiple > bindings to the home agent while is attached to the home link. > This flag is valid only for a Binding Update sent to the home > agent. > > DSMIPv6 (D) flag > > This flag indicates that the care-of address is an IPv4 address. > When this flag is set, the care-of address field MUST contain an > IPv4 address. > > > GT> I can not remember if this was ever discussed but do we really > need flags C and D? It seems to me that the Length field can be 4 (CoA > not included), 12 (v4CoA), or 20 (v6CoA), which provides all the info > we need. Good point. The receiver can tell which address is stored in the option. > > > Reserved > > 5 bits Reserved field. The reserved field MUST be zero. > > Care-of Address > > This field has the variable length depending on the specified > flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 > care-of address for the corresponding BID is stored in this > field. > If both 'C' and 'D' flags are set, an IPv4 Care-of Address is > carried in this field. This field MUST NOT be used if a Binding > Identifier mobility option is included in any other message other > than a Binding Update or if the 'C' flag is not set. > > $B!D(B > 4.4. Link Layer Address Mobility Option > > The Link Layer Address mobility option is included only in the > deregistration Binding Update when a mobile node returns home with > simultaneous home and foreign attachment support described in > Section 5.6.3. This option contains the link-layer address of the > sender of the Binding Update (i.e. a mobile node). This option MUST > be silently ignored for other mobility header messages. > > GT> I think the term ?silently? is used in the context of dropping a > packet/message i.e., ?silently discard?. In this case maybe we should > just say ?ignored?. yes, the intention is "ignored". I will correct the expression. > > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Type = TBD | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > + + > : Link Layer > address : > > + + > > +---------------------------------------------------------------+ > > Figure 6: BID Mobility Option > > > GT> Figure caption seems wrong. Also, has such option never been > defined for MIPv6 before? I see that PMIPv6 draft also defined the > same option. I would hope that only one such option is needed for all > flavors of MIPv6? Do you mean the interface identifier option of PMIP6? If that interface identifier is always LL address, we will reuse that option. Or we can overwrite the sub-option spec. to carry the LL address always for MCoA in this spec. I will discuss this with Sri. > $B!D(B > 5.6. Returning Home > > The mobile node may return to the home link, by attaching to the > home > link through one of its interfaces. When the mobile node wants to > return home, it should be configured with information on what > interface it needs to use. The mobile node may use only the > interface with which it is attached to the home link, only the > interfaces still attached to the visited link or use both interfaces > > GT> // visited link/ visited link(s) > > attached to the home link and visited link simultaneously. The > > GT> // visited link/ visited link(s) > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 19] > > Internet-Draft MCoA April > 2008 > > > following describes each option in more detail. > > 5.6.1. Using only Interface attached to the Home Link > > The mobile node returns home and de-registers all the bindings as > shown in Figure 2 and as defined in [RFC-3775]. De-registering all > the bindings is the same as binding de-registration from foreign > link > > GT> delete ?from foreign link? > > described in Section 5.5. After the de-registration step, all the > packets routed by the home agent are only forwarded to the interface > attached to the home link, even if there are other active interfaces > attached to the visited link. While the mobile node de-registers > all > > GT> // visited link/ visited link(s) > > the bindings from the home agent, it may continue registering > bindings for interface attached to visited link to the correspondent > > GT> //interface attached to visited link/ interface(s) attached to > visited link(s) > > node as shown in Figure 2. > > 5.6.2. Using only Interface attached to the Visited Link > > The mobile node returns home and shuts down the interface attached > to > the home link as shown in Figure 3. Before shutting down the > interface, any binding for the care-of address previously associated > with the interface should be deleted. To delete the binding cache > entry, the mobile node SHOULD send a de-registration Binding Update > with the lifetime set to zero and include the corresponding BID > information. If the mobile node does not send a de-registration > Binding Update, the binding for the care-of address previously > assigned to the interface remains at the home agent. > > GT> // at the home agent/ at the home agent until its lifetime expires > > This binding is > deleted only when it expires. In order to avoid this, the mobile > node SHOULD send a de-registration binding update for the interface > attached to the home link. > > GT> I think the above can be removed (the SHOULD is repeated above and > the rest is already explained). > > > This scenario is not the most efficient because all the traffic to > and from the mobile node is going through the bi-directional tunnel, > whereas the mobile node is now accessible at one hop on the home > link > from its home agent. > > GT> To avoid judgment calls maybe we can revise this to the following: > ? In this scenario, despite the face that the mobile node is > connected to its home link, all of its traffic is send and received > via the HA and its foreign links.? > > > > 5.6.3. Simultaneous Home and Visited Link Operation > > > [Problems of Simultaneous Home and Foreign Attachments] > > The mobile node returns home and continues using all the interfaces > attached to both foreign and home links as shown in Figure 4. The > mobile node indicates this by setting the 'H' flag in the BID > mobility option as defined below. There are additional requirements > on the Returning Home procedures for possible Neighbor Discovery > states conflicts at the home link. > > In [RFC-3775], the home agent intercepts packets meant for the > mobile > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 20] > > Internet-Draft MCoA April > 2008 > > > node using the Proxy Neighbor Discovery [RFC-2461] while the mobile > node is away from the home link. When the mobile node returns home, > the home agent deletes the binding cache and stops proxying for the > home address so that a mobile node can configure its home address on > the interface attached to the home link. In this specification, a > mobile node may return home, configure the home address on the > interface attached to the home link, but still use the interfaces > attached to the foreign links. In this case, a possible conflict > arises when the both the home agent and the mobile node try to > defend > the home address. If the home agent stops proxying for the home > address, the packets are always routed to the interface attached to > the home link and are never routed to the interfaces attached to the > visited links. It is required to avoid the conflict between the > home > agent and the mobile node, while still allowing the simultaneous use > of home and foreign links. The following describes the mechanism > for > achieving this. > > > [Overview and Approach] > > In this specification, the home agent MUST intercept all the packets > meant for the mobile node and decide whether to send the traffic > directly to the home address on the link or tunnel to the care-of > address. The home agent intercepts all the packets even when the > mobile node is attached to the home link through one of its > interfaces. The home agent would make this decision based on the > type of packets and flows. How to make this decision is out of > scope > in this document. > > Even when the mobile node returns home, how can home agent intercept > the packets meant for the mobile node at the home link on behalf of > the mobile node? > > GT> The question above can be removed. > > We introduce two possible scenarios, illustrated in > > GT> //We introduce two possible scenarios, illustrated / Two scenarios > are illustrated > > Figure 4, depending on whether the Home Agent is a single router at > the home link or not. The difference is who will defend the home > address by (Proxy) Neighbor Discovery on the home link. > > 1. Mobile node defends the home address by the regular Neighbor > Discovery Protocol (illustrated as topology-a in Figure 4). The > home agent is the single router to the Internet on the home > link. > Therefore the home agent is capable of intercepting packets > without relying on the proxy Neighbor Discovery protocol and the > mobile node can manage the Neighbor Cache entry of the home > address on the home link as a regular IPv6 node. > > 2. Home agent continue intercepting the mobile node's packets using > proxy Neighbor Discovery even after the mobile node's returning > home (illustrated as topology-b in Figure 4). The home agent > cannot intercept all the packets meant for the mobile node by IP > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 21] > > Internet-Draft MCoA April > 2008 > > > routing due to multiple routers on the home link. Due to the > possible competing neighbor cache state for the home address, > the > mobile node SHOULD NOT operate Neighbor Discovery protocol for > the home address on the home link. The problem arises when the > home agent perform the neighbor discovery to resolve the link- > layer address of the mobile node on the home link. Since the > mobile node never answers to the Neighbor Discovery packets for > the home address, the home agent would need to know the Link- > Layer address of the interface with which the mobile node is > attached to the home link in other way. > > > GT> I re-wrote the above to make it clearer: > "The home agent cannot naturally intercept all the packets meant for > the mobile node by IP routing due to multiple routers on the home > link. In this case, the mobile node MUST NOT operate Neighbor > Discovery protocol for the home address on the home link. This allows > the home agent to keep using proxy neighbor discovery and thus it > keeps receiving all the packets sent to the mobile node's home > address. If the home agent, according to its local policy, needs to > deliver packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's link > local address." > > > This specification > introduces a new Link-Layer Address mobility option carrying the > mobile node's link-layer address in the Binding Update. > Likewise, the mobile node would also know the link-layer address > of the default router address to send packets from the home link > without Neighbor Discovery. The link-layer address is used to > transmit packets from and to the mobile node on the home link. > The packets are transmitted without the Neighbor Discovery > protocol by constructing the link-layer header manually. This > operation is similar to Mobile IPv6 [RFC-3775] when a mobile > node > sends a deregistration binding update to the home agent's link- > layer address in returning home operation. > > > > > > > [Sending Deregistration Binding Update] > > > o As soon as a mobile node returns home, it sends a de-registration > Binding Update to the home agent from the interface attached to > the home link. > > GT> I think throughout the description of this mode of operation the > MN sends a *registration* not a *de-registration*. In fact you should > add somewhere that "A BU with H flag set MUST have a non-zero > Lifetime" I think MN can use the zero lifetime and de-register the BU. MN continues setting the H flag for BUs to other interfaces attached to foreign link, because MN attached to both foreign and home link. MN sends BU from the interface attached to the home link just once. After that BU, MN sends BU with H flag set from the other interfaces while it is at home link. MN should not send BU from the home link multiple times.. That's why we said dregistration BU here. What do you think? > > o The mobile node MUST include the BID mobility option specifying > the BID the mobile node had previously associated with the > interface attached to the home link. The 'H' flag MUST be set in > the BID mobility option. The 'C' flag MUST NOT be set and the > care-of address field MUST NOT be included. When the 'H' flag is > set, the home agent recognizes that the mobile node wants to > continue using interfaces attached to both home and visited > links. > Note that H flag MUST be set for all the binding updates sent > from > the mobile node (ex. Binding Update for the interface attached > to > the foreign link). > > GT>// for the interface attached to the foreign link)./ for the > interface(s) attached to foreign link(s)). > > > > o The mobile node SHOULD include the Link-Layer address mobility > option to notify the mobile node's link-layer address to the home > agent, too. This link-layer address is required for the home > agent to send the Binding Acknowledgement and to forward the > mobile node's packet. > > o According to [RFC-3775], the mobile node MUST start responding to > Neighbor Solicitation for its home address right after it sends > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 22] > > Internet-Draft MCoA April > 2008 > > > the deregistration Binding Update to the home agent. However, in > this specification, the mobile node MUST NOT respond to Neighbor > Solicitation before receiving a Binding Acknowledgement, since > the > home agent may continue proxying for the home address. > > GT> the MN must not respond to NS messages before and *after* > receiving the BA, right? This isn't such clear. If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after the BA. Otherwise, MN should answer to NS. > > [Sending Binding Acknowledgement] > > o When the home agent sends the Binding Acknowledgement after > succeeding the binding de-registration, it MUST set the status > value to either 0 [Binding Update Accepted] or to [MCOARETURNHOME > WO/NDP (TBD)] in the BID mobility option depending on home agent > configuration at the home link. The new values are: > > * Binding Update Accepted (0): NDP is permitted for the home > address at the home link. This is regular returning home > operation of [RFC-3775] > > * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > address at the home link > > If the binding update is rejected, the appropriate error value > MUST be set to the status field. In this case, the home agent > operation is same as [RFC-3775]. > > o If the home agent is the only router at the home link, it stops > proxy Neighbor Discover for the requested home address and > responds with the [Binding Update Accepted] status value to the > mobile node. Since the mobile node will not reply to Neighbor > Solicitation for the home address before receiving the Binding > Acknowledgement, the home agent SHOULD use the link-layer address > carried by the Link Layer Address mobility option in the received > Binding Update. After the completion of the binding > deregistration, the mobile node starts regular Neighbor Discovery > operations for the home address on the home link. The neighbor > cache entry for the home address is created by the regular > exchange of Neighbor Solicitation and Neighbor Advertisement. > > o On the other hand, if the home agent is not the only router on > the > home link, it returns [MCOA RETURNHOME WO/NDP] value in the > Status > field of the BID mobility option. The home agent learns the > mobile node's link-layer address by receiving the link-layer > address mobility option carried by the Binding Update. It stores > the link-layer address as a neighbor cache entry for the mobile > node so that it can send the packets to the mobile node's link- > layer address. > > > GT> It should be clarified that even if the HA is the only router on > the link, it might still make sense to continue Proxy-NDP as normal. > On shared links, this is probably the easiest way of intercepting > packets, as opposed to snooping. In any case, it is an implementation > choice. This is good point. We should leave the choice to implementations. I appreciate your detailed comments! regards, ryuji > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 23] > > Internet-Draft MCoA April > 2008 > > > o If BID option is missed in the Binding Acknowledgement, the home > agent might not recognize the simultaneous home and foreign > attachment. The home agent might process the de-registration > Binding Update as one of [RFC-3775] and deletes all the > registered > binding cache entries for the mobile node. Thus, the mobile node > SHOULD stop using the interface attached to foreign link and use > only the interface attached to the home link. > > > [Sending Packets from the Home Link] > > o When the mobile node receives the Binding Acknowledgement which > status value is [Binding Update Accepted] and BID option, it can > configure its home address to the interface attached to the home > link and start operating Neighbor Discovery for the home address > on the home link. Packets can be transmitted from and to the > mobile node as if the mobile node is a regular IPv6 node. > > o If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST > NOT operate Neighbor Discovery for the home address. When the > mobile node sends packets from the interface attached to the home > link, it MUST learn the link-layer address of the next hop (i.e. > default router of the mobile node). A mobile node learns the > default router's link-layer address from a Source Link-Layer > Address option in Router Advertisements. The mobile node sends > packets directly to the default router's link-layer address. > This > is done by constructing the packet including link-layer header > with the learned link-layer address of the default router. The > home agent also forwards the packet to the mobile node on the > home > link by using the mobile node's link-layer address. The link- > layer address SHOULD be cached when the home agent received the > deregistration Binding Update message. > > > [Leaving from the Home Link] > > o When the mobile node detaches from the home link, it SHOULD > immediately send a binding update for one of active care-of > address with H flag unset. When the 'H' flag of BID option is > unset in any Binding Update, the home agent stop forwarding the > mobile node's packet to the home link. > > o On the other hand, if the mobile node does not have any active > care-of address to send a Binding Update and leaves the home link > (i.e. the mobile node is completely disconnected), the home agent > continues forwarding packets to the mobile node until the > expiration of all the binding cache entries for the home address. > Once all the bindings are expired, the mobile node is assumed to > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 24] > > Internet-Draft MCoA April > 2008 > > > be disconnected completely from networks. > > > > [Changing Behavior during the attachment to the home link] > > When a mobile node would change the home operation to Section 5.6.1 > or Section 5.6.2, following procedure should be taken. > > GT> Remove the above sentence > > If a mobile node decides to return home completely without any > active > foreign link attachment, it simply sends a deregistration binding > update as described in Section 5.6.1. Once the home agent receives > such de-registration binding update, the home agent clears all the > binding and states for the mobile node. > > If a mobile node would stop using the interface attached to the home > > GT>// If a mobile node would/ If a mobile node decides to / > > link, it simply sends a binding update from the one of active care-of > address. In the Binding Update, the mobile node should include the > BID option for the care-of address and unset the H flag of BID > option. The home agent clears the states of the mobile node for the > interface attached to the home link and stop forwarding the packets > to the mobile node on the home link. > > > > > On Tue, Apr 15, 2008 at 3:55 PM, Ryuji Wakikawa > wrote: >> >> Hello all, >> >> I revised the draft according to the discussions >> at the last IETF meeting. >> I haven't submitted this to the IETF, please >> fetch the document from >> >> http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6- >> multiplecoa-07.txt >> >> The diff from the previous draft is also available at >> http://www.sfc.wide.ad.jp/~ryuji/mcoadiff.html >> >> Please take a look and provide your comments. >> >> thanks, >> ryuji >> >> >> >> >> >> _______________________________________________ >> 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 Apr 16 01:46:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE6A28C416; Wed, 16 Apr 2008 01:46: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 4CEB33A6EB4 for ; Wed, 16 Apr 2008 01:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=1.495, 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 wZcy7vbHWJ16 for ; Wed, 16 Apr 2008 01:46:42 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id ECAAA3A6E00 for ; Wed, 16 Apr 2008 01:46:41 -0700 (PDT) Received: from dummyhost11.it.uc3m.es (dummyhost15.it.uc3m.es [163.117.139.42])by smtp01.uc3m.es (Postfix) with ESMTP id 4ABB058597B; Wed, 16 Apr 2008 10:47:07 +0200 (CEST) Message-ID: <4805BD09.4020400@it.uc3m.es> Date: Wed, 16 Apr 2008 10:47:05 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Tony Whyman References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> <4804F070.5030104@mccallumwhyman.com> In-Reply-To: <4804F070.5030104@mccallumwhyman.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.8286 TC:1F TRN:62 TV:5.0.1023(15852.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 Subject: Re: [MEXT] changes in the CNs 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 see your point. However, it does sounds like a reasonable feature to = ask to be able to run whatever mechanism we define in proxy mode, = doesn't it? Tony Whyman escribi=F3: > Wesley, > > Thanks for clarifying that. > > The moto of the ATC Business is "if it ain't broke don't fix it" and I = > would expect any deployment of ATN-IP to respect this and follow the = > same roll out pattern as ATN-OSI - after all if it worked once... > > That model started with years of prototypes and trials, followed by a = > deployment programme that recruited a core set of pioneer airlines in = > Europe around a single ATC Centre, in order to help prove the system = > and give the vendors a chance to develop stable products. Only now has = > the full roll out programme begun, backed by a mandate that will apply = > to all aircraft flying above FL280. Start to finish was around 16 years. > > Expect the same to happen with an ATN-IP. There will be several years = > of trials and prototypes before some pioneer airlines start to use it. = > Only once the system is proven and demonstrated to be at least as safe = > as the current system, would full roll out begin. Hopefully the = > experience gained first time around would be used to speed the process = > up - but how much is another matter. > > During the trials and prototypes phase only a local PKI is required = > and expect it to be refined several times during the learning process. = > Even during the pioneer phase, only a local PKI would be required, but = > its implementation should anticipate the later roll out to first = > regional use and then global. > > So, you can see why I have a relaxed view about PKI deployment. > > Regards > > Tony > > > > Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >>> -----Original Message----- >>> From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] Sent: Tuesday, = >>> April 15, 2008 12:28 PM >>> >>> FWIW, i am just repeating what people have expressed in the meeting. >>> >>> below... >>> >>> Tony Whyman escribi=F3: >>> = >>>> Marcelo, >>>> >>>> Seems an odd assumption to me. The one thing that you can usually = >>>> assume in ATC is that there is a trust relationship between an = >>>> aircraft (MR) and the ATC Centre (CN). >>>> = >> >> >> I think the consensus was that in the long-term, what Tony says will >> be the case, but in the nearer-term (next several years), the PKI >> will not yet be deployed and it is unclear how long it will take to >> get it rolled out globally to all ANSPs and equipment. >> >> This is a parallel/supporting effort whose website and minutes may be >> of interest: >> https://www.jcg.aero/index.php >> Hugh Mote, who has been participating in MEXT meetings is active there. >> = > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 01:51:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4773A6F1F; Wed, 16 Apr 2008 01:51: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 6FFEA3A6F19 for ; Wed, 16 Apr 2008 01:51: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 gftuLd6ibYqh for ; Wed, 16 Apr 2008 01:51:40 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 613C53A6F23 for ; Wed, 16 Apr 2008 01:51:40 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m3G8qDEr022030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Apr 2008 09:52:13 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m3G8qCur016674 for ; Wed, 16 Apr 2008 09:52:13 +0100 Message-ID: <4805BE3D.4090702@mccallumwhyman.com> Date: Wed, 16 Apr 2008 09:52:13 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mext@ietf.org References: <4804B71D.3050102@it.uc3m.es> <4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> <4804F070.5030104@mccallumwhyman.com> In-Reply-To: <4804F070.5030104@mccallumwhyman.com> Subject: [MEXT] Global PKIs ( was Re: changes in the CNs) 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 Dear all, From some off list discussions that have taken place, I get the feeling that different people focus on different issues when the term "global PKI" is mentioned. There is thus a need to agree on the interpretation of the term "global PKI". Firstly, there is a clear need to separate out discussion on the technology used (certificate formats, digital signature algorithms, etc.) from the process of issuing certificates (politics). In my paper and posts, I have assumed an evolutionary approach to both, with a single global PKI being the logical outcome of this process. On the other hand, I have no problem in conceding that the move from regional to a single global PKI may have political issues associated with it, in the sense that one CA may have problems recognising the validity and integrity of the process performed by another CA. It may thus be a very long evolutionary process. My proposal is thus that the requirement for an aviation global PKI is interpreted as a need for a core common PKI technology supporting a number of regional PKIs, with a long term objective of evolving into a single global PKI. My assumption here is that the main problem in establishing a regional PKI is technology, while joining the regions together to form a single global PKI is a political problem. A region is thus self-defining. The practical implication is that an aircraft will need a certificate for each region in which it operates and will need to be able to validate certificates presented to it issued by the CAs responsible for those regions. Implementations will have to be able to work with multiple certificates and CAs. Only when CAs start issuing cross-certificates for each other, will the number of certificates that an aircraft needs, be reduced. The issuing of the cross-certificate is where the political issue arises as will only be done when a given regional CA is fully satisfied as to the validity and integrity of the process performed by another regional CA. Regards Tony Whyman _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:00:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E20628C452; Wed, 16 Apr 2008 02:00: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 EE1B728C247 for ; Wed, 16 Apr 2008 02:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.531, 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 i9E7zuc+zWp2 for ; Wed, 16 Apr 2008 02:00:39 -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 4091D28C45B for ; Wed, 16 Apr 2008 02:00:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2431573wfa.31 for ; Wed, 16 Apr 2008 02:00:39 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kmGMp0qnS0CGxtqlFHK5nBKmoDBjCdlNOpmUe7Oej/8=; b=jgtcxGl6oMtea50754Fse9zQ/ZseUOunhT0MpATryUUsZwEdK/YHpl7fClIz5NUux4h/IGVHdBphaNNIdQmysDkHXmGOs1O1gY3B+pqq9oPsC+02jl1rbYa3U6fn0313Ix+p0LI+6jO0aakYiqbxRN8XGmxUa/m5lqgwBYo1ULI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=WIvW7qhAsBpx8t8Fv95ac3hJz3s3Sevn/aBB5bO6uHAJ1gf42PENm7AHUqK9MzrYoc17NZO5icbE7Rh3Vu5ZDxNzxOfc1x+MdF4dIkHcFACowcfQQhtenXy6sub0hmvQwKNu7aIhQwxIAkTyVB/nD9VRQlbYXNoiWKS9z+t/+4A= Received: by 10.142.78.10 with SMTP id a10mr2612652wfb.37.1208336439484; Wed, 16 Apr 2008 02:00:39 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Wed, 16 Apr 2008 02:00:39 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2008 10:00:39 +0100 From: "George Tsirtsis" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: Ryuji Wakikawa , mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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, Yes, most of my comments are now minor so, good job!. The only issue that bothers me a little is whether the BU with H flag set over the home link should be viewed as registration or de-registration. I think either way works, but I need to think this through just in case there is some implication that we do not see at the moment. See some comments inline. Regards George 2008/4/16 Ryuji Wakikawa : > Hello George, > > Thanks for comments! > > It looks like your comments are more editorial one. > Can I assume you mostly agree on the changes? > I will revise the document quickly and post it again to MEXT. > > > > On 2008/04/15, at 21:29, George Tsirtsis wrote: .. > > > > > > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = TBD | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + + > > : Link Layer address : > > + + > > +---------------------------------------------------------------+ > > > > Figure 6: BID Mobility Option > > > > > > GT> Figure caption seems wrong. Also, has such option never been > > defined for MIPv6 before? I see that PMIPv6 draft also defined the > > same option. I would hope that only one such option is needed for all > > flavors of MIPv6? > > > > Do you mean the interface identifier option of PMIP6? > If that interface identifier is always LL address, we will reuse that > option. > Or we can overwrite the sub-option spec. to carry the LL address always for > MCoA in this spec. > I will discuss this with Sri. > > GT2> Yes, I think it would be nice to coordinate with Sri, but I am not sure what you mean by "we can overwrite the sub-option spec...." > > > > > > > > > > > > [Sending Deregistration Binding Update] > > > > > > o As soon as a mobile node returns home, it sends a de-registration > > Binding Update to the home agent from the interface attached to > > the home link. > > > > GT> I think throughout the description of this mode of operation the > > MN sends a *registration* not a *de-registration*. In fact you should > > add somewhere that "A BU with H flag set MUST have a non-zero > > Lifetime" > > > > I think MN can use the zero lifetime and de-register the BU. > MN continues setting the H flag for BUs to other interfaces attached to > foreign link, > because MN attached to both foreign and home link. > > MN sends BU from the interface attached to the home link just once. > After that BU, MN sends BU with H flag set from the other interfaces while > it is at home link. > > MN should not send BU from the home link multiple times.. > That's why we said dregistration BU here. > > What do you think? > GT2> Hmmm, I guess that could work too. Let's think about this a minute. The way you are thinking about this, can the MN send a BU over a foreign link with the H flag set, without having send the dereg BU with H flag set first? > > > > > o The mobile node MUST include the BID mobility option specifying > > the BID the mobile node had previously associated with the > > interface attached to the home link. The 'H' flag MUST be set in > > the BID mobility option. The 'C' flag MUST NOT be set and the > > care-of address field MUST NOT be included. When the 'H' flag is > > set, the home agent recognizes that the mobile node wants to > > continue using interfaces attached to both home and visited links. > > Note that H flag MUST be set for all the binding updates sent from > > the mobile node (ex. Binding Update for the interface attached to > > the foreign link). > > > > GT>// for the interface attached to the foreign link)./ for the > > interface(s) attached to foreign link(s)). > > > > > > > > o The mobile node SHOULD include the Link-Layer address mobility > > option to notify the mobile node's link-layer address to the home > > agent, too. This link-layer address is required for the home > > agent to send the Binding Acknowledgement and to forward the > > mobile node's packet. > > > > o According to [RFC-3775], the mobile node MUST start responding to > > Neighbor Solicitation for its home address right after it sends > > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page 22] > > > > Internet-Draft MCoA April 2008 > > > > > > the deregistration Binding Update to the home agent. However, in > > this specification, the mobile node MUST NOT respond to Neighbor > > Solicitation before receiving a Binding Acknowledgement, since the > > home agent may continue proxying for the home address. > > > > GT> the MN must not respond to NS messages before and *after* > > receiving the BA, right? > > > > This isn't such clear. > If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after the > BA. > Otherwise, MN should answer to NS. > > GT2> OK, some clarification maybe useful to indicate that what happens after the BA depends on how the HA responds i.e., the BA's status field. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:06:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583CE28C44D; Wed, 16 Apr 2008 02:06: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 D753C3A6E9E for ; Wed, 16 Apr 2008 02:06: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 T4XNd1cOUaRR for ; Wed, 16 Apr 2008 02:06:00 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 0C1153A6908 for ; Wed, 16 Apr 2008 02:05:35 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so1372723and.122 for ; Wed, 16 Apr 2008 02:06:10 -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=D/v8n9Pkj9es+O2wFZUS7QBUjlqkzTWmd9/uPmOSV+I=; b=Cz08lSPcPR2XciV6hUtBjqKaBxNFZP/G6tXsyxm0emfqXWJRxJ7xrD2GlnQ/2ppp6BTI702fzMIgHJz0w2pAryMeb0Er9UhmVnVzxcDvU8/y6HhLMyQo4oDMySE/Tx8LUh1yJIbQ+tIPheulwRUaB4wlUh12p1HmB+XWK77WIAo= 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=ChqqHICaW+tOusSYl9rZot8ljvQM52G025KmW6a3gqEHOdWaJXeK0eke365IWYn9bud0iToPcXYDZybNhGqAYVVobKrapkAhIchgHaSc24cowF30c6W9LqHYPfbUL0NC1DkX/kGe1mo5NAavHAhb+I1GwudQVnj2pDdKyOVnPng= Received: by 10.100.247.14 with SMTP id u14mr7885865anh.155.1208336764835; Wed, 16 Apr 2008 02:06:04 -0700 (PDT) Received: from ?58.98.38.35? ( [58.98.38.35]) by mx.google.com with ESMTPS id 32sm19158912wri.0.2008.04.16.02.06.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Apr 2008 02:06:03 -0700 (PDT) From: Ryuji Wakikawa To: "George Tsirtsis" In-Reply-To: References: Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 18:05:56 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 George, On 2008/04/16, at 18:00, George Tsirtsis wrote: > Hi Ryuji, > > Yes, most of my comments are now minor so, good job!. Great! thanks. > The only issue that bothers me a little is whether the BU with H flag > set over the home link should be viewed as registration or > de-registration. I think either way works, but I need to think this > through just in case there is some implication that we do not see at > the moment. OK, please find my comments inline. > See some comments inline. > > Regards > George > > 2008/4/16 Ryuji Wakikawa : >> Hello George, >> >> Thanks for comments! >> >> It looks like your comments are more editorial one. >> Can I assume you mostly agree on the changes? >> I will revise the document quickly and post it again to MEXT. >> >> >> >> On 2008/04/15, at 21:29, George Tsirtsis wrote: > .. >> >>> >>> >>> >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type = TBD | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> + + >>> : Link Layer >>> address : >>> >>> + + >>> >>> +---------------------------------------------------------------+ >>> >>> Figure 6: BID Mobility Option >>> >>> >>> GT> Figure caption seems wrong. Also, has such option never been >>> defined for MIPv6 before? I see that PMIPv6 draft also defined the >>> same option. I would hope that only one such option is needed for >>> all >>> flavors of MIPv6? >>> >> >> Do you mean the interface identifier option of PMIP6? >> If that interface identifier is always LL address, we will reuse that >> option. >> Or we can overwrite the sub-option spec. to carry the LL address >> always for >> MCoA in this spec. >> I will discuss this with Sri. >> >> > > GT2> Yes, I think it would be nice to coordinate with Sri, but I am > not sure what you mean by "we can overwrite the sub-option spec...." I mean the MCoA spec clearly states to carry only LL address in this option. >>> >>> >>> [Sending Deregistration Binding Update] >>> >>> >>> o As soon as a mobile node returns home, it sends a de-registration >>> Binding Update to the home agent from the interface attached to >>> the home link. >>> >>> GT> I think throughout the description of this mode of operation the >>> MN sends a *registration* not a *de-registration*. In fact you >>> should >>> add somewhere that "A BU with H flag set MUST have a non-zero >>> Lifetime" >>> >> >> I think MN can use the zero lifetime and de-register the BU. >> MN continues setting the H flag for BUs to other interfaces >> attached to >> foreign link, >> because MN attached to both foreign and home link. >> >> MN sends BU from the interface attached to the home link just once. >> After that BU, MN sends BU with H flag set from the other >> interfaces while >> it is at home link. >> >> MN should not send BU from the home link multiple times.. >> That's why we said dregistration BU here. >> >> What do you think? >> > > GT2> Hmmm, I guess that could work too. Let's think about this a > minute. The way you are thinking about this, can the MN send a BU over > a foreign link with the H flag set, without having send the dereg BU > with H flag set first? MN sends only one dereg-BU with H flag set and zero lifetime to HA from the home link. After that deregistration, MN sends BU with H flag set from the foreign link to HA. This tells HA that MN is still at the home link. Once MN leaves from the home link, MN unset the H flag in BU so that HA can detect the MN's leaving. >>> o According to [RFC-3775], the mobile node MUST start responding to >>> Neighbor Solicitation for its home address right after it sends >>> >>> >>> >>> Wakikawa (Editor), et al. Expires October 17, 2008 >>> [Page 22] >>> >>> Internet-Draft MCoA >>> April 2008 >>> >>> >>> the deregistration Binding Update to the home agent. However, in >>> this specification, the mobile node MUST NOT respond to Neighbor >>> Solicitation before receiving a Binding Acknowledgement, since >>> the >>> home agent may continue proxying for the home address. >>> >>> GT> the MN must not respond to NS messages before and *after* >>> receiving the BA, right? >>> >> >> This isn't such clear. >> If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS >> after the >> BA. >> Otherwise, MN should answer to NS. >> >> > > GT2> OK, some clarification maybe useful to indicate that what happens > after the BA depends on how the HA responds i.e., the BA's status > field. Right. I will update this. regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:19:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CBE28C45F; Wed, 16 Apr 2008 02:19: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 8DCDB28C471 for ; Wed, 16 Apr 2008 02:19:08 -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=[AWL=-0.000, 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 VNRZOUhmpgn7 for ; Wed, 16 Apr 2008 02:19:07 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 3E1EA28C45F for ; Wed, 16 Apr 2008 02:19:07 -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-maile12) with ESMTP id m3G9JdMj021785; Wed, 16 Apr 2008 18:19:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m3G9JeG21297; Wed, 16 Apr 2008 18:19:40 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m3G9JaP22380; Wed, 16 Apr 2008 18:19:36 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 17:19:03 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 16 Apr 2008 17:18:59 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 16 Apr 2008 17:18:59 +0800 From: "Benjamin Lim" To: "'George Tsirtsis'" References: Date: Wed, 16 Apr 2008 17:18:59 +0800 Message-ID: <005701c89fa2$e7848840$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcifoMsq/yx563ZYQhivyek9ki8WPgAADqQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 16 Apr 2008 09:19:03.0091 (UTC) FILETIME=[E97DC030:01C89FA2] Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 George, Permit me to join in ;p =8==8<=8== > > I think MN can use the zero lifetime and de-register the BU. > > MN continues setting the H flag for BUs to other > interfaces attached > > to foreign link, because MN attached to both foreign and home link. > > > > MN sends BU from the interface attached to the home link just once. > > After that BU, MN sends BU with H flag set from the other > interfaces > > while it is at home link. > > > > MN should not send BU from the home link multiple times.. > > That's why we said dregistration BU here. > > > > What do you think? > > > > GT2> Hmmm, I guess that could work too. Let's think about this a > minute. The way you are thinking about this, can the MN send > a BU over a foreign link with the H flag set, without having > send the dereg BU with H flag set first? [Ben] My view is that the 'H' flag allows MN to tell HA that its wants to use both home and foreign attach interface. Hence, sending it on reg-BU over foreign link or de-reg BU over home link should be ok. From the BU over foregin link case, as the 'H' flag is in the BID option, HA can look for the corresponding entry in BCE (that matches the BID) and mark it as a special entry to let it know that MN is also connected to the home link. Why I say special entry is because the BID could be reuse by the MN for flow filtering purposes (I think this was where we last stop the discussion ;p) Regards, Benjamin Lim. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:19:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8FE28C483; Wed, 16 Apr 2008 02:19: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 5EC1528C465 for ; Wed, 16 Apr 2008 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=0.513, 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 eygEKLA9RxN7 for ; Wed, 16 Apr 2008 02:19:23 -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 415FF28C2B3 for ; Wed, 16 Apr 2008 02:19:23 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2437809wfa.31 for ; Wed, 16 Apr 2008 02:19:56 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pvnJwiLonWjeUk0L2sPtDcGMV4s9TNRFadUDEaJ0grI=; b=KAQuxcQxgVSIy2cF6UOVMJPvle7Fz0Ys/w6lBGNWTAKPAxF/0acb6Je5/iwjoeuWvQw0SOaSUqHTx9Jp9nP/jn1TDBWBvwm0zZabos7nWQj3KqCK75MCwtl+6jxt/TGzPrnH6tL7TICokr8bdMXuioPQAWxO2Ir1sM4xShp3vrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=pfy0w/+ehequss2NEbxzP5bGapf0iNesfKfWOSO6uzwTh4TpM2Kc9S/nljZiH+qwLguaP80D65NV/ct92AMapQRlCtBLPojusqFnURTFqpNAmtq09XLKu+SaQ5018l8lP2UpPUL98K3LVaTJVqF+adq4FxViXZ1CkdTA1M/7y2w= Received: by 10.142.142.16 with SMTP id p16mr2609618wfd.123.1208337596501; Wed, 16 Apr 2008 02:19:56 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Wed, 16 Apr 2008 02:19:56 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2008 10:19:56 +0100 From: "George Tsirtsis" To: "Ryuji Wakikawa" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 think what you propose wrt de-registration BU with H-flag set, works. I have a slight preference in viewing this as a registration but my preference is based on semantics and I do not think it technically impacts the solution. For this reason I say that we go with your proposal, so after fixing the final set of minor comments I think you should publish the draft. Time for a proper WGLC ...at least from my side :-) Regards George On Wed, Apr 16, 2008 at 10:05 AM, Ryuji Wakikawa wrote: > Hi George, > > > On 2008/04/16, at 18:00, George Tsirtsis wrote: > > > Hi Ryuji, > > > > Yes, most of my comments are now minor so, good job!. > > > > Great! thanks. > > > > > The only issue that bothers me a little is whether the BU with H flag > > set over the home link should be viewed as registration or > > de-registration. I think either way works, but I need to think this > > through just in case there is some implication that we do not see at > > the moment. > > > > OK, please find my comments inline. > > > > > > See some comments inline. > > > > Regards > > George > > > > 2008/4/16 Ryuji Wakikawa : > > > > > Hello George, > > > > > > Thanks for comments! > > > > > > It looks like your comments are more editorial one. > > > Can I assume you mostly agree on the changes? > > > I will revise the document quickly and post it again to MEXT. > > > > > > > > > > > > On 2008/04/15, at 21:29, George Tsirtsis wrote: > > > > > .. > > > > > > > > > > > > > > > > > > > > > > > > 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Type = TBD | Length | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > + + > > > > : Link Layer address : > > > > + + > > > > +---------------------------------------------------------------+ > > > > > > > > Figure 6: BID Mobility Option > > > > > > > > > > > > GT> Figure caption seems wrong. Also, has such option never been > > > > defined for MIPv6 before? I see that PMIPv6 draft also defined the > > > > same option. I would hope that only one such option is needed for all > > > > flavors of MIPv6? > > > > > > > > > > > > > > Do you mean the interface identifier option of PMIP6? > > > If that interface identifier is always LL address, we will reuse that > > > option. > > > Or we can overwrite the sub-option spec. to carry the LL address always > for > > > MCoA in this spec. > > > I will discuss this with Sri. > > > > > > > > > > > > > GT2> Yes, I think it would be nice to coordinate with Sri, but I am > > not sure what you mean by "we can overwrite the sub-option spec...." > > > > I mean the MCoA spec clearly states to carry only LL address in this > option. > > > > > > > > > > > > > > > > > > > > [Sending Deregistration Binding Update] > > > > > > > > > > > > o As soon as a mobile node returns home, it sends a de-registration > > > > Binding Update to the home agent from the interface attached to > > > > the home link. > > > > > > > > GT> I think throughout the description of this mode of operation the > > > > MN sends a *registration* not a *de-registration*. In fact you should > > > > add somewhere that "A BU with H flag set MUST have a non-zero > > > > Lifetime" > > > > > > > > > > > > > > I think MN can use the zero lifetime and de-register the BU. > > > MN continues setting the H flag for BUs to other interfaces attached to > > > foreign link, > > > because MN attached to both foreign and home link. > > > > > > MN sends BU from the interface attached to the home link just once. > > > After that BU, MN sends BU with H flag set from the other interfaces > while > > > it is at home link. > > > > > > MN should not send BU from the home link multiple times.. > > > That's why we said dregistration BU here. > > > > > > What do you think? > > > > > > > > > > GT2> Hmmm, I guess that could work too. Let's think about this a > > minute. The way you are thinking about this, can the MN send a BU over > > a foreign link with the H flag set, without having send the dereg BU > > with H flag set first? > > > > MN sends only one dereg-BU with H flag set and zero lifetime to HA from the > home link. > > After that deregistration, MN sends BU with H flag set from the foreign > link to HA. > This tells HA that MN is still at the home link. > Once MN leaves from the home link, MN unset the H flag in BU so that HA can > detect the MN's leaving. > > > > > > > > > > > > o According to [RFC-3775], the mobile node MUST start responding to > > > > Neighbor Solicitation for its home address right after it sends > > > > > > > > > > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > 22] > > > > > > > > Internet-Draft MCoA April > 2008 > > > > > > > > > > > > the deregistration Binding Update to the home agent. However, in > > > > this specification, the mobile node MUST NOT respond to Neighbor > > > > Solicitation before receiving a Binding Acknowledgement, since the > > > > home agent may continue proxying for the home address. > > > > > > > > GT> the MN must not respond to NS messages before and *after* > > > > receiving the BA, right? > > > > > > > > > > > > > > This isn't such clear. > > > If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after > the > > > BA. > > > Otherwise, MN should answer to NS. > > > > > > > > > > > > > GT2> OK, some clarification maybe useful to indicate that what happens > > after the BA depends on how the HA responds i.e., the BA's status > > field. > > > > > Right. I will update this. > > regards, > ryuji > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:27:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987CB28C211; Wed, 16 Apr 2008 02:27: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 0A9BA3A6C0D for ; Wed, 16 Apr 2008 02:27:52 -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 i5fZ1tQiTuHX for ; Wed, 16 Apr 2008 02:27:51 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id A54053A6F1F for ; Wed, 16 Apr 2008 02:27:50 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m3G9SN9R030291; Wed, 16 Apr 2008 11:28:23 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m3G9SNN4032679; Wed, 16 Apr 2008 11:28:23 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 11:28:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 11:28:20 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803B81E32@zagh223a.ww300.siemens.net> In-Reply-To: <4805B72D.8000603@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: Acifmv1k7T+EaihBRYuVZexUl8DDOAABJbYA References: <22124704.234881208312532747.JavaMail.weblogic@epml14> <4805B72D.8000603@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" , X-OriginalArrivalTime: 16 Apr 2008 09:28:22.0504 (UTC) FILETIME=[36ED6680:01C89FA4] 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::080416112823-265BFBB0-19596EEF/0-0/0-15 X-purgate-size: 4837/0 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, > The IPv6 network prefix is there presumably because we want > to enable the use of the HA anycast address. There is nothing > corresponding in IPv4, so we don't need a prefix. And this > draft does not give us IPv6 home addresses, so there is no > need for IPv4 home addresses either. In deployments where the per-MN prefix model is used, letting the MN know the home prefix is equal to assigning the address to the MN. I'm not clear if DHAAD works with per-MN prefix model. I thought that the main purpose of the home network prefix is the same as the MIP6_HOME_PREFIX attribute from RFC 5026. For DHAAD, the better way might be to include prefix length in the Home agent address option, and if the bits after the prefix length are zero, the MN should run DHAAD. In this way the MN could be told to run DHAAD with one prefix and use another prefix for its home address configuration. domagoj > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 16. travanj 2008 10:22 > To: heejin.jang@samsung.com > Cc: Premec, Domagoj; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Heejin, > > >> This is actually a problem in -13 (I reviewed it myself > after sending > >> out the mail this morning). > >> > >> I think we need to be able to indicate (a) FQDNs, (b) IPv6 > addresses, > >> or > >> (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to > >> either > >> IPv4 or IPv6 addresses or both... no flags needed. > >> > > > > Ok. for FQDN sub-opt-code, I'll fallback to the previous > version. (v12). > > > > > >> And I think this draft should only focus on Mobile IPv6. > We get the > >> Mobile IPv6 home agent's addresses (be it v4 or v6), not something > >> else... > >> > > > > " focus on Mobile IPv6..not something else..." means there > is no need > > to add what Premec suggested, that is IPv4 HoA, IPv4 subnet? > > > > The IPv6 network prefix is there presumably because we want > to enable the use of the HA anycast address. There is nothing > corresponding in IPv4, so we don't need a prefix. And this > draft does not give us IPv6 home addresses, so there is no > need for IPv4 home addresses either. > > > For clarity, then I'll revise as below. (Your previous mail > was also > > considered.) > > > > OLD: > > Sub-opt-code > > > > 0 Reserved > > 1 Home network identifier (only admitted > > in a Home Network Information option) > > 2 IPv6 home network prefix > > 3 IPv6 home agent address > > 4 IPv4 address of the dual-stacked home agent > > 5 Home agent FQDN > > 6 .. (2^16-1) Reserved > > NEW: > > 0 Reserved > > 1 Home network identifier (only admitted > > in a Home Network Information option) > > 2 IPv6 home network prefix > > 3 IPv6 home agent address > > 4 Home agent FQDN > > 5 .. (2^16-1) Reserved > > > > No, this is wrong. You *do* need to have IPv4 address of the > Mobile IPv6 home agent as well. Don't change this part, just > change the parts where you talked about Mobile IPv4... these > options will give you access to the Mobile IPv6 service, be > it over IPv4, IPv6 or whatever. But these options do not give > you access to Mobile IPv4 service. > > > /* Node that the below is for IPv6 address sub-opt-code, > not for FQDN > > sub-opt-code*/ > > > > When the Sub-opt-code is set to 3, the Home Network Parameter field > > MUST consist of a Flags octet followed by the 128-bit IPv6 > address of > > the home agent. The most significant bit of the Flags > octet encodes a > > DSMIP field, and the seven remaining bits are Reserved > (must be set to > > 0 and ignored on receipt). A Value of 1 in the DSMIP field > indicates > > that the home agent specified by the following IPv6 address has an > > IPv4 address and has a capability to support DSMIPv6 [DSMIPv6]. A > > value of 0 means that the home agent only supports Mobile IPv6. > > > > I don't see a need for this. You will deliver one or several > of: IPv4 address, IPv6 address, IPv6 prefix, FQDN. Depending > on what you get and how the FQDN is resolved, you will either > have or not have IPv4 addresses in your final set. If you do, > that means that server should be contactable by IPv4 using > DSMIP. No flag needed. > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:49:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4242028C417; Wed, 16 Apr 2008 02:49: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 A4B4128C446 for ; Wed, 16 Apr 2008 02:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 h-2y+cBSNi-P for ; Wed, 16 Apr 2008 02:49:09 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 62C4F28C46E for ; Wed, 16 Apr 2008 02:49:09 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D2AD0198805; Wed, 16 Apr 2008 12:49:43 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 8668219871D; Wed, 16 Apr 2008 12:49:43 +0300 (EEST) Message-ID: <4805CBB8.9050705@piuha.net> Date: Wed, 16 Apr 2008 12:49:44 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: "Premec, Domagoj" References: <22124704.234881208312532747.JavaMail.weblogic@epml14> <4805B72D.8000603@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B81E32@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6803B81E32@zagh223a.ww300.siemens.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 > In deployments where the per-MN prefix model is used, letting the MN know the home prefix is equal to assigning the address to the MN. I'm not clear if DHAAD works with per-MN prefix model. I thought that the main purpose of the home network prefix is the same as the MIP6_HOME_PREFIX attribute from RFC 5026. For DHAAD, the better way might be to include prefix length in the Home agent address option, and if the bits after the prefix length are zero, the MN should run DHAAD. In this way the MN could be told to run DHAAD with one prefix and use another prefix for its home address configuration. > Clearly we had different ideas about the use of the prefix in hiopt. But I think it is intended for the use of DHAAD. See paragraph 1 in Section 1. I don't think this draft should be extended to deal with the home address configuration (be it per-mn prefix or individual addresses). Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:54:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194F128C4A2; Wed, 16 Apr 2008 02:54: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 413A728C491 for ; Wed, 16 Apr 2008 02:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN54RBXlI9Za for ; Wed, 16 Apr 2008 02:54:44 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 0DBFD28C46E for ; Wed, 16 Apr 2008 02:54:44 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE00E6UWM9ZY@mailout2.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 18:49:21 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE006DAWM9BY@ms5.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 18:49:21 +0900 (KST) Content-return: prohibited Date: Wed, 16 Apr 2008 09:49:21 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <30785671.253551208339361346.JavaMail.weblogic@epml10> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080416094323713@heejin.jang X-MTR: 20080416094323713@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, April 16, 2008 5:22 PM > To: heejin.jang@samsung.com > Cc: Premec, Domagoj; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Heejin, > > >> This is actually a problem in -13 (I reviewed it myself > after sending > >> out the mail this morning). > >> > >> I think we need to be able to indicate (a) FQDNs, (b) IPv6 > addresses, > >> or > >> (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to > >> either > >> IPv4 or IPv6 addresses or both... no flags needed. > >> > > > > Ok. for FQDN sub-opt-code, I'll fallback to the previous > version. (v12). > > > > > >> And I think this draft should only focus on Mobile IPv6. > We get the > >> Mobile IPv6 home agent's addresses (be it v4 or v6), not something > >> else... > >> > > > > " focus on Mobile IPv6..not something else..." means there > is no need > > to add what Premec suggested, that is IPv4 HoA, IPv4 subnet? > > > > The IPv6 network prefix is there presumably because we want > to enable the use of the HA anycast address. There is nothing > corresponding in IPv4, so we don't need a prefix. And this > draft does not give us IPv6 home addresses, so there is no > need for IPv4 home addresses either. As far as I know, there is a dynamic discovery in MIPv4, too. Section 3.6.1.2. of draft-ietf-mip4-rfc3344bis-06.txt described about that procedures (page 47, last paragraph). But these new options do not aim at allowing access to MIPv4 as you told, IPv4 HoA and IPv4 subnet won't be included in a new version. > > > For clarity, then I'll revise as below. (Your previous mail > was also > > considered.) > > > > OLD: > > Sub-opt-code > > > > 0 Reserved > > 1 Home network identifier (only admitted > > in a Home Network Information option) > > 2 IPv6 home network prefix > > 3 IPv6 home agent address > > 4 IPv4 address of the dual-stacked home agent > > 5 Home agent FQDN > > 6 .. (2^16-1) Reserved > > NEW: > > 0 Reserved > > 1 Home network identifier (only admitted > > in a Home Network Information option) > > 2 IPv6 home network prefix > > 3 IPv6 home agent address > > 4 Home agent FQDN > > 5 .. (2^16-1) Reserved > > > > No, this is wrong. You *do* need to have IPv4 address of the > Mobile IPv6 home agent as well. Don't change this part, just > change the parts where you talked about Mobile IPv4... these > options will give you access to the Mobile IPv6 service, be > it over IPv4, IPv6 or whatever. But these options do not give > you access to Mobile IPv4 service. I see. Ok. > > /* Node that the below is for IPv6 address sub-opt-code, > not for FQDN > > sub-opt-code*/ > > > > When the Sub-opt-code is set to 3, the Home Network Parameter field > > MUST consist of a Flags octet followed by the 128-bit IPv6 > address of > > the home agent. The most significant bit of the Flags > octet encodes a > > DSMIP field, and the seven remaining bits are Reserved > (must be set to > > 0 and ignored on receipt). A Value of 1 in the DSMIP field > indicates > > that the home agent specified by the following IPv6 address has an > > IPv4 address and has a capability to support DSMIPv6 [DSMIPv6]. A > > value of 0 means that the home agent only supports Mobile IPv6. > > > > I don't see a need for this. You will deliver one or several > of: IPv4 address, IPv6 address, IPv6 prefix, FQDN. Depending > on what you get and how the FQDN is resolved, you will either > have or not have IPv4 addresses in your final set. If you do, > that means that server should be contactable by IPv4 using > DSMIP. No flag needed. Ok. I'll keep using the previous one. Thanks again. :) - Best regards, Heejin > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 02:59:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5FB28C14E; Wed, 16 Apr 2008 02:59: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 676603A6C8E for ; Wed, 16 Apr 2008 02:59:55 -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 tonO+H-tGN7L for ; Wed, 16 Apr 2008 02:59:51 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 4EDC03A6C68 for ; Wed, 16 Apr 2008 02:59:51 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m3GA0OU0001970; Wed, 16 Apr 2008 12:00:24 +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 m3GA0OoL016483; Wed, 16 Apr 2008 12:00:24 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 12:00:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 12:00:22 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803B81EE3@zagh223a.ww300.siemens.net> In-Reply-To: <4805CBB8.9050705@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: AcifpzR2jTIV7aMtTcOMGYf5thS+JAAAM44w References: <22124704.234881208312532747.JavaMail.weblogic@epml14> <4805B72D.8000603@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803B81E32@zagh223a.ww300.siemens.net> <4805CBB8.9050705@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" X-OriginalArrivalTime: 16 Apr 2008 10:00:24.0254 (UTC) FILETIME=[B0612DE0:01C89FA8] 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::080416120024-0BAC3BA0-419B8566/0-0/0-15 X-purgate-size: 1689/999999 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 see. I guess I was mislead by the definition of Home network prefix option, which explicitely mentions addresses configuration: >Valid Lifetime > > 32-bit unsigned integer. > The length of time in seconds > (relative to the time the packet is sent) that addresses > generated from the prefix via stateless address > auto-configuration remain in the valid state [RFC4862]. domagoj > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 16. travanj 2008 11:50 > To: Premec, Domagoj > Cc: heejin.jang@samsung.com; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > > > In deployments where the per-MN prefix model is used, > letting the MN know the home prefix is equal to assigning the > address to the MN. I'm not clear if DHAAD works with per-MN > prefix model. I thought that the main purpose of the home > network prefix is the same as the MIP6_HOME_PREFIX attribute > from RFC 5026. For DHAAD, the better way might be to include > prefix length in the Home agent address option, and if the > bits after the prefix length are zero, the MN should run > DHAAD. In this way the MN could be told to run DHAAD with one > prefix and use another prefix for its home address configuration. > > > > Clearly we had different ideas about the use of the prefix in > hiopt. But I think it is intended for the use of DHAAD. See > paragraph 1 in Section 1. > > I don't think this draft should be extended to deal with the > home address configuration (be it per-mn prefix or individual > addresses). > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 03:03:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6C628C14E; Wed, 16 Apr 2008 03:03: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 290B23A6EF1 for ; Wed, 16 Apr 2008 03:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69s-Kn5BoIiP for ; Wed, 16 Apr 2008 03:03:48 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 87F173A6AAA for ; Wed, 16 Apr 2008 03:03:48 -0700 (PDT) Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE004VXXBAND@mailout1.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 19:04:22 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE007W1XBAM0@ms5.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 19:04:22 +0900 (KST) Content-return: prohibited Date: Wed, 16 Apr 2008 10:04:22 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <22258564.254131208340262485.JavaMail.weblogic@epml10> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080416100321651@heejin.jang X-MTR: 20080416100321651@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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 See below. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, April 16, 2008 6:50 PM > To: Premec, Domagoj > Cc: heejin.jang@samsung.com; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > > > In deployments where the per-MN prefix model is used, > letting the MN know the home prefix is equal to assigning the > address to the MN. I'm not clear if DHAAD works with per-MN > prefix model. I thought that the main purpose of the home > network prefix is the same as the MIP6_HOME_PREFIX attribute > from RFC 5026. For DHAAD, the better way might be to include > prefix length in the Home agent address option, and if the > bits after the prefix length are zero, the MN should run > DHAAD. In this way the MN could be told to run DHAAD with one > prefix and use another prefix for its home address configuration. > > > > Clearly we had different ideas about the use of the prefix in > hiopt. But I think it is intended for the use of DHAAD. See > paragraph 1 in Section 1. As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 carries home network prefix together with valid & preferred lifetimes. This means that the prefix also will be used for IPv6 address autoconfiguration. I meant that the provided prefix was both for DHAAD and for Autoconf. If the provided prefix is intended only for the use of DHAAD and the auto-configuration is not allowed with it, it should be mentioned clearly in the document..isn't it? > I don't think this draft should be extended to deal with the > home address configuration (be it per-mn prefix or individual > addresses). > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 03:14:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F210A28C177; Wed, 16 Apr 2008 03:14: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 181F528C177 for ; Wed, 16 Apr 2008 03:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waNOhrbNUwDG for ; Wed, 16 Apr 2008 03:14:50 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 29D8228C14E for ; Wed, 16 Apr 2008 03:14:49 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE0058XXTO2U@mailout2.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 19:15:24 +0900 (KST) Received: from ep_spt04 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZE009ALXTOHH@ms5.samsung.com> for mext@ietf.org; Wed, 16 Apr 2008 19:15:24 +0900 (KST) Content-return: prohibited Date: Wed, 16 Apr 2008 10:15:24 +0000 (GMT) From: Heejin Jang To: Heejin Jang , Jari Arkko , "Premec, Domagoj" , "mext@ietf.org" Message-id: <8005168.254611208340924338.JavaMail.weblogic@epml10> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080416100947385@heejin.jang X-MTR: 20080416100947385@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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 prefixes allocated for IPv6 autoconfiguration may not be available for DHAAD. So the current sub-opt-code 1 (both for auto-conf and DHAAD) is not exact in that sense. Now if we narrow down the use of the provided prefix for only DHAAD, I need to mention it in the document. Agree? ------- Original Message ------- Sender : Heejin Jang R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology Date : 2008-04-16 19:04 (GMT+09:00) Title : Re: Re: [MEXT] FW: Summary for the changes in hiopt-13 See below. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, April 16, 2008 6:50 PM > To: Premec, Domagoj > Cc: heejin.jang@samsung.com; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > > > In deployments where the per-MN prefix model is used, > letting the MN know the home prefix is equal to assigning the > address to the MN. I'm not clear if DHAAD works with per-MN > prefix model. I thought that the main purpose of the home > network prefix is the same as the MIP6_HOME_PREFIX attribute > from RFC 5026. For DHAAD, the better way might be to include > prefix length in the Home agent address option, and if the > bits after the prefix length are zero, the MN should run > DHAAD. In this way the MN could be told to run DHAAD with one > prefix and use another prefix for its home address configuration. > > > > Clearly we had different ideas about the use of the prefix in > hiopt. But I think it is intended for the use of DHAAD. See > paragraph 1 in Section 1. As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 carries home network prefix together with valid & preferred lifetimes. This means that the prefix also will be used for IPv6 address autoconfiguration. I meant that the provided prefix was both for DHAAD and for Autoconf. If the provided prefix is intended only for the use of DHAAD and the auto-configuration is not allowed with it, it should be mentioned clearly in the document..isn't it? > I don't think this draft should be extended to deal with the > home address configuration (be it per-mn prefix or individual > addresses). > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 03:25:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF093A6BFE; Wed, 16 Apr 2008 03: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 398F63A6B16 for ; Wed, 16 Apr 2008 03:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 WO+JLSZt6fEp for ; Wed, 16 Apr 2008 03:25:37 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CBCC73A6BFE for ; Wed, 16 Apr 2008 03:25:36 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7E10C198805; Wed, 16 Apr 2008 13:26:11 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 35C9219871D; Wed, 16 Apr 2008 13:26:11 +0300 (EEST) Message-ID: <4805D444.1080704@piuha.net> Date: Wed, 16 Apr 2008 13:26:12 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <22258564.254131208340262485.JavaMail.weblogic@epml10> In-Reply-To: <22258564.254131208340262485.JavaMail.weblogic@epml10> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 Heejin, > As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 > carries home network prefix together with valid & preferred lifetimes. > This means that the prefix also will be used for IPv6 address autoconfiguration. > I meant that the provided prefix was both for DHAAD and for Autoconf. > > If the provided prefix is intended only for the use of DHAAD and > the auto-configuration is not allowed with it, it should be mentioned clearly > in the document..isn't it? > I agree that this should be made clear in the document. But I'm also getting the sense that we're piling on many things into this document (including late changes), and it does not make me feel good. I tried to trace which caused us to insert the lifetimes into the document in version 11, but was unable to find it. Perhaps someone complained about the inability to see prefix length (version 10 had that problem)? In any case, I really do not want this document to extend itself into address configuration. You do not have the explanations or mechanisms in the document to do that. For instance, how would it work with security, i.e., avoiding grabbing someone else's address? Perhaps more to the point, we have already stretched our ability to make changes in late reviews, and we are close to sending it back to the WG. I would suggest stating that the prefix information is for DHAAD only, or alternatively removing the entire concept of sending prefix information. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 16 03:31:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D8628C193; Wed, 16 Apr 2008 03:31: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 2BA223A692E for ; Wed, 16 Apr 2008 03:31:27 -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_DE=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 LDbz67cmN8MT for ; Wed, 16 Apr 2008 03:31:26 -0700 (PDT) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id EFD443A6C5C for ; Wed, 16 Apr 2008 03:31:24 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 12:31:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 12:31:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Global PKIs ( was Re: changes in the CNs) thread-index: AcifnzUM5oTspJXNTHGnscv8YLQifAABK/VE References: <4804B71D.3050102@it.uc3m.es><4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> <4804F070.5030104@mccallumwhyman.com> <4805BE3D.4090702@mccallumwhyman.com> From: To: , X-OriginalArrivalTime: 16 Apr 2008 10:31:58.0792 (UTC) FILETIME=[199CBC80:01C89FAD] Subject: Re: [MEXT] Global PKIs ( was Re: changes in the CNs) 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, the idea of the related sentence in Section 3.8.1. in the requirements docu= ment is to reduce the set of nodes to whom the MR has a trust relationship = with (wrt certificates) to one where it is guaranteed that it will work and= the certificates are stable and reliable. Extending it to the CNs involves problems and assuming a distributed PKI wi= th numerous CAs for the future in aviation has its own problems, like the c= omplex building of certification paths in case of bridges, using the correc= t certificate or problems with certain local policies. Given a certificate = is not accepted at the CN (for whathever reasons) there must still be a way= communication can take place, and having RO is necessary for this purpose. Fact is no one knows when an "end2end" PKI is available and how reliably it= will work. Basing the *primary* RO solution on such an assumption seems da= ngerous and as the requirements document says "anchor points may be owned b= y the service providers" it seems reasonable to take advantage of airlines = and communication service providers having contracts with each other for th= e purpose of RO. Christian -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org im Auftrag von Tony Whyman Gesendet: Mi 16.04.2008 10:52 An: mext@ietf.org Betreff: [MEXT] Global PKIs ( was Re: changes in the CNs) = Dear all, From some off list discussions that have taken place, I get the feeling = that different people focus on different issues when the term "global = PKI" is mentioned. There is thus a need to agree on the interpretation = of the term "global PKI". Firstly, there is a clear need to separate out discussion on the = technology used (certificate formats, digital signature algorithms, = etc.) from the process of issuing certificates (politics). In my paper and posts, I have assumed an evolutionary approach to both, = with a single global PKI being the logical outcome of this process. On = the other hand, I have no problem in conceding that the move from = regional to a single global PKI may have political issues associated = with it, in the sense that one CA may have problems recognising the = validity and integrity of the process performed by another CA. It may = thus be a very long evolutionary process. My proposal is thus that the requirement for an aviation global PKI is = interpreted as a need for a core common PKI technology supporting a = number of regional PKIs, with a long term objective of evolving into a = single global PKI. My assumption here is that the main problem in establishing a regional = PKI is technology, while joining the regions together to form a single = global PKI is a political problem. A region is thus self-defining. The practical implication is that an aircraft will need a certificate = for each region in which it operates and will need to be able to = validate certificates presented to it issued by the CAs responsible for = those regions. Implementations will have to be able to work with = multiple certificates and CAs. Only when CAs start issuing = cross-certificates for each other, will the number of certificates that = an aircraft needs, be reduced. The issuing of the cross-certificate is where the political issue arises = as will only be done when a given regional CA is fully satisfied as to = the validity and integrity of the process performed by another regional CA. Regards Tony Whyman _______________________________________________ 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 Apr 16 07:51:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCF93A6F43; Wed, 16 Apr 2008 07: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 2A0AA28C1F2 for ; Wed, 16 Apr 2008 07:50: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 T1t7G5z2-3MR for ; Wed, 16 Apr 2008 07:50:57 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 47F733A6BFE for ; Wed, 16 Apr 2008 07:50:57 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m3GEpTtO024763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2008 15:51:30 +0100 Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m3GEpTvj018812; Wed, 16 Apr 2008 15:51:30 +0100 Message-ID: <48061273.1040703@mccallumwhyman.com> Date: Wed, 16 Apr 2008 15:51:31 +0100 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Christian.Bauer@dlr.de References: <4804B71D.3050102@it.uc3m.es><4804D61E.7090605@mccallumwhyman.com> <4804D79F.1010700@it.uc3m.es> <4804F070.5030104@mccallumwhyman.com> <4805BE3D.4090702@mccallumwhyman.com> In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] Global PKIs ( was Re: changes in the CNs) 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 Christian, Your comment "Given a certificate is not accepted at the CN (for = whatever reason) there must still be a way communication can take = place..." reminds me of a now deleted requirement in the original ATN = SARPs. This was titled "Emergency use of a Mobile Subnetwork" and = basically said that if an aircraft calls within 5 mins of comms being = rejected, it must be accepted - at least for emergency use (knock twice = and you're in). Without qualifying what "an emergency" was, this = requirement was aimed at ensuring comms would be available. I was = certainly present at the meeting that agreed this, and the requirement = reads as if I wrote it - but I can't remember that degree of detail. The = point is, it was later deleted once the operational people got involved. The comms group that wrote the original SARPs thought like you do (like = I did), that there must always be a way for data link communication to = take place. The operational people beg to differ. If you look at the way = the European system works today, data link equipped aircraft must = explicitly identify themselves to the ATC Provider and, unless they are = on a list of approved aircraft, they will be rejected for data link service. The reason for this is air safety. The ATC Provider needs to be sure = that the aircraft's data link implementation has been properly certified = and approved for use. Data link is supplementary to a general = certificate of air-worthiness and hence must be separately verified An = aircraft that does not have certified equipment on board, or is from an = airline whose pilot procedures for use of data link have not been = approved, may be a hazard to other airspace users. Hence service denied. What happens to the aircraft? It must have a working VHF radio and hence = can still be offered voice based ATC services. At present, ATC for that = aircraft is simply less efficient than it should be. In the future, this = will mean that the aircraft will be limited in its choice of airspaces = and will probably have to bump around at 20,000 feet. However, there is another problem lurking here and that is that the = current ATN-OSI was designed around the open access principle. The = current system cannot provide a proof of identity. This is acceptable = for the present, partly because the ATN-OSI protocols are not part of = every Linux distribution and hence there is a technical barrier to = overcome for any attacker, and partly because of high quality = Surveillance from SSR Mode S radars. Controllers can readily spot any = discrepancy between data comms, voice comms and the Airspace picture. A move to ATN-IP potentially removes one of those props and simply by = using industry standard protocols without any mitigation, weakens the = system. It also makes it difficult to realise any cost savings by = reducing dependency on SSR Mode S. An important Operational Requirement was missed first time around and it = seems to me fairly obviously that now the requirement is known, any = ATN-IP must respect it. That is identity of aircraft must be visible to = the ATC Provider, and credentials offered that support that identity. = This is so that Data Link ATC Service is not given to unapproved aircraft. There is a validated ATN-OSI specification (PKI based) to add a proof to = the identity. The business case for this enhancement is not there yet - = but one day it will be - if only because having a signed certificate = will be easier to manage than an ever growing list of approved aircraft. = It would be nice if you can put the case: rather than investing more in = the old system, why not put the money into deploying ATN-IP. You may argue that a Service Provider could still be a proxy and check = the identity on behalf of the ATC Provider. But think of the liability = issues. I doubt whether the risk of getting this wrong is insurable. Hence my own view that any ATN-IP has to start from the assumption that = there is a direct trust relationship between the ATC Provider and the = aircraft it serves. IPsec supported by an appropriate PKI appears to be = the correct way of realising this. Regards Tony Christian.Bauer@dlr.de wrote: > Hi, > > the idea of the related sentence in Section 3.8.1. in the requirements do= cument is to reduce the set of nodes to whom the MR has a trust relationshi= p with (wrt certificates) to one where it is guaranteed that it will work a= nd the certificates are stable and reliable. > > Extending it to the CNs involves problems and assuming a distributed PKI = with numerous CAs for the future in aviation has its own problems, like the= complex building of certification paths in case of bridges, using the corr= ect certificate or problems with certain local policies. Given a certificat= e is not accepted at the CN (for whathever reasons) there must still be a w= ay communication can take place, and having RO is necessary for this purpos= e. > Fact is no one knows when an "end2end" PKI is available and how reliably = it will work. Basing the *primary* RO solution on such an assumption seems = dangerous and as the requirements document says "anchor points may be owned= by the service providers" it seems reasonable to take advantage of airline= s and communication service providers having contracts with each other for = the purpose of RO. > > Christian > > > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org im Auftrag von Tony Whyman > Gesendet: Mi 16.04.2008 10:52 > An: mext@ietf.org > Betreff: [MEXT] Global PKIs ( was Re: changes in the CNs) > = > Dear all, > > From some off list discussions that have taken place, I get the feeling = > that different people focus on different issues when the term "global = > PKI" is mentioned. There is thus a need to agree on the interpretation = > of the term "global PKI". > > Firstly, there is a clear need to separate out discussion on the = > technology used (certificate formats, digital signature algorithms, = > etc.) from the process of issuing certificates (politics). > > In my paper and posts, I have assumed an evolutionary approach to both, = > with a single global PKI being the logical outcome of this process. On = > the other hand, I have no problem in conceding that the move from = > regional to a single global PKI may have political issues associated = > with it, in the sense that one CA may have problems recognising the = > validity and integrity of the process performed by another CA. It may = > thus be a very long evolutionary process. > > My proposal is thus that the requirement for an aviation global PKI is = > interpreted as a need for a core common PKI technology supporting a = > number of regional PKIs, with a long term objective of evolving into a = > single global PKI. > > My assumption here is that the main problem in establishing a regional = > PKI is technology, while joining the regions together to form a single = > global PKI is a political problem. A region is thus self-defining. > > The practical implication is that an aircraft will need a certificate = > for each region in which it operates and will need to be able to = > validate certificates presented to it issued by the CAs responsible for = > those regions. Implementations will have to be able to work with = > multiple certificates and CAs. Only when CAs start issuing = > cross-certificates for each other, will the number of certificates that = > an aircraft needs, be reduced. > > The issuing of the cross-certificate is where the political issue arises = > as will only be done when a given regional CA is fully satisfied as to = > the validity and integrity of the process performed by another regional C= A. > > Regards > > Tony Whyman > > > > _______________________________________________ > 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 Apr 16 15:01:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C313A6B76; Wed, 16 Apr 2008 15:01: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 EAC083A6A47 for ; Wed, 16 Apr 2008 15:01:33 -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 CNXzcBFxtGU7 for ; Wed, 16 Apr 2008 15:01:33 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id C5E793A6B76 for ; Wed, 16 Apr 2008 15:01:32 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m3GM260F004353; Thu, 17 Apr 2008 00:02:06 +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 m3GM26OW029130; Thu, 17 Apr 2008 00:02:06 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Apr 2008 00:02:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 00:02:01 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803BA84B1@zagh223a.ww300.siemens.net> In-Reply-To: <4805D444.1080704@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: AcifrFnGNcf8t9qhRKaJBDAwyq+1rQAYHy0A References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" , X-OriginalArrivalTime: 16 Apr 2008 22:02:05.0438 (UTC) FILETIME=[81E581E0:01C8A00D] 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::080417000206-0BAC3BA0-35349212/0-0/0-15 X-purgate-size: 2987/999999 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, > I would suggest stating that the prefix information is for > DHAAD only, or alternatively removing the entire concept of > sending prefix information. I'm a bit worried about restricting the usage of the home prefix acquired via hiopt only to DHAAD. If we do that, we end up with two categories of home network prefixes: one that is allowed to be used only for DHAAD and the other one which is RFC 3775 conformant and is good for DHAAD, home link detection and address configuration. I don't think it should matter how the MN obtained the home link prefix. Once it gets it, it should be able to use it as per RFC 3775, without additional restrictions. Maybe the Home network prefix option should be removed from the draft and instead use the Home agent address option with IID bits set to zero to indicate DHAAD. This seems like a cleaner approach to me. Having said that, I don't want to delay the hiopt draft, and I'm fine with progressing the draft as per your comments. domagoj > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 16. travanj 2008 12:26 > To: heejin.jang@samsung.com > Cc: Premec, Domagoj; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Heejin, > > > As shown in Fig in page 10 of v13, the sub-option with > sub-opt-code 1 > > carries home network prefix together with valid & preferred > lifetimes. > > This means that the prefix also will be used for IPv6 > address autoconfiguration. > > I meant that the provided prefix was both for DHAAD and for > Autoconf. > > > > If the provided prefix is intended only for the use of > DHAAD and the > > auto-configuration is not allowed with it, it should be mentioned > > clearly in the document..isn't it? > > > I agree that this should be made clear in the document. > > But I'm also getting the sense that we're piling on many > things into this document (including late changes), and it > does not make me feel good. > > I tried to trace which caused us to insert the lifetimes into > the document in version 11, but was unable to find it. > Perhaps someone complained about the inability to see prefix > length (version 10 had that problem)? > > In any case, I really do not want this document to extend > itself into address configuration. You do not have the > explanations or mechanisms in the document to do that. For > instance, how would it work with security, i.e., avoiding > grabbing someone else's address? Perhaps more to the point, > we have already stretched our ability to make changes in late > reviews, and we are close to sending it back to the WG. > > I would suggest stating that the prefix information is for > DHAAD only, or alternatively removing the entire concept of > sending prefix information. > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 00:58:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5C03A6F30; Thu, 17 Apr 2008 00:58: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 E72043A6B42 for ; Thu, 17 Apr 2008 00:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvsxHMEcdHad for ; Thu, 17 Apr 2008 00:58:08 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 108213A67E3 for ; Thu, 17 Apr 2008 00:58:07 -0700 (PDT) Received: from ep_ms5_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZG00FO8M5RW3@mailout3.samsung.com> for mext@ietf.org; Thu, 17 Apr 2008 16:58:39 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZG006C6M5REZ@ms5.samsung.com> for mext@ietf.org; Thu, 17 Apr 2008 16:58:39 +0900 (KST) Content-return: prohibited Date: Thu, 17 Apr 2008 07:58:39 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <561893.298361208419119224.JavaMail.weblogic@epml14> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080417074551843@heejin.jang X-MTR: 20080417074551843@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: [MEXT] Submission of hiopt-14 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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. I've submitted new draft (hiopt-14) which reflects Alfred's lated comments and the discussion results about sub-opt-codes. Regarding sub-option for IPv6 home network prefix, for minimum change, I kept using the same set of sub-opt-codes as you recommened, and the Home Network Parameter field in the sub-option was just simplified without lifetimes because they were intended to be used for address auto-configuration. - Best regards, Heejin ------- Original Message ------- Sender : Jari Arkko Date : 2008-04-16 19:26 (GMT+09:00) Title : Re: [MEXT] FW: Summary for the changes in hiopt-13 Heejin, > As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 > carries home network prefix together with valid & preferred lifetimes. > This means that the prefix also will be used for IPv6 address autoconfiguration. > I meant that the provided prefix was both for DHAAD and for Autoconf. > > If the provided prefix is intended only for the use of DHAAD and > the auto-configuration is not allowed with it, it should be mentioned clearly > in the document..isn't it? > I agree that this should be made clear in the document. But I'm also getting the sense that we're piling on many things into this document (including late changes), and it does not make me feel good. I tried to trace which caused us to insert the lifetimes into the document in version 11, but was unable to find it. Perhaps someone complained about the inability to see prefix length (version 10 had that problem)? In any case, I really do not want this document to extend itself into address configuration. You do not have the explanations or mechanisms in the document to do that. For instance, how would it work with security, i.e., avoiding grabbing someone else's address? Perhaps more to the point, we have already stretched our ability to make changes in late reviews, and we are close to sending it back to the WG. I would suggest stating that the prefix information is for DHAAD only, or alternatively removing the entire concept of sending prefix information. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 01:21:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D213A6B42; Thu, 17 Apr 2008 01:21: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 029013A6909 for ; Thu, 17 Apr 2008 01:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 98X45NbvXAC0 for ; Thu, 17 Apr 2008 01:21:14 -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 06CEC3A68B4 for ; Thu, 17 Apr 2008 01:21:13 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2840259wfa.31 for ; Thu, 17 Apr 2008 01:21:51 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=gl3lZLvm9AjSP52ZIZfWxXgHkmj0GSPFxg+SVi8XP+k=; b=EPTEprLBXKIqzvrGcq0gNGt3jeGrJbN6vtaUyz4xkuCRM6M8v+aJ+uQTMB+RNnCA8CNgRf3Nsi63WoWpZ8FLvbRZjLgyw7IyPUrUXR1TtwiD3Dm2Ujk5qvkn7UmVyvBV54m0WQlnYg3pUOwKHE2zkjdUO+EZaOGMXBkT/4wrco8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dfw1Xb5r79+bSwpUj8gZ/B/yN4oywYLgsMqWyIlnIiclEptzOnnGSgNsyLM437scgmeFBoCthzBTSEXli3eK/AjOYDL5XmgDfRg9MtCbbc+dxVpO8P/jprA9UL73ZnTgUU8dXCegGBUcNwerHLBIIM8qxu5eBdPvkr7xGDUWzug= Received: by 10.142.186.9 with SMTP id j9mr329038wff.284.1208420511574; Thu, 17 Apr 2008 01:21:51 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 17 Apr 2008 01:21:51 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 09:21:51 +0100 From: "George Tsirtsis" To: mext MIME-Version: 1.0 Content-Disposition: inline Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 all, Here is the clarification text for IKEv2/IPSEC and DSMIPv6 interactions. In particular, the text clarifies the behavior when the MN is connected to an IPv4 network, which RFC4877 does not cover. Thanks to Pasi for his review and his help with defining the required SPDs; also thanks to Wassim and Hesham for their review. Hesham will fold the following text appropriately into the DSMIPv6 draft following a hopefully quick review from the group. Best Regards George P.S.: I will have intermittent connectivity Friday-Sunday. ----------------------------------------------------------------------------------------------------------------------- DSMIPv6 defines a number of possible data encapsulations depending on the MN's connectivity and MN's and HA's configuration. These encapsulations and the signaling required to establish them, are straight forward when the MN is connected to an IPv6 capable network. Some clarification is, however, needed for IKEv2/IPSEC operations when the MN is connected to an IPv4-only network. 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 includes information about how IKEv2 runs over IPv4/UDP for NAT Traversal. A DSMIPv6 MN connected to an IPv4-only network then, needs to follow the procedures described below. To establish an SA for the protection of BU/BA messages, the DSMIPv6 MN and the HA SHOULD implement the following IKEv2 compatible procedure: Mobile Node Home Agent ----------- ---------- IPv4(source_addr=V4ADDR, dest_addr=HAADDR) UDP (500, 500) HDR, SAi1, KEi, Ni NAT-D, NAT-D --> <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] NAT-D, NAT-D IPv4(source_addr=V4ADDR, dest_addr=HAADDR) UDP (4500,4500) HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) UDP (4500,Y) HDR*#, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} The SPDs are as shown in RFC 4877 Section 7.2.1 mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use SA ESP transport mode Initiate using IDi = user_1 to address home_agent_1 home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use SA ESP transport mode where home_address_1 is the MN's registered IPv6 home address and home_agent_1 is the IP address of the home agent The above should result in BU/BA messages with the following encapsulations: Binding update received by the home agent: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (sport=X, dport=DSMIPv6) IPv6 header (src=V6HOA, dst=HAADDR) ESP Header in Transport Mode Mobility header BU [IPv4 HAO] IPv4 CoA option (+ other as needed) At the home agent, following UDP de-tunneling the Binding Update is delivered to the IPSEC module as shown below: IPv6 header (src=V6HOA, dst=HAADDR) ESP Header in Transport Mode Mobility header BU [IPv4 HAO] IPv4 CoA option (+ other as needed) The Binding Update following IPSEC processing is delivered to the DSMIPv6 home agent module as follows: IPv6 header (src=V6HOA, dst=HAADDR) Mobility header BU [IPv4 HAO] IPv4 CoA option (+ other as needed) The Binding Acknowledgement sent by the home agent module to the IPSEC module is as follows: IPv6 header (src=HAADDR, dst=V6HOA) Mobility Header BA ([IPv4 ACK], NAT DET) (+ other as needed) The Binding Acknowledgement send by the HA to the MN is as follows: IPv4 header (src= HA_V4ADDR, dst=V4ADDR) UDP Header (sport=DSMIPv6, dport=Y) IPv6 header (src=HAADDR, dst=V6HOA) ESP Header in Transport Mode Mobility Header BA ([IPv4 ACK], NAT DET) 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 To secure data traffic when the MN is located on an IPv4 only network, the MN MUST establish a child_SA for that purpose. The procedure is as follows: Mobile Node Home Agent ----------- ---------- UDP (4500,4500) HDR, SK {[N], SA, Ni, [KEi],[TSi, TSr]} --> <-- UDP (4500,Y) HDR, SK {SA, Nr, [KEr], [TSi, TSr]} If no NAT is detected, the encapsulation used will be: IPv4 (source_addr=v4CoA, dest_addr=HAAddr) ESP IP (source_addr=HoA, set_addr=CNAddr) Upper_layer_HDR where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA If NAT is detected, the encapsulation used will be IPv4 (source_addr=v4Addr, dest_addr=HAAddr) UDP (sport=X, dport=4500) ESP IP (source_addr=HoA, set_addr=CNAddr) Upper_layer_HDR where v4CoA may be the external IPv4 address of the NAT, IP is either IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA The SPD for data decryption whether NAT is detected or not is set as follows. Note that this rule is designed to match all data from the MN to nodes other than the HA. This is done so that this rule does not overlap with the earlier rule securing BU/BA signaling between the MN and the HA. Mobile Node SPD-S: - IF local_address = home_address & remote_address != home_agent & proto=any Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1 home agent SPD-S: - IF local_address != home_agent & remote_address = home_address & proto = any Then use SA ESP tunnel mode where home_address is the MN's registered IPv6 or IPv4 home address and home_agent is the IPv6 or the IPv4 address of the home agent. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 01:24:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BB03A6C38; Thu, 17 Apr 2008 01:24: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 3244A28C4E9 for ; Thu, 17 Apr 2008 01:24:55 -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 utX7cwBJobFl for ; Thu, 17 Apr 2008 01: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 4AC0E3A6BE4 for ; Thu, 17 Apr 2008 01:24:48 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 95138198805; Thu, 17 Apr 2008 11:25:24 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5CD86198759; Thu, 17 Apr 2008 11:25:24 +0300 (EEST) Message-ID: <48070976.9040100@piuha.net> Date: Thu, 17 Apr 2008 11:25:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: "mext@ietf.org" References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> In-Reply-To: <4805D444.1080704@piuha.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 now happy with -14. I would like at least a few acknowledgments from the WG members that they too are happy. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 01:49:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E2C3A6A2D; Thu, 17 Apr 2008 01:49: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 865543A6A2D for ; Thu, 17 Apr 2008 01:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.526, 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 Xq3ntUW2pomd for ; Thu, 17 Apr 2008 01:48:59 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by core3.amsl.com (Postfix) with ESMTP id A5C233A6A17 for ; Thu, 17 Apr 2008 01:48:59 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3555361pyg.24 for ; Thu, 17 Apr 2008 01:49:37 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xwO7lIWeDFykoLBT68Q6aPEgNEYpuzx2rEAa2n0p0DM=; b=Bw5U9ub2avpVWF9wpsJmeKcMcH4VypZd+UEqO/ZwuFzXoa/phRXNbw9qmMwzNA9RA3sYL/WZepnqTeh2TWb/AsF1Vrj+ddNvgSY7rG8NXRwwwOAQ1uVdT+tuFHDOaKC08kb8c1/MY9fcu2nDJwur/5b18dWibSybej60qVRLB6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=Jkpx8QRwFaTGKmQm8Jkhfb2n5bmeXmSpqUhT9rcqLMPdu6gb2i+0512ffS63M2mYNuy1gOFnOA++PoUDkoMbUNnoY5QvdX6NHgxbaL80IUvcRiyXzf6qasOxULJmTmiB6ZaZ60sKJ/r7sEgrEVlYDpkNTzFOUicIGa8glnU2kaY= Received: by 10.142.71.15 with SMTP id t15mr339009wfa.315.1208422176786; Thu, 17 Apr 2008 01:49:36 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 17 Apr 2008 01:49:36 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 09:49:36 +0100 From: "George Tsirtsis" To: "Jari Arkko" In-Reply-To: <48070976.9040100@piuha.net> MIME-Version: 1.0 Content-Disposition: inline References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> Cc: =?UTF-8?Q?Alfred_=EF=BF=BD?= , "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 the draft is generally OK. Given the discussion we just had, however, the draft does not describe at all what the MN is supposed to do with the information received. If there are restrictions in terms of what the MN is supposed to do e.g., can not create an address out of the HNP, then that should be indicated. I have to admit though that I am not sure why such restrictions would be necessary, so being silent on the issue is OK with me. One more thing. Do you think that the relationship between the HA information received and the link on which the MN is attached is always clear? Would it be useful to say something about detecting whether the HA information returned corresponds to an HA "on-link" wrt to the requesting MN? e.g., the MN can compare the HNP received from DHCP with the prefixes in the RA received on link, or instead an explicit indication maybe included in the DHCP message when that is the case.. Note that the MN may request for HA info of a specific MSP without realizing that it is already connected to it. Thanks George On Thu, Apr 17, 2008 at 9:25 AM, Jari Arkko wrote: > I am now happy with -14. I would like at least a few acknowledgments > from the WG members that they too are happy. > > > > 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 Apr 17 02:16:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D833A7022; Thu, 17 Apr 2008 02:16: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 74D783A7003 for ; Thu, 17 Apr 2008 02:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 JjQiw-6OVu5i for ; Thu, 17 Apr 2008 02:15:54 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A64043A68F0 for ; Thu, 17 Apr 2008 02:15:30 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 71C86198805; Thu, 17 Apr 2008 12:16:07 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 322BC1986D5; Thu, 17 Apr 2008 12:16:07 +0300 (EEST) Message-ID: <48071558.3030506@piuha.net> Date: Thu, 17 Apr 2008 12:16:08 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: George Tsirtsis References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, > If > there are restrictions in terms of what the MN is supposed to do e.g., > can not create an address out of the HNP, then that should be > indicated. I have to admit though that I am not sure why such > restrictions would be necessary, so being silent on the issue is OK > with me. > Section 3.3 does say that the prefix info is for dynamic discovery only. Are you missing some other specific information? > One more thing. Do you think that the relationship between the HA > information received and the link on which the MN is attached is > always clear? Would it be useful to say something about detecting > whether the HA information returned corresponds to an HA "on-link" wrt > to the requesting MN? e.g., the MN can compare the HNP received from > DHCP with the prefixes in the RA received on link, or instead an > explicit indication maybe included in the DHCP message when that is > the case.. > Note that the MN may request for HA info of a specific MSP without > realizing that it is already connected to it. > Having DHCP indicate too much of what the mobile node should do with the information would probably lead into problems. Mobile nodes have to be able to deal with these things, with or without discovery, because they can have multiple interfaces. (I wouldn't mind if some additional clarifying text were added because of the above.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 02:21:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0522C3A6D39; Thu, 17 Apr 2008 02: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 56E513A6A82 for ; Thu, 17 Apr 2008 02:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.499, 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 Ip6vKwj-849I for ; Thu, 17 Apr 2008 02:21:00 -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 4EACF3A6FEE for ; Thu, 17 Apr 2008 02:20:21 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2853916wfa.31 for ; Thu, 17 Apr 2008 02:20: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Nl2nWEaBW9EVLfz6633A/PihbfHajpfDSF/7aEILmss=; b=rGG1BGDj9qGkP5l+s+8DfN6FCImV5u942HdHmsOugljYlGbB0XPPAN67CyOuNWO3cfx5h95Ct0cI96ASjENb0RnZOlQAkfq/K5jNksfYjvF5s7256rKpUbBC+fV9EBnG+RkQuoJGUPxU1dp1MrmwLDrlCaDNKJZx8dtEedu/hWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=DWPa26H/46IUQUFRMMZYFiZIlkO4sk35dDH6nLyQ6sH9hy43uwJx3FgjsS4SPt9uIezWGX2wbpCOXOkZZdNS76Vvv7ka+LQ8nIX89X6jvILx/Y96P0IfqvogOdW1mmmlkPKLkDxX7j96DR88ynfQ9HO6tXVht7oNHS8XIqCjhW0= Received: by 10.142.142.16 with SMTP id p16mr352715wfd.176.1208424058805; Thu, 17 Apr 2008 02:20:58 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 17 Apr 2008 02:20:58 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 10:20:58 +0100 From: "George Tsirtsis" To: "Jari Arkko" In-Reply-To: <48071558.3030506@piuha.net> MIME-Version: 1.0 Content-Disposition: inline References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> <48071558.3030506@piuha.net> Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 OK, I earlier missed the text in section 3.3. Thanks George On Thu, Apr 17, 2008 at 10:16 AM, Jari Arkko wrote: > George, > > > > If > > there are restrictions in terms of what the MN is supposed to do e.g., > > can not create an address out of the HNP, then that should be > > indicated. I have to admit though that I am not sure why such > > restrictions would be necessary, so being silent on the issue is OK > > with me. > > > > Section 3.3 does say that the prefix info is for dynamic discovery only. > Are you missing some other specific information? > > > > One more thing. Do you think that the relationship between the HA > > information received and the link on which the MN is attached is > > always clear? Would it be useful to say something about detecting > > whether the HA information returned corresponds to an HA "on-link" wrt > > to the requesting MN? e.g., the MN can compare the HNP received from > > DHCP with the prefixes in the RA received on link, or instead an > > explicit indication maybe included in the DHCP message when that is > > the case.. > > Note that the MN may request for HA info of a specific MSP without > > realizing that it is already connected to it. > > > > Having DHCP indicate too much of what the mobile node should do with the > information would probably lead into problems. Mobile nodes have to be > able to deal with these things, with or without discovery, because they > can have multiple interfaces. > > (I wouldn't mind if some additional clarifying text were added because > of the above.) > > Jari > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 02:51:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEB83A6A16; Thu, 17 Apr 2008 02:51: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 74F053A6A47 for ; Thu, 17 Apr 2008 02:51:00 -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 9-I9Zr0C3ZBr for ; Thu, 17 Apr 2008 02:50:56 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 33D953A6FE9 for ; Thu, 17 Apr 2008 02:50:52 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m3H9pQrK030230; Thu, 17 Apr 2008 11:51:26 +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 m3H9pQEq031578; Thu, 17 Apr 2008 11:51:26 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Apr 2008 11:51:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 11:51:19 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803BA88FB@zagh223a.ww300.siemens.net> In-Reply-To: <48071558.3030506@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: Aciga9kt7hGDWOZRTFGbotBKzJUSTQABGUPA References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> <48071558.3030506@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" , "George Tsirtsis" X-OriginalArrivalTime: 17 Apr 2008 09:51:25.0737 (UTC) FILETIME=[99CFC190:01C8A070] 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::080417115126-265B6BB0-33B5D566/0-0/0-15 X-purgate-size: 2425/0 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, George, > (I wouldn't mind if some additional clarifying text were > added because of the above.) Would the following change be acceptable: Old text: Note that the provided prefix information MUST be used for the dynamic home agent discovery only. New text: Note that the provided prefix information MUST be used only for the dynamic home agent discovery and home link detection. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: 17. travanj 2008 11:16 > To: George Tsirtsis > Cc: mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > George, > > > If > > there are restrictions in terms of what the MN is supposed > to do e.g., > > can not create an address out of the HNP, then that should be > > indicated. I have to admit though that I am not sure why such > > restrictions would be necessary, so being silent on the issue is OK > > with me. > > > > Section 3.3 does say that the prefix info is for dynamic > discovery only. > Are you missing some other specific information? > > > One more thing. Do you think that the relationship between the HA > > information received and the link on which the MN is attached is > > always clear? Would it be useful to say something about detecting > > whether the HA information returned corresponds to an HA > "on-link" wrt > > to the requesting MN? e.g., the MN can compare the HNP > received from > > DHCP with the prefixes in the RA received on link, or instead an > > explicit indication maybe included in the DHCP message when that is > > the case.. > > Note that the MN may request for HA info of a specific MSP without > > realizing that it is already connected to it. > > > > Having DHCP indicate too much of what the mobile node should > do with the information would probably lead into problems. > Mobile nodes have to be able to deal with these things, with > or without discovery, because they can have multiple interfaces. > > (I wouldn't mind if some additional clarifying text were > added because of the above.) > > 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 Apr 17 03:04:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C723A684D; Thu, 17 Apr 2008 03:04: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 86C533A6FFD for ; Thu, 17 Apr 2008 03:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.483, 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 8SqO+4nZVrB1 for ; Thu, 17 Apr 2008 03:04:17 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 166E13A6FF3 for ; Thu, 17 Apr 2008 03:04:17 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2864379wfa.31 for ; Thu, 17 Apr 2008 03:04:54 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GhO5ORlGdiHasQ5bdiNBau/ZnPmBeS7aKaWwgL85Ub8=; b=FLr0I8zEa1Ba6OG9SpRu2ektNrdg7CbdbUug8JoQE63vZxHI2HZ8GnWZ1PGykcXfdeXu3cQ961SO5U+SoBnlHgORdNpEHzWGnYWrt8f92siDxfK6Vvu7Q/Wr9l9dDzcuh29kAWgwXtf7LVjwYOJ7w2miV2r6kO17N8s3M2TM3EU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=vbpFK7/2CGtEgZNmyH3bL+sJiX9Z2FH+HFTXJAhgwnc3HoM4ImSYdT46CDsCwC4cNGurvLKEe9STcvK/kMMgfLWsnOYsY+8OGSyWvCcrHe6nXd4BcoIb/3kWhA+qMNTrb29PS/DnSMO9Y6aJRLCSZL/cqa9cF4SoSjHTED7ZnzY= Received: by 10.142.82.17 with SMTP id f17mr370516wfb.145.1208426694556; Thu, 17 Apr 2008 03:04:54 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 17 Apr 2008 03:04:54 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 11:04:54 +0100 From: "George Tsirtsis" To: "Premec, Domagoj" In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6803BA88FB@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Disposition: inline References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> <48071558.3030506@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803BA88FB@zagh223a.ww300.siemens.net> Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 was not going to say anything but the truth is that I do not like this MUST statement. I would rephrase with something like this: "The prefix information is provided so that the mobile node can perform dynamic home agent discovery as defined in RFC3775. The information may also be used to allow the mobile node to determine whether the home agent information received via DHCPv6 corresponds to a home agent on-link or not." Regards George On Thu, Apr 17, 2008 at 10:51 AM, Premec, Domagoj wrote: > Jari, George, > > > > (I wouldn't mind if some additional clarifying text were > > added because of the above.) > > Would the following change be acceptable: > > Old text: > Note that the provided prefix information MUST be used for > the dynamic home agent discovery only. > > New text: > Note that the provided prefix information MUST be used only for > the dynamic home agent discovery and home link detection. > > > domagoj > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Jari Arkko > > > Sent: 17. travanj 2008 11:16 > > To: George Tsirtsis > > Cc: mext@ietf.org > > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > > > > > George, > > > > > If > > > there are restrictions in terms of what the MN is supposed > > to do e.g., > > > can not create an address out of the HNP, then that should be > > > indicated. I have to admit though that I am not sure why such > > > restrictions would be necessary, so being silent on the issue is OK > > > with me. > > > > > > > Section 3.3 does say that the prefix info is for dynamic > > discovery only. > > Are you missing some other specific information? > > > > > One more thing. Do you think that the relationship between the HA > > > information received and the link on which the MN is attached is > > > always clear? Would it be useful to say something about detecting > > > whether the HA information returned corresponds to an HA > > "on-link" wrt > > > to the requesting MN? e.g., the MN can compare the HNP > > received from > > > DHCP with the prefixes in the RA received on link, or instead an > > > explicit indication maybe included in the DHCP message when that is > > > the case.. > > > Note that the MN may request for HA info of a specific MSP without > > > realizing that it is already connected to it. > > > > > > > Having DHCP indicate too much of what the mobile node should > > do with the information would probably lead into problems. > > Mobile nodes have to be able to deal with these things, with > > or without discovery, because they can have multiple interfaces. > > > > (I wouldn't mind if some additional clarifying text were > > added because of the above.) > > > > 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 Apr 17 03:07:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A113A6F99; Thu, 17 Apr 2008 03:07: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 633253A69DF for ; Thu, 17 Apr 2008 03:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 4J5Trc3qsAr5 for ; Thu, 17 Apr 2008 03:06:52 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EA1A028C175 for ; Thu, 17 Apr 2008 03:06:51 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 04FDB198806; Thu, 17 Apr 2008 13:07:29 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 88438198788; Thu, 17 Apr 2008 13:07:28 +0300 (EEST) Message-ID: <48072162.7010008@piuha.net> Date: Thu, 17 Apr 2008 13:07:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: George Tsirtsis References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> <48071558.3030506@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803BA88FB@zagh223a.ww300.siemens.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 like this text... Jari George Tsirtsis kirjoitti: > Sorry, I was not going to say anything but the truth is that I do not > like this MUST statement. I would rephrase with something like this: > > "The prefix information is provided so that the mobile node can > perform dynamic home agent discovery as defined in RFC3775. The > information may also be used to allow the mobile node to determine > whether the home agent information received via DHCPv6 corresponds to > a home agent on-link or not." > > Regards > George > > On Thu, Apr 17, 2008 at 10:51 AM, Premec, Domagoj > wrote: > >> Jari, George, >> >> >> > (I wouldn't mind if some additional clarifying text were >> > added because of the above.) >> >> Would the following change be acceptable: >> >> Old text: >> Note that the provided prefix information MUST be used for >> the dynamic home agent discovery only. >> >> New text: >> Note that the provided prefix information MUST be used only for >> the dynamic home agent discovery and home link detection. >> >> >> domagoj >> >> >> > -----Original Message----- >> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> > Behalf Of Jari Arkko >> >> >>> Sent: 17. travanj 2008 11:16 >>> >> > To: George Tsirtsis >> > Cc: mext@ietf.org >> > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 >> > >> >> >> >>> George, >>> >> > >> > > If >> > > there are restrictions in terms of what the MN is supposed >> > to do e.g., >> > > can not create an address out of the HNP, then that should be >> > > indicated. I have to admit though that I am not sure why such >> > > restrictions would be necessary, so being silent on the issue is OK >> > > with me. >> > > >> > >> > Section 3.3 does say that the prefix info is for dynamic >> > discovery only. >> > Are you missing some other specific information? >> > >> > > One more thing. Do you think that the relationship between the HA >> > > information received and the link on which the MN is attached is >> > > always clear? Would it be useful to say something about detecting >> > > whether the HA information returned corresponds to an HA >> > "on-link" wrt >> > > to the requesting MN? e.g., the MN can compare the HNP >> > received from >> > > DHCP with the prefixes in the RA received on link, or instead an >> > > explicit indication maybe included in the DHCP message when that is >> > > the case.. >> > > Note that the MN may request for HA info of a specific MSP without >> > > realizing that it is already connected to it. >> > > >> > >> > Having DHCP indicate too much of what the mobile node should >> > do with the information would probably lead into problems. >> > Mobile nodes have to be able to deal with these things, with >> > or without discovery, because they can have multiple interfaces. >> > >> > (I wouldn't mind if some additional clarifying text were >> > added because of the above.) >> > >> > 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 Apr 17 03:53:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3863A6C50; Thu, 17 Apr 2008 03:53: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 DEE9D3A6A79 for ; Thu, 17 Apr 2008 03:53:16 -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=[AWL=-0.000, 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 ZpkE5jg4VeIU for ; Thu, 17 Apr 2008 03:53:16 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 7B3E73A6C50 for ; Thu, 17 Apr 2008 03:53:15 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m3HArk06007803; Thu, 17 Apr 2008 12:53:46 +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 m3HAri8a029907; Thu, 17 Apr 2008 12:53:46 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Apr 2008 12:53:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 12:52:35 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803BA8A0E@zagh223a.ww300.siemens.net> In-Reply-To: <48072162.7010008@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: Summary for the changes in hiopt-13 Thread-Index: AcigcuxFvnAntuSKT4OPTGEhGx8dTAABckZA References: <22258564.254131208340262485.JavaMail.weblogic@epml10> <4805D444.1080704@piuha.net> <48070976.9040100@piuha.net> <48071558.3030506@piuha.net> <3C31CDD06342EA4A8137716247B1CD6803BA88FB@zagh223a.ww300.siemens.net> <48072162.7010008@piuha.net> From: "Premec, Domagoj" To: "Jari Arkko" , "George Tsirtsis" X-OriginalArrivalTime: 17 Apr 2008 10:53:45.0455 (UTC) FILETIME=[4EDB6FF0:01C8A079] 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::080417125346-265BDBB0-0A8617DC/0-0/0-15 X-purgate-size: 5326/0 Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 That's fine by me, too... domagoj > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 17. travanj 2008 12:07 > To: George Tsirtsis > Cc: Premec, Domagoj; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > I like this text... > > Jari > > George Tsirtsis kirjoitti: > > Sorry, I was not going to say anything but the truth is > that I do not > > like this MUST statement. I would rephrase with something like this: > > > > "The prefix information is provided so that the mobile node can > > perform dynamic home agent discovery as defined in RFC3775. The > > information may also be used to allow the mobile node to determine > > whether the home agent information received via DHCPv6 > corresponds to > > a home agent on-link or not." > > > > Regards > > George > > > > On Thu, Apr 17, 2008 at 10:51 AM, Premec, Domagoj > > wrote: > > > >> Jari, George, > >> > >> > >> > (I wouldn't mind if some additional clarifying text > were > added > >> because of the above.) > >> > >> Would the following change be acceptable: > >> > >> Old text: > >> Note that the provided prefix information MUST be used for > >> the dynamic home agent discovery only. > >> > >> New text: > >> Note that the provided prefix information MUST be used only for > >> the dynamic home agent discovery and home link detection. > >> > >> > >> domagoj > >> > >> > >> > -----Original Message----- > >> > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On > > >> Behalf Of Jari Arkko > >> > >> > >>> Sent: 17. travanj 2008 11:16 > >>> > >> > To: George Tsirtsis > >> > Cc: mext@ietf.org > >> > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > >> > >> > >> > >>> George, > >>> > >> > > >> > > If > >> > > there are restrictions in terms of what the MN is supposed > >> > to do e.g., > >> > > can not create an address out of the HNP, then that should be > >> > > indicated. I have to admit though that I am not sure why such > >> > > restrictions would be necessary, so being silent on > the issue is OK > >> > > with me. > >> > > > >> > > >> > Section 3.3 does say that the prefix info is for dynamic > >> > discovery only. > >> > Are you missing some other specific information? > >> > > >> > > One more thing. Do you think that the relationship > between the HA > >> > > information received and the link on which the MN is > attached is > >> > > always clear? Would it be useful to say something > about detecting > >> > > whether the HA information returned corresponds to an HA > >> > "on-link" wrt > >> > > to the requesting MN? e.g., the MN can compare the HNP > >> > received from > >> > > DHCP with the prefixes in the RA received on link, or > instead an > >> > > explicit indication maybe included in the DHCP > message when that is > >> > > the case.. > >> > > Note that the MN may request for HA info of a > specific MSP without > >> > > realizing that it is already connected to it. > >> > > > >> > > >> > Having DHCP indicate too much of what the mobile node should > >> > do with the information would probably lead into problems. > >> > Mobile nodes have to be able to deal with these things, with > >> > or without discovery, because they can have multiple interfaces. > >> > > >> > (I wouldn't mind if some additional clarifying text were > >> > added because of the above.) > >> > > >> > 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 Apr 17 04:27:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D2C3A6FBD; Thu, 17 Apr 2008 04:27: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 3A7313A6FF2 for ; Thu, 17 Apr 2008 04:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, ROUND_THE_WORLD_LOCAL=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80yzGRL6KIeA for ; Thu, 17 Apr 2008 04:27:03 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (rodin.i2r.a-star.edu.sg [192.122.139.27]) by core3.amsl.com (Postfix) with ESMTP id EC71E3A6A82 for ; Thu, 17 Apr 2008 04:27:02 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id DCE3B13B680; Thu, 17 Apr 2008 02:00:59 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id CE1DC13B672; Thu, 17 Apr 2008 02:00:59 +0800 (SGT) Received: from precision5570 ([192.168.137.53]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 19:26:48 +0800 Message-ID: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> From: "QIU Ying" To: "Suresh Krishnan" , "marcelo bagnulo" , "Julien Laganier" , "mext" Date: Thu, 17 Apr 2008 19:25:57 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 17 Apr 2008 11:26:48.0135 (UTC) FILETIME=[ECA06570:01C8A07D] Subject: [MEXT] update firewall 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, folks It seems it is time to update the firewall drafts. My suggestions is below: Regarding vendor draft: I agree with Henrik comments: the time out of 420 seconds (7 minutes) is to= o = long for the binging update signal processing. The pinholes for the mobilit= y = head type 1~6 (HoTI/HoT, CoTI/CoT, BU/BA) are no longer necessary when they = get the return messages (HoT, CoT, BA), respectively. So 30 seconds should = be enough. But as for the pinhole for data packets, it is necessary to = associate its lifetime to the ones of a binding cache entry. Hence, the = last sentence in section 4 could move to the end of section 5. Regarding admin draft: The section 4.2 and 6.3 are talking about IKE negotiation. It is the generi= c = security issue. So these sections could be removed from the document. Section 5.5 deals with the tunneled issue between 2 fixed IP addresses (HA = and CN). So it should be removed, too. There are some minor editor errors in the draft: In section 6.2, please change the sentence =93described in section 5.1=94 t= o = =93described in section 4.1=94 In Figure 1, please change =93Home Agent of A=94 to =93Home Agent=94. In figure 2, please change =93CN C=94 to =93CN=94. Regards Qiu Ying ------------ Institute For Infocomm Research - Disclaimer -------------This= email is confidential and may be privileged. If you are not the intended = recipient, please delete it and notify us immediately. Please do not copy o= r use it for any purpose, or disclose its contents to any other person. Tha= nk you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 05:39:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0CA28C0E0; Thu, 17 Apr 2008 05:39: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 EF2163A6B86 for ; Thu, 17 Apr 2008 05:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=1.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 34NRaOr7OGCy for ; Thu, 17 Apr 2008 05:39:01 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A74EF28C511 for ; Thu, 17 Apr 2008 05:38:59 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m3HCdV85003058; Thu, 17 Apr 2008 07:39:31 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 07:39:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 08:39:29 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0558CA35@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update firewall drafts Thread-Index: AcigfhO8EiswVUtzSHiLDIEJmh1OTwACLsIw References: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> From: "Suresh Krishnan" To: "QIU Ying" , "marcelo bagnulo" , "Julien Laganier" , "mext" X-OriginalArrivalTime: 17 Apr 2008 12:39:30.0989 (UTC) FILETIME=[151715D0:01C8A088] Subject: Re: [MEXT] update firewall 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 Qiu, I am already in the process of updating the drafts and I am just waiting for comments frm the co-authors before I submit a new revision. Please see comments inline. > -----Original Message----- > From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > Sent: April-17-08 7:26 AM > To: Suresh Krishnan; marcelo bagnulo; Julien Laganier; mext > Subject: update firewall drafts > > Hi, folks > > It seems it is time to update the firewall drafts. My > suggestions is below: > > Regarding vendor draft: > I agree with Henrik comments: the time out of 420 seconds (7 > minutes) is too long for the binging update signal > processing. The pinholes for the mobility head type 1~6 > (HoTI/HoT, CoTI/CoT, BU/BA) are no longer necessary when they > get the return messages (HoT, CoT, BA), respectively. So 30 > seconds should be enough. But as for the pinhole for data > packets, it is necessary to associate its lifetime to the > ones of a binding cache entry. Hence, the last sentence in > section 4 could move to the end of section 5. I have added a configurable interval for this pinhole. I have no issues setting different lifetimes for different messages as Henrik suggested. The issue is to agree on reasonable defaults. > > Regarding admin draft: > The section 4.2 and 6.3 are talking about IKE negotiation. It > is the generic security issue. So these sections could be > removed from the document. I am not sure about this. This is not a generic security issue . This IKE signaling is opened up explicitly for MIPv6 to work. I would personally prefer to keep this in the document, but I am willing to be convinced otherwise. > > Section 5.5 deals with the tunneled issue between 2 fixed IP > addresses (HA and CN). So it should be removed, too. I have removed this in the new revision. I have also removed section 4.3. Please check if this is OK with you. > > There are some minor editor errors in the draft: > In section 6.2, please change the sentence "described in > section 5.1" to "described in section 4.1" > In Figure 1, please change "Home Agent of A" to "Home Agent". > In figure 2, please change "CN C" to "CN". OK. Thanks Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 20:36:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79143A6A12; Thu, 17 Apr 2008 20:36:37 -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 43A593A6A12 for ; Thu, 17 Apr 2008 20:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.696 X-Spam-Level: ** X-Spam-Status: No, score=2.696 tagged_above=-999 required=5 tests=[ROUND_THE_WORLD_LOCAL=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUMW7g3rbWQ4 for ; Thu, 17 Apr 2008 20:36:35 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (rodin.i2r.a-star.edu.sg [192.122.139.27]) by core3.amsl.com (Postfix) with ESMTP id 043D43A67F3 for ; Thu, 17 Apr 2008 20:36:34 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6370013B676; Thu, 17 Apr 2008 18:09:55 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id 5491813B666; Thu, 17 Apr 2008 18:09:55 +0800 (SGT) Received: from precision5570 ([192.168.137.53]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 11:35:43 +0800 Message-ID: <011a01c8a105$2961e8d0$3589a8c0@precision5570> From: "QIU Ying" To: "Suresh Krishnan" , "marcelo bagnulo" , "Julien Laganier" , "mext" References: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> <6D19CA8D71C89C43A057926FE0D4ADAA0558CA35@ecamlmw720.eamcs.ericsson.se> Date: Fri, 18 Apr 2008 11:34:52 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 18 Apr 2008 03:35:43.0427 (UTC) FILETIME=[47F5F930:01C8A105] Subject: Re: [MEXT] update firewall 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, Suresh Thanks for your updating these drafts. Unfortunately, I have not got them in time :-( Please refer my responses inline. >----- Original Message ----- >From: "Suresh Krishnan" >Hi Qiu, > I am already in the process of updating the drafts and I am just >waiting for comments frm the co-authors before I submit a new revision. >Please see comments inline. >> -----Original Message----- >> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] >> >> Regarding vendor draft: >> I agree with Henrik comments: the time out of 420 seconds (7 >> minutes) is too long for the binging update signal >> processing. The pinholes for the mobility head type 1~6 >> (HoTI/HoT, CoTI/CoT, BU/BA) are no longer necessary when they >> get the return messages (HoT, CoT, BA), respectively. So 30 >> seconds should be enough. But as for the pinhole for data >> packets, it is necessary to associate its lifetime to the >> ones of a binding cache entry. Hence, the last sentence in >> section 4 could move to the end of section 5. >I have added a configurable interval for this pinhole. I have no issues >setting different lifetimes for different messages as Henrik suggested. >The issue is to agree on reasonable defaults. I noted that you introduce a parameter STATEFUL_PINHOLE_LIFETIME and I am sure that it should be employed to all dynamic pinholes. But we know the pinholes for the binding update signalling are just used one time, after passing HoTI/HoT, CoTI/CoT, BU/BA, these pinholes are not used anymore until next update (when the location and CoA might be changed). Meanwhile the pinholes for data packet should be open during the communication. Moreover, the more pinholes are opened, the weaker the firewall is. >> Regarding admin draft: >> The section 4.2 and 6.3 are talking about IKE negotiation. It >> is the generic security issue. So these sections could be >> removed from the document. > >I am not sure about this. This is not a generic security issue . This >IKE signaling is opened up explicitly for MIPv6 to work. I would >personally prefer to keep this in the document, but I am willing to be >convinced otherwise. The pattern the draft suggested is also suitable for the normal IPv6 scenarios which IKE is used. Of course, in MIP6 network, we can not ignore IKE issue. So, to be or not to be? >> Section 5.5 deals with the tunneled issue between 2 fixed IP >> addresses (HA and CN). So it should be removed, too. > >I have removed this in the new revision. I have also removed section >4.3. Please check if this is OK with you. That's fine for me. Regards Qiu Ying >> There are some minor editor errors in the draft: >> In section 6.2, please change the sentence "described in >> section 5.1" to "described in section 4.1" >> In Figure 1, please change "Home Agent of A" to "Home Agent". >> In figure 2, please change "CN C" to "CN". > >OK. > >Thanks >Suresh ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 22:19:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD4128C195; Thu, 17 Apr 2008 22:19: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 8DB2728C195 for ; Thu, 17 Apr 2008 22:19:48 -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 bkl21-3jpgk2 for ; Thu, 17 Apr 2008 22:19:47 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id ABB223A6B0F for ; Thu, 17 Apr 2008 22:19:47 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m3I5JiGv022759; Fri, 18 Apr 2008 00:19:45 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 00:19:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 01:19:43 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0558D22E@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <011a01c8a105$2961e8d0$3589a8c0@precision5570> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update firewall drafts Thread-Index: AcihBWntkh97ud4DSCatzauBenTbBwADeQlg References: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> <6D19CA8D71C89C43A057926FE0D4ADAA0558CA35@ecamlmw720.eamcs.ericsson.se> <011a01c8a105$2961e8d0$3589a8c0@precision5570> From: "Suresh Krishnan" To: "QIU Ying" , "marcelo bagnulo" , "Julien Laganier" , "mext" X-OriginalArrivalTime: 18 Apr 2008 05:19:44.0667 (UTC) FILETIME=[D0079EB0:01C8A113] Subject: Re: [MEXT] update firewall 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 Qiu, Thanks for your comments. I am removing the issues we agree on. > I noted that you introduce a parameter > STATEFUL_PINHOLE_LIFETIME and I am > sure that it should be employed to all dynamic pinholes. But > we know the > pinholes for the binding update signalling are just used one > time, after > passing HoTI/HoT, CoTI/CoT, BU/BA, these pinholes are not > used anymore until > next update (when the location and CoA might be changed). > Meanwhile the > pinholes for data packet should be open during the > communication. Moreover, > the more pinholes are opened, the weaker the firewall is. I can try to add text which mentions that the pinhole opened for the CoT, HoT and the BA must be closed after the expected messages pass through. The issue I see is that retransmissions due to loss will not get through. Let me know how you want to proceed with this issue. > > >> Regarding admin draft: > >> The section 4.2 and 6.3 are talking about IKE negotiation. It > >> is the generic security issue. So these sections could be > >> removed from the document. > > > >I am not sure about this. This is not a generic security issue . This > >IKE signaling is opened up explicitly for MIPv6 to work. I would > >personally prefer to keep this in the document, but I am > willing to be > >convinced otherwise. > > The pattern the draft suggested is also suitable for the normal IPv6 > scenarios which IKE is used. Of course, in MIP6 network, we > can not ignore > IKE issue. So, to be or not to be? I will leave this in there for now unless someone has a strong reason for this to be removed. Thanks Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 22:48:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328E73A6C36; Thu, 17 Apr 2008 22: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 B2EBB3A6988 for ; Thu, 17 Apr 2008 22:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, ROUND_THE_WORLD_LOCAL=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PfdivBJk1x7 for ; Thu, 17 Apr 2008 22:48:11 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (rodin.i2r.a-star.edu.sg [192.122.139.27]) by core3.amsl.com (Postfix) with ESMTP id 16A2F3A6C86 for ; Thu, 17 Apr 2008 22:48:10 -0700 (PDT) Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 48D6D13B683; Thu, 17 Apr 2008 20:21:31 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id 398C213B665; Thu, 17 Apr 2008 20:21:31 +0800 (SGT) Received: from precision5570 ([192.168.137.53]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 13:47:19 +0800 Message-ID: <016201c8a117$8ba27a20$3589a8c0@precision5570> From: "QIU Ying" To: "Suresh Krishnan" , "marcelo bagnulo" , "Julien Laganier" , "mext" References: <00de01c8a07d$ce6aefd0$3589a8c0@precision5570> <6D19CA8D71C89C43A057926FE0D4ADAA0558CA35@ecamlmw720.eamcs.ericsson.se> <011a01c8a105$2961e8d0$3589a8c0@precision5570> <6D19CA8D71C89C43A057926FE0D4ADAA0558D22E@ecamlmw720.eamcs.ericsson.se> Date: Fri, 18 Apr 2008 13:46:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 18 Apr 2008 05:47:19.0929 (UTC) FILETIME=[AAA48E90:01C8A117] Subject: Re: [MEXT] update firewall 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, Suresh >I can try to add text which mentions that the pinhole opened for the >CoT, HoT and the BA must be closed after the expected messages pass >through. The issue I see is that retransmissions due to loss will not >get through. Let me know how you want to proceed with this issue. My opinion is: if MN can not receive the return messages (HoT, CoT, BA) after timeout, it should resend initial messages (HoTI, CoTI and BU) and let firewall to open these pinholes again because only initiator (MN here) can know if the round signaling is finished. It is not reasonable to let firewall to check the statuses due to overhead. Regards QIu Ying ----- Original Message ----- From: "Suresh Krishnan" To: "QIU Ying" ; "marcelo bagnulo" ; "Julien Laganier" ; "mext" Sent: Friday, April 18, 2008 1:19 PM Subject: RE: update firewall drafts Hi Qiu, Thanks for your comments. I am removing the issues we agree on. > I noted that you introduce a parameter > STATEFUL_PINHOLE_LIFETIME and I am > sure that it should be employed to all dynamic pinholes. But > we know the > pinholes for the binding update signalling are just used one > time, after > passing HoTI/HoT, CoTI/CoT, BU/BA, these pinholes are not > used anymore until > next update (when the location and CoA might be changed). > Meanwhile the > pinholes for data packet should be open during the > communication. Moreover, > the more pinholes are opened, the weaker the firewall is. I can try to add text which mentions that the pinhole opened for the CoT, HoT and the BA must be closed after the expected messages pass through. The issue I see is that retransmissions due to loss will not get through. Let me know how you want to proceed with this issue. > > >> Regarding admin draft: > >> The section 4.2 and 6.3 are talking about IKE negotiation. It > >> is the generic security issue. So these sections could be > >> removed from the document. > > > >I am not sure about this. This is not a generic security issue . This > >IKE signaling is opened up explicitly for MIPv6 to work. I would > >personally prefer to keep this in the document, but I am > willing to be > >convinced otherwise. > > The pattern the draft suggested is also suitable for the normal IPv6 > scenarios which IKE is used. Of course, in MIP6 network, we > can not ignore > IKE issue. So, to be or not to be? I will leave this in there for now unless someone has a strong reason for this to be removed. Thanks Suresh ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Apr 17 23:29:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DE73A6953; Thu, 17 Apr 2008 23:29: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 039033A687B for ; Thu, 17 Apr 2008 23:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8byfjMbU0Y2 for ; Thu, 17 Apr 2008 23:29:19 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 83D253A68AB for ; Thu, 17 Apr 2008 23:29:19 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 2so256125ywt.49 for ; Thu, 17 Apr 2008 23:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:organization:mime-version:content-type; bh=HIvAg5rHWS8o8mYeK/y1BuQfGFy2jGL90sVzv9Y1Z1w=; b=Qa8jFoO1xQsy8qguLfHsZk6ZOaO7bN3/f+LGjVi81IeA6FYTgsbs3N4Wm1z3NGDwDzWb+Q0V/UPTEhZiW9NOSNtM/S3E0FH7gMRJ8Lc9Gq9tofQN6RgyoFbyIZ4xxXyIJZcqG7PwqnlwoeOJUmyJceNYUngffr2bPh9zEacrPJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:organization:mime-version:content-type; b=OD6HPrAExxnf/WXwOKcS1dIlBtEUs5pZcHTB3GRDVfO/+uMoty/tNezY3ZcSMzA2iAtDrIrcUy5WaJ5njTj5J45S4f+ogH7aHdsVFJz1eOVhdqreKzSRutx+frhjB6F9wFqWkRJYF6liqDWtYSpdw7hB/HRoD5yAlYnjbvpjj3k= Received: by 10.150.121.3 with SMTP id t3mr2986131ybc.227.1208500150418; Thu, 17 Apr 2008 23:29:10 -0700 (PDT) Received: from ryujibsd.gmail.com ( [61.200.198.68]) by mx.google.com with ESMTPS id 5sm3255438wrh.24.2008.04.17.23.29.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Apr 2008 23:29:08 -0700 (PDT) Date: Tue, 15 Apr 2008 23:07:22 +0000 Message-ID: From: Ryuji Wakikawa To: "George Tsirtsis" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) Organization: ToyotaITC/Keio Univ. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: mext@ietf.org Subject: Re: [MEXT] MCoA Update [pre07] 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 George, At Wed, 16 Apr 2008 10:19:56 +0100, George Tsirtsis wrote: > > Hi Ryuji, > > I think what you propose wrt de-registration BU with H-flag set, > works. I have a slight preference in viewing this as a registration > but my preference is based on semantics and I do not think it > technically impacts the solution. great to have agreement:-) > For this reason I say that we go with your proposal, so after fixing > the final set of minor comments I think you should publish the draft. > Time for a proper WGLC ...at least from my side :-) OK, I will work on your comments and will submit it to IETF unless there are more comments from the MEXT group. regards, ryuji > Regards > George > > On Wed, Apr 16, 2008 at 10:05 AM, Ryuji Wakikawa > wrote: > > Hi George, > > > > > > On 2008/04/16, at 18:00, George Tsirtsis wrote: > > > > > Hi Ryuji, > > > > > > Yes, most of my comments are now minor so, good job!. > > > > > > > Great! thanks. > > > > > > > > > The only issue that bothers me a little is whether the BU with H flag > > > set over the home link should be viewed as registration or > > > de-registration. I think either way works, but I need to think this > > > through just in case there is some implication that we do not see at > > > the moment. > > > > > > > OK, please find my comments inline. > > > > > > > > > > > See some comments inline. > > > > > > Regards > > > George > > > > > > 2008/4/16 Ryuji Wakikawa : > > > > > > > Hello George, > > > > > > > > Thanks for comments! > > > > > > > > It looks like your comments are more editorial one. > > > > Can I assume you mostly agree on the changes? > > > > I will revise the document quickly and post it again to MEXT. > > > > > > > > > > > > > > > > On 2008/04/15, at 21:29, George Tsirtsis wrote: > > > > > > > .. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1 2 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = TBD | Length | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > + + > > > > > : Link Layer address : > > > > > + + > > > > > +---------------------------------------------------------------+ > > > > > > > > > > Figure 6: BID Mobility Option > > > > > > > > > > > > > > > GT> Figure caption seems wrong. Also, has such option never been > > > > > defined for MIPv6 before? I see that PMIPv6 draft also defined the > > > > > same option. I would hope that only one such option is needed for all > > > > > flavors of MIPv6? > > > > > > > > > > > > > > > > > > Do you mean the interface identifier option of PMIP6? > > > > If that interface identifier is always LL address, we will reuse that > > > > option. > > > > Or we can overwrite the sub-option spec. to carry the LL address always > > for > > > > MCoA in this spec. > > > > I will discuss this with Sri. > > > > > > > > > > > > > > > > > > GT2> Yes, I think it would be nice to coordinate with Sri, but I am > > > not sure what you mean by "we can overwrite the sub-option spec...." > > > > > > > I mean the MCoA spec clearly states to carry only LL address in this > > option. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Sending Deregistration Binding Update] > > > > > > > > > > > > > > > o As soon as a mobile node returns home, it sends a de-registration > > > > > Binding Update to the home agent from the interface attached to > > > > > the home link. > > > > > > > > > > GT> I think throughout the description of this mode of operation the > > > > > MN sends a *registration* not a *de-registration*. In fact you should > > > > > add somewhere that "A BU with H flag set MUST have a non-zero > > > > > Lifetime" > > > > > > > > > > > > > > > > > > I think MN can use the zero lifetime and de-register the BU. > > > > MN continues setting the H flag for BUs to other interfaces attached to > > > > foreign link, > > > > because MN attached to both foreign and home link. > > > > > > > > MN sends BU from the interface attached to the home link just once. > > > > After that BU, MN sends BU with H flag set from the other interfaces > > while > > > > it is at home link. > > > > > > > > MN should not send BU from the home link multiple times.. > > > > That's why we said dregistration BU here. > > > > > > > > What do you think? > > > > > > > > > > > > > > GT2> Hmmm, I guess that could work too. Let's think about this a > > > minute. The way you are thinking about this, can the MN send a BU over > > > a foreign link with the H flag set, without having send the dereg BU > > > with H flag set first? > > > > > > > MN sends only one dereg-BU with H flag set and zero lifetime to HA from the > > home link. > > > > After that deregistration, MN sends BU with H flag set from the foreign > > link to HA. > > This tells HA that MN is still at the home link. > > Once MN leaves from the home link, MN unset the H flag in BU so that HA can > > detect the MN's leaving. > > > > > > > > > > > > > > > > > > o According to [RFC-3775], the mobile node MUST start responding to > > > > > Neighbor Solicitation for its home address right after it sends > > > > > > > > > > > > > > > > > > > > Wakikawa (Editor), et al. Expires October 17, 2008 [Page > > 22] > > > > > > > > > > Internet-Draft MCoA April > > 2008 > > > > > > > > > > > > > > > the deregistration Binding Update to the home agent. However, in > > > > > this specification, the mobile node MUST NOT respond to Neighbor > > > > > Solicitation before receiving a Binding Acknowledgement, since the > > > > > home agent may continue proxying for the home address. > > > > > > > > > > GT> the MN must not respond to NS messages before and *after* > > > > > receiving the BA, right? > > > > > > > > > > > > > > > > > > This isn't such clear. > > > > If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after > > the > > > > BA. > > > > Otherwise, MN should answer to NS. > > > > > > > > > > > > > > > > > > GT2> OK, some clarification maybe useful to indicate that what happens > > > after the BA depends on how the HA responds i.e., the BA's status > > > field. > > > > > > > > > Right. I will update this. > > > > regards, > > ryuji > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Apr 18 05:51:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9847528C225; Fri, 18 Apr 2008 05:51: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 8D76F28C213 for ; Fri, 18 Apr 2008 05:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 EhaENJCltLlZ for ; Fri, 18 Apr 2008 05:51:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DCA1928C27B for ; Fri, 18 Apr 2008 05:50:53 -0700 (PDT) Received: from IBM52A5038A94F ([121.136.51.154]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Jmq343X4w-0005gv; Fri, 18 Apr 2008 08:50:55 -0400 From: "Alper Yegin" To: "'George Tsirtsis'" , "'Jari Arkko'" Date: Fri, 18 Apr 2008 15:50:30 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-index: AcigZ/mdlYkOhVeIRHSoZGPhOC4ViQAxPhvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-Id: <0MKp8S-1Jmq343X4w-0005gv@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18Z+WSzc/snq1W6ng3vDwH4jDg4pYEV2Zcl3zq mEnUU0IEIDJtUYZcz39sCKicaLgmjKocjyFyZIhShWzE3ziLE7 C3NN665O7ToPfi9wKghUA== Cc: =?UTF-8?Q?'Alfred_=EF=BF=BD'?= , mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 more thing. Do you think that the relationship between the HA > information received and the link on which the MN is attached is > always clear? Would it be useful to say something about detecting > whether the HA information returned corresponds to an HA "on-link" wrt > to the requesting MN? e.g., the MN can compare the HNP received from > DHCP with the prefixes in the RA received on link, or instead an > explicit indication maybe included in the DHCP message when that is > the case.. This requires the DHCP server to be aware of the prefix(es) advertised on the access link. And it may not be. I think it is best if we leave that to the MN to figure out, as usual. Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Apr 19 00:13:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6EC3A6A27; Sat, 19 Apr 2008 00:13: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 2FE063A6A27 for ; Sat, 19 Apr 2008 00:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap88QW3Q+53G for ; Sat, 19 Apr 2008 00:13:08 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 782CB3A67D6 for ; Sat, 19 Apr 2008 00:13:08 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so769722wfa.31 for ; Sat, 19 Apr 2008 00:13:11 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=57ytG6Pue6AD2TeA64haHwhY5OfRCaXMt0Ln8aUWO3w=; b=mBb/aT9dx1PGsrHQmu9qFvekFoeR81gQqrNqNsjNN5zWuh2k9aoTonk8jp1bAyNOtcN19HFKWRRoU6q20eeTV+VCPgcXvM2RS1yGcsOCWm3d8RjoBziuADiah4RfD+HTawPqxHzPJl4au3gO/VSdeVdfkEgZ/0RlAIRfp6IB6do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t4Z/wcSQjnJ2YGHDjA7SbKW9lYqCfVBSKdmHJtphrZAV1jfd5voldhiNJhTCC3tUPLQUWGpB3i3NxVhwKkcUMU2MS1rKoyUW1w4hyE7GSZfDRy5zwDa4zuVHEpb5HRgWX1RUGZ7VsTHxrXJOg/6QfzOe3ofcEIVOzk+Q8kIIdsk= Received: by 10.142.71.3 with SMTP id t3mr922689wfa.244.1208589191449; Sat, 19 Apr 2008 00:13:11 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Sat, 19 Apr 2008 00:13:11 -0700 (PDT) Message-ID: Date: Sat, 19 Apr 2008 08:13:11 +0100 From: "George Tsirtsis" To: "Alper Yegin" , "Jari Arkko" , "=?UTF-8?Q?Alfred_=EF=BF=BD?=" , mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13i 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 do not think the text implies that the DHCP server knows something speciific about the link. If the HNP provided by the DHCP server, matches what the MN gets in the RA onlink, then the MN knows. George On 4/18/08, Alper Yegin wrote: > > One more thing. Do you think that the relationship between the HA > > information received and the link on which the MN is attached is > > always clear? Would it be useful to say something about detecting > > whether the HA information returned corresponds to an HA "on-link" wrt > > to the requesting MN? e.g., the MN can compare the HNP received from > > DHCP with the prefixes in the RA received on link, or instead an > > explicit indication maybe included in the DHCP message when that is > > the case.. > > > This requires the DHCP server to be aware of the prefix(es) advertised on > the access link. And it may not be. > > I think it is best if we leave that to the MN to figure out, as usual. > > Alper > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Apr 20 01:55:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A423A6BBC; Sun, 20 Apr 2008 01:55: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 389EC28C0FE for ; Sun, 20 Apr 2008 01:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 hMzGw0qewvWm for ; Sun, 20 Apr 2008 01:55:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5D7793A6BBC for ; Sun, 20 Apr 2008 01:55:36 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (125.44.217.87.dynamic.jazztel.es [87.217.44.125])by smtp01.uc3m.es (Postfix) with ESMTP id 0ACEE59EDF4; Sun, 20 Apr 2008 10:55:40 +0200 (CEST) Message-ID: <480B050B.3050808@it.uc3m.es> Date: Sun, 20 Apr 2008 10:55:39 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext , Sri Gundavelli , Julien Laganier References: <47FA050B.2010001@it.uc3m.es> In-Reply-To: <47FA050B.2010001@it.uc3m.es> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.4405 TC:1F TRN:16 TV:5.5.1026(15860.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) Subject: [MEXT] Reminder WGLC on draft-ietf-mext-nemo-mib-00 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 Just to remind you that WGLC ends tomorrow Regards, marcelo marcelo bagnulo escribi=F3: > Hi, > > We are now starting the WGLC for draft-ietf-mext-nemo-mib-00, which will = > close on april 21st 2008. > Please, send comments to the list before that date. > > For your convenience, the document can be found: > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-00.txt > > Regards, Julien and 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 From mext-bounces@ietf.org Sun Apr 20 18:54:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E9C3A6774; Sun, 20 Apr 2008 18:54: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 26B5B3A6ADF for ; Sun, 20 Apr 2008 18:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OHGSCrRBGUg for ; Sun, 20 Apr 2008 18:54:19 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 1AF823A6ED9 for ; Sun, 20 Apr 2008 18:52:22 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZN00F54JNE95@mailout2.samsung.com> for mext@ietf.org; Mon, 21 Apr 2008 10:47:38 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZN0007JJNEZY@ms5.samsung.com> for mext@ietf.org; Mon, 21 Apr 2008 10:47:38 +0900 (KST) Content-return: prohibited Date: Mon, 21 Apr 2008 01:47:38 +0000 (GMT) From: Heejin Jang To: Jari Arkko , tsirtsis@googlemail.com, mext@ietf.org, domagoj.premec@siemens.com Message-id: <25262965.37771208742458248.JavaMail.weblogic@epml02> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080421014220998@heejin.jang X-MTR: 20080421014220998@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: =?windows-1252?Q?=3F=3F=3F=3F?= , =?windows-1252?Q?Alfred_=3F?= Subject: [MEXT] Changes in hiopt-15 (from hiopt-14) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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 and folks. I've posted draft-ietf-mip6-hiopt-15 and changes from -14 are; 1) Afred's comments were reflected. 2) About the description for the home network prefix, I revised the texts as George proposed and Jari agreed. That is, " When the Sub-opt-code is set to 2, the Home Network Parameter field MUST include the 8-bit Prefix-Len followed by the 128-bit IPv6 Home Network Prefix. The Prefix-Len information indicates the number of leading bits in the IPv6 Home Network Prefix that are valid. The prefix information is provided so that the mobile node can perform dynamic home agent discovery as defined in [RFC3775]. The information may also be used to allow the mobile node to determine whether the home agent information received via DHCPv6 corresponds to a home agent on-link or not." - All the best Heejin > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, April 18, 2008 4:43 AM > To: Alfred > Cc: heejin.jang@samsung.com; a.yegin@partner.samsung.com; > kchowdhury@starentnetworks.com; jinchoe@samsung.com > Subject: Re: draft-ietf-mip6-hiopt-14 > > I think we still have time to fix this. On list discussion we > are converging on a change (you should adopt that, Heejin). > And I'm waiting for more people to say "OK" from the WG > before proceeding. > > I see a -15 in the near future :-) > > Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 21 00:16:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052243A6EE0; Mon, 21 Apr 2008 00:16: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 8D1293A6EF6 for ; Mon, 21 Apr 2008 00:16: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=[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 SEOk1t4OTr4S for ; Mon, 21 Apr 2008 00:16:30 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AFE5A3A6DBF for ; Mon, 21 Apr 2008 00:16:30 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A92FB198808 for ; Mon, 21 Apr 2008 10:16:35 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 632681987A5 for ; Mon, 21 Apr 2008 10:16:35 +0300 (EEST) Message-ID: <480C3F56.9090901@piuha.net> Date: Mon, 21 Apr 2008 10:16:38 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: mext@ietf.org References: <0MKp8S-1Jmq343X4w-0005gv@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Jmq343X4w-0005gv@mrelay.perfora.net> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 The last edits are in -15 now. Any additional people who want to comment on this before its approved? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 21 02:22:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19FB3A67AD; Mon, 21 Apr 2008 02:22: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 86A813A67AD for ; Mon, 21 Apr 2008 02:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 hwFIid7YHNIC for ; Mon, 21 Apr 2008 02:21:59 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 42D0D28C0D6 for ; Mon, 21 Apr 2008 02:21:58 -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 1JnsDp-0005ZO-V2; Mon, 21 Apr 2008 19:22:02 +1000 Message-Id: <4CD8A8D3-8481-4652-81C3-0F1AA617E871@elevatemobile.com> From: Hesham Soliman To: George Tsirtsis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 19:21:54 +1000 References: X-Mailer: Apple Mail (2.919.2) Cc: mext Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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, Does anyone have any comments on George's proposal below? Please speak now because I want to update the draft and submit ASAP. Hesham On 17/04/2008, at 6:21 PM, George Tsirtsis wrote: > Hi all, > > Here is the clarification text for IKEv2/IPSEC and DSMIPv6 > interactions. In particular, the text clarifies the behavior when the > MN is connected to an IPv4 network, which RFC4877 does not cover. > > Thanks to Pasi for his review and his help with defining the required > SPDs; also thanks to Wassim and Hesham for their review. > Hesham will fold the following text appropriately into the DSMIPv6 > draft following a hopefully quick review from the group. > > Best Regards > George > P.S.: I will have intermittent connectivity Friday-Sunday. > > > ----------------------------------------------------------------------------------------------------------------------- > DSMIPv6 defines a number of possible data encapsulations depending on > the MN's connectivity and MN's and HA's configuration. These > encapsulations and the signaling required to establish them, are > straight forward when the MN is connected to an IPv6 capable network. > Some clarification is, however, needed for IKEv2/IPSEC operations when > the MN is connected to an IPv4-only network. > > > 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 > > RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 includes > information about how IKEv2 runs over IPv4/UDP for NAT Traversal. A > DSMIPv6 MN connected to an IPv4-only network then, needs to follow > the procedures described below. > > To establish an SA for the protection of BU/BA messages, the DSMIPv6 > MN and the HA SHOULD implement the following IKEv2 compatible > procedure: > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (500, 500) HDR, SAi1, KEi, Ni > NAT-D, NAT-D --> > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP(500,X) HDR, SAr1, KEr, Nr, > [CERTREQ] > NAT-D, NAT-D > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > --> > > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP (4500,Y) > HDR*#, SK > {IDr, [CERT,] AUTH, SAr2, TSi, > TSr} > > > The SPDs are as shown in RFC 4877 Section 7.2.1 > > mobile node SPD-S: > - IF local_address = home_address_1 & > remote_address = home_agent_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BAck > Then use SA ESP transport mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address = home_agent_1 & > remote_address = home_address_1 & > proto = MH & local_mh_type = BAck & remote_mh_type = BU > Then use SA ESP transport mode > > where home_address_1 is the MN's registered IPv6 home address and > home_agent_1 is the IP address of the home agent > > The above should result in BU/BA messages with the following > encapsulations: > Binding update received by the home agent: > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (sport=X, dport=DSMIPv6) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > > At the home agent, following UDP de-tunneling the Binding Update is > delivered to the IPSEC module as shown below: > > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > The Binding Update following IPSEC processing is delivered to the > DSMIPv6 home agent module as follows: > > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > > The Binding Acknowledgement sent by the home agent module to the IPSEC > module is as follows: > > IPv6 header (src=HAADDR, dst=V6HOA) > Mobility Header > BA ([IPv4 ACK], NAT DET) > (+ other as needed) > > The Binding Acknowledgement send by the HA to the MN is as follows: > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > UDP Header (sport=DSMIPv6, dport=Y) > IPv6 header (src=HAADDR, dst=V6HOA) > ESP Header in Transport Mode > Mobility Header > BA ([IPv4 ACK], NAT DET) > > > > 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 > > To secure data traffic when the MN is located on an IPv4 only network, > the MN MUST establish a child_SA for that purpose. The procedure is as > follows: > > Mobile Node Home Agent > ----------- ---------- > UDP (4500,4500) HDR, SK > {[N], SA, Ni, [KEi],[TSi, TSr]} --> > > <-- UDP (4500,Y) > HDR, SK > {SA, Nr, [KEr], [TSi, TSr]} > > > If no NAT is detected, the encapsulation used will be: > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > If NAT is detected, the encapsulation used will be > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > UDP (sport=X, dport=4500) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where v4CoA may be the external IPv4 address of the NAT, IP is either > IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA > > The SPD for data decryption whether NAT is detected or not is set as > follows. Note that this rule is designed to match all data from the MN > to nodes other than the HA. This is done so that this rule does not > overlap with the earlier rule securing BU/BA signaling between the MN > and the HA. > > Mobile Node SPD-S: > - IF local_address = home_address & > remote_address != home_agent & > proto=any > Then use SA ESP tunnel mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address != home_agent & > remote_address = home_address & > proto = any > Then use SA ESP tunnel mode > > where home_address is the MN's registered IPv6 or IPv4 home address > and home_agent is the IPv6 or the IPv4 address of the home agent. > _______________________________________________ > 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 Apr 21 02:33:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F20728C10C; Mon, 21 Apr 2008 02:33: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 2952A3A6D1A for ; Mon, 21 Apr 2008 02:33:41 -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 UHbw7rzWhkqS for ; Mon, 21 Apr 2008 02:33:40 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 0CD7E3A6851 for ; Mon, 21 Apr 2008 02:33:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1208770425!22879420!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 17327 invoked from network); 21 Apr 2008 09:33:45 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-119.messagelabs.com with SMTP; 21 Apr 2008 09:33:45 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m3L9XZCJ004192; Mon, 21 Apr 2008 02:33:40 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m3L9XYeH026910; Mon, 21 Apr 2008 04:33:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m3L9XXdC026899; Mon, 21 Apr 2008 04:33:33 -0500 (CDT) Message-ID: <480C5F6C.8090706@gmail.com> Date: Mon, 21 Apr 2008 11:33:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jari Arkko References: <0MKp8S-1Jmq343X4w-0005gv@mrelay.perfora.net> <480C3F56.9090901@piuha.net> In-Reply-To: <480C3F56.9090901@piuha.net> X-Antivirus: avast! (VPS 080420-0, 20/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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: > The last edits are in -15 now. Any additional people who want to > comment on this before its approved? Hi Jari, I am not familiar with the advancement of this document and the recent discussion. I have just quickly skimmed through it. I am surprised by the intention to pursue the document and get it approved. Because I find a few incoherencies. It may be I'm not enough familiar with the document, if so my message can be discarded. For example: > 3. DHCP options for HA Dynamic Discovery > > This section introduces new DHCP options and their sub-options which > are used for dynamic discovery of the home agent's IPv6 address, IPv6 > home network prefix, So the home network prefix is discovered, presumably by MN. > 3.1. Home Network Information Option > > This option is proposed to allow the exchange of home network > information between the mobile node (DHCP client) and the DHCP > server. It is used to indicate the target home network requested by > the mobile node to the DHCP server in the Information-request > message. In the Reply message, it conveys the home network > information assigned by the DHCP server to the mobile node. The MN indicates the home network information to DHCP Server, and then the DHCP Server indicates back to MN the home network information. Is this information the same? Can it change? If the MN knows the home network information then why does it need the DHCP Server to tell it back the home network information? Is the home network prefix part of the home network information? > 4.3. DHCP Server Behavior > > When the server receives a Relay-forward message, it may include the > MIP6 Relay Agent option in case there was home information available > for the mobile node at the relay. DHCP Server includes the MIP6 Relay Agent option into what? Overall comments about some paragraphs: > New DHCP options are defined which allow a mobile node to request the > home agent IP address, FQDN, or home network prefix and obtain it > via the DHCP response. If this is a MN, then it could be a MR, and MR may need to learn Mobile Network Prefixes. Is it necessary to learn Mobile Network Prefixes as well? Just a question. > A mobile node can indicate its home network identity when roaming to > a visited network in order to obtain the MIP6 bootstrap parameters > from the home network. As an example, the visited network may > determine the home network of the mobile node based on the realm > portion of the NAI (Network Access Identifier) [RFC4282] used in > access authentication. This is not a good example, it is not a good idea to decide the identity of a subnet based on the realm part of NAI. There is no relationship about domain names and subnet addresses, and there shouldn't be any. If one needs to identify a subnet then it's by its IP subnet address, not by its fqdn (there's no fqdn-subnet relationship). I haven't read further. 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 Apr 21 03:59:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5263A6F1A; Mon, 21 Apr 2008 03:59: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 D11523A6DB6 for ; Mon, 21 Apr 2008 03:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 7isgpLRYc1Yz for ; Mon, 21 Apr 2008 03:59:40 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 52DE43A6CE5 for ; Mon, 21 Apr 2008 03:59:36 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m3LAxK8B004386; Mon, 21 Apr 2008 12:59:22 +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 m3LAxKKa010113; Mon, 21 Apr 2008 12:59:20 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:59:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 12:59:18 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803BD7F4C@zagh223a.ww300.siemens.net> In-Reply-To: <4CD8A8D3-8481-4652-81C3-0F1AA617E871@elevatemobile.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions Thread-Index: AcijkUCtcowb4trCT9O7JFO3vCeKKwADGNgA References: <4CD8A8D3-8481-4652-81C3-0F1AA617E871@elevatemobile.com> From: "Premec, Domagoj" To: "Hesham Soliman" , "George Tsirtsis" X-OriginalArrivalTime: 21 Apr 2008 10:59:18.0561 (UTC) FILETIME=[BF0E6110:01C8A39E] 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::080421125920-265B2BB0-6C8D7A1A/0-0/0-15 X-purgate-size: 8420/0 Cc: mext Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 > IP (source_addr=HoA, set_addr=CNAddr) s/set_addr/dest_addr/ domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: 21. travanj 2008 11:22 > To: George Tsirtsis > Cc: mext > Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > Folks, > > Does anyone have any comments on George's proposal below? > Please speak now because I want to update the draft and submit ASAP. > > Hesham > > On 17/04/2008, at 6:21 PM, George Tsirtsis wrote: > > > Hi all, > > > > Here is the clarification text for IKEv2/IPSEC and DSMIPv6 > > interactions. In particular, the text clarifies the > behavior when the > > MN is connected to an IPv4 network, which RFC4877 does not cover. > > > > Thanks to Pasi for his review and his help with defining > the required > > SPDs; also thanks to Wassim and Hesham for their review. > > Hesham will fold the following text appropriately into the DSMIPv6 > > draft following a hopefully quick review from the group. > > > > Best Regards > > George > > P.S.: I will have intermittent connectivity Friday-Sunday. > > > > > > > ---------------------------------------------------------------------- > > ------------------------------------------------- > > DSMIPv6 defines a number of possible data encapsulations > depending on > > the MN's connectivity and MN's and HA's configuration. These > > encapsulations and the signaling required to establish them, are > > straight forward when the MN is connected to an IPv6 > capable network. > > Some clarification is, however, needed for IKEv2/IPSEC > operations when > > the MN is connected to an IPv4-only network. > > > > > > 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 > > > > RFC4877 defines how IKEv2 is used for Mobile IPv6 and > RFC4306 includes > > information about how IKEv2 runs over IPv4/UDP for NAT Traversal. A > > DSMIPv6 MN connected to an IPv4-only network then, needs to follow > > the procedures described below. > > > > To establish an SA for the protection of BU/BA messages, > the DSMIPv6 > > MN and the HA SHOULD implement the following IKEv2 compatible > > procedure: > > > > Mobile Node Home Agent > > ----------- ---------- > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > > UDP (500, 500) HDR, SAi1, KEi, Ni > > NAT-D, NAT-D --> > > <-- IPv4(source_addr=HAADDR, > > dest_addr=V4ADDR) > > UDP(500,X) HDR, SAr1, KEr, Nr, > > [CERTREQ] > > NAT-D, NAT-D > > > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > > UDP (4500,4500) HDR, SK > > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > > --> > > > > <-- IPv4(source_addr=HAADDR, > > dest_addr=V4ADDR) > > UDP (4500,Y) Marker> HDR*#, > > SK > > {IDr, [CERT,] AUTH, > SAr2, TSi, > > TSr} > > > > > > The SPDs are as shown in RFC 4877 Section 7.2.1 > > > > mobile node SPD-S: > > - IF local_address = home_address_1 & > > remote_address = home_agent_1 & > > proto = MH & local_mh_type = BU & remote_mh_type = BAck > > Then use SA ESP transport mode > > Initiate using IDi = user_1 to address home_agent_1 > > > > home agent SPD-S: > > - IF local_address = home_agent_1 & > > remote_address = home_address_1 & > > proto = MH & local_mh_type = BAck & remote_mh_type = BU > > Then use SA ESP transport mode > > > > where home_address_1 is the MN's registered IPv6 home address and > > home_agent_1 is the IP address of the home agent > > > > The above should result in BU/BA messages with the following > > encapsulations: > > Binding update received by the home agent: > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > > UDP header (sport=X, dport=DSMIPv6) > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > > > At the home agent, following UDP de-tunneling the Binding Update is > > delivered to the IPSEC module as shown below: > > > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > The Binding Update following IPSEC processing is delivered to the > > DSMIPv6 home agent module as follows: > > > > IPv6 header (src=V6HOA, dst=HAADDR) > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > > > The Binding Acknowledgement sent by the home agent module > to the IPSEC > > module is as follows: > > > > IPv6 header (src=HAADDR, dst=V6HOA) > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > (+ other as needed) > > > > The Binding Acknowledgement send by the HA to the MN is as follows: > > > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > > UDP Header (sport=DSMIPv6, dport=Y) > > IPv6 header (src=HAADDR, dst=V6HOA) > > ESP Header in Transport Mode > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > > > > > > > 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 > > > > To secure data traffic when the MN is located on an IPv4 > only network, > > the MN MUST establish a child_SA for that purpose. The > procedure is as > > follows: > > > > Mobile Node Home Agent > > ----------- ---------- > > UDP (4500,4500) HDR, SK > > {[N], SA, Ni, [KEi],[TSi, TSr]} --> > > > > <-- UDP (4500,Y) > > HDR, SK > > {SA, Nr, [KEr], [TSi, TSr]} > > > > > > If no NAT is detected, the encapsulation used will be: > > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > > > If NAT is detected, the encapsulation used will be > > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > > UDP (sport=X, dport=4500) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where v4CoA may be the external IPv4 address of the NAT, IP > is either > > IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA > > > > The SPD for data decryption whether NAT is detected or not is set as > > follows. Note that this rule is designed to match all data > from the MN > > to nodes other than the HA. This is done so that this rule does not > > overlap with the earlier rule securing BU/BA signaling > between the MN > > and the HA. > > > > Mobile Node SPD-S: > > - IF local_address = home_address & > > remote_address != home_agent & > > proto=any > > Then use SA ESP tunnel mode > > Initiate using IDi = user_1 to address home_agent_1 > > > > home agent SPD-S: > > - IF local_address != home_agent & > > remote_address = home_address & > > proto = any > > Then use SA ESP tunnel mode > > > > where home_address is the MN's registered IPv6 or IPv4 home address > > and home_agent is the IPv6 or the IPv4 address of the home agent. > > _______________________________________________ > > 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 Apr 21 05:50:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE6E28C292; Mon, 21 Apr 2008 05:50: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 631283A6F25 for ; Mon, 21 Apr 2008 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 fYd8R-ut9Dn3 for ; Mon, 21 Apr 2008 05:50:43 -0700 (PDT) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 3D49328C292 for ; Mon, 21 Apr 2008 05:50:43 -0700 (PDT) X-AuditID: c26e2f18-000018ec0000050c-94-480c8dad58b0 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 15:50:53 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 14:50:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 14:50:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions Thread-Index: AcigZCObJJNDyEI0SkO2/+ROC6fNXADSN57g References: From: To: , X-OriginalArrivalTime: 21 Apr 2008 12:50:48.0286 (UTC) FILETIME=[527167E0:01C8A3AE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 A few comments. As a result of section 1's IKE exchanges, the NAT box has the mappings new new src dst src dst ---- ---- ---- ---- UDP 500 500 maps to UDP X 500 UDP 4500 4500 maps to UDP Y 4500 The following BU and BA packets will then create the mapping UDP DSMIP DSMIP maps to UDP Z DSMIP calling for a change in the UDP headers of the BU and BA packets. For section 1's IKE exchanges, the following details might be considered * Use N(USE_TRANSPORT_MODE) * Not clear what *# means in HDR*# * Have a statement, that the transport CHILD_SA might already have been made in the previous foreign network (v4 or v6), or might have been made proactively in the home network. Thus the illustrated exchange is only for the case of a full re-negotiation. * Although also used in RFC 4877, the "local_mh_type = BU & remote_mh_type = BAck" cannot be true, as as only one MH type is supplied in a BU or BA. Probably not worth to effort to change. For section 2's IKE exchange, this exchange could also have been made proactively, and then only require installation when moving to the foreign IPv4 network. Thus the illustrated exchange is only for the case of re-negotiation. Christian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: 17. april 2008 10:22 > To: mext > Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > Hi all, > > Here is the clarification text for IKEv2/IPSEC and DSMIPv6 > interactions. In particular, the text clarifies the behavior > when the MN is connected to an IPv4 network, which RFC4877 > does not cover. > > Thanks to Pasi for his review and his help with defining the > required SPDs; also thanks to Wassim and Hesham for their review. > Hesham will fold the following text appropriately into the > DSMIPv6 draft following a hopefully quick review from the group. > > Best Regards > George > P.S.: I will have intermittent connectivity Friday-Sunday. > > > -------------------------------------------------------------- > --------------------------------------------------------- > DSMIPv6 defines a number of possible data encapsulations > depending on the MN's connectivity and MN's and HA's > configuration. These encapsulations and the signaling > required to establish them, are straight forward when the MN > is connected to an IPv6 capable network. > Some clarification is, however, needed for IKEv2/IPSEC > operations when the MN is connected to an IPv4-only network. > > > 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 > > RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 > includes information about how IKEv2 runs over IPv4/UDP for > NAT Traversal. A > DSMIPv6 MN connected to an IPv4-only network then, needs to > follow the procedures described below. > > To establish an SA for the protection of BU/BA messages, the > DSMIPv6 MN and the HA SHOULD implement the following IKEv2 compatible > procedure: > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (500, 500) HDR, SAi1, KEi, Ni > NAT-D, NAT-D --> > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP(500,X) HDR, SAr1, > KEr, Nr, [CERTREQ] > NAT-D, NAT-D > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > --> > > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP (4500,Y) Marker> HDR*#, SK > {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > > The SPDs are as shown in RFC 4877 Section 7.2.1 > > mobile node SPD-S: > - IF local_address = home_address_1 & > remote_address = home_agent_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BAck > Then use SA ESP transport mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address = home_agent_1 & > remote_address = home_address_1 & > proto = MH & local_mh_type = BAck & remote_mh_type = BU > Then use SA ESP transport mode > > where home_address_1 is the MN's registered IPv6 home address and > home_agent_1 is the IP address of the home agent > > The above should result in BU/BA messages with the following > encapsulations: > Binding update received by the home agent: > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (sport=X, dport=DSMIPv6) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > > At the home agent, following UDP de-tunneling the Binding > Update is delivered to the IPSEC module as shown below: > > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > The Binding Update following IPSEC processing is delivered to the > DSMIPv6 home agent module as follows: > > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) > > > The Binding Acknowledgement sent by the home agent module to > the IPSEC module is as follows: > > IPv6 header (src=HAADDR, dst=V6HOA) > Mobility Header > BA ([IPv4 ACK], NAT DET) > (+ other as needed) > > The Binding Acknowledgement send by the HA to the MN is as follows: > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > UDP Header (sport=DSMIPv6, dport=Y) > IPv6 header (src=HAADDR, dst=V6HOA) > ESP Header in Transport Mode > Mobility Header > BA ([IPv4 ACK], NAT DET) > > > > 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 > > To secure data traffic when the MN is located on an IPv4 only > network, the MN MUST establish a child_SA for that purpose. > The procedure is as > follows: > > Mobile Node Home Agent > ----------- ---------- > UDP (4500,4500) HDR, SK > {[N], SA, Ni, [KEi],[TSi, TSr]} --> > > <-- UDP (4500,Y) Marker> HDR, SK > {SA, Nr, [KEr], [TSi, TSr]} > > > If no NAT is detected, the encapsulation used will be: > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > If NAT is detected, the encapsulation used will be > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > UDP (sport=X, dport=4500) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where v4CoA may be the external IPv4 address of the NAT, IP is either > IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA > > The SPD for data decryption whether NAT is detected or not is > set as follows. Note that this rule is designed to match all > data from the MN to nodes other than the HA. This is done so > that this rule does not overlap with the earlier rule > securing BU/BA signaling between the MN and the HA. > > Mobile Node SPD-S: > - IF local_address = home_address & > remote_address != home_agent & > proto=any > Then use SA ESP tunnel mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address != home_agent & > remote_address = home_address & > proto = any > Then use SA ESP tunnel mode > > where home_address is the MN's registered IPv6 or IPv4 home > address and home_agent is the IPv6 or the IPv4 address of the > home agent. > _______________________________________________ > 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 Apr 21 06:05:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E703A6A47; Mon, 21 Apr 2008 06:05: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 A8B3828C23A for ; Mon, 21 Apr 2008 06:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 i6yO4lrKq-Kc for ; Mon, 21 Apr 2008 06:04:59 -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 2793A3A67CC for ; Mon, 21 Apr 2008 06:04:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 2so900328ywt.49 for ; Mon, 21 Apr 2008 06:04: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BDlWKCDLucAUxnlmHx1iQP/Ii7Dpy63RNdWvDKYNEC0=; b=RtK2aaS2Abs9aXNSxdQLZn3Xev/yWQno6zl62EIzc02LBOe5OMagI6rgpK6iTNTsdPHEBq/dGw+BNgK8K96fGwtf66uMnebq4k54zh7ZslWVJz+FzODFkkbMd6CCq2te50KkhWQzNl7itWTanUdOEp+MNkeuKeR6wht3Yjoeurw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=iOqijQL6trKhik0tR/pCRc8IxTZCjtlUtOJzv2iE3ZqaYrO9vHaqL+ud34PJ0Pai5zwQkOyuSUrhQRRgNDwGezeGrs5cXjEAYySJEW/F/YWtarxbl9Jd/XbEam2QbXk7HvzSDllPEC1+Z86KrBYhMLEDp8XGW78v1/BDN5Of2w0= Received: by 10.143.159.11 with SMTP id l11mr1687769wfo.186.1208783097183; Mon, 21 Apr 2008 06:04:57 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Mon, 21 Apr 2008 06:04:57 -0700 (PDT) Message-ID: Date: Mon, 21 Apr 2008 14:04:57 +0100 From: "George Tsirtsis" To: Christian.Kaas-Petersen@tietoenator.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 Christian, Thanks for your comments, see inline... On Mon, Apr 21, 2008 at 1:50 PM, wrote: > A few comments. > > As a result of section 1's IKE exchanges, the NAT box has the mappings > > new new > src dst src dst > ---- ---- ---- ---- > UDP 500 500 maps to UDP X 500 > UDP 4500 4500 maps to UDP Y 4500 > > The following BU and BA packets will then create the mapping > > UDP DSMIP DSMIP maps to UDP Z DSMIP > > calling for a change in the UDP headers of the BU and BA packets. > GT> It is not clear to me if the above is an observation or whether you are suggesting something specific. I think the text already shows all this and the fact that the UDP header changes (if NAT exists) does not affect the IKEv2 SA for the BU/BA. > For section 1's IKE exchanges, the following details might be considered > > * Use N(USE_TRANSPORT_MODE) GT> Use that where? the packet formats already indicate ESP Transport mode. > * Not clear what *# means in HDR*# GT> The notation is used in RFC3947 to indicate a modified header and I failed to remove it from one place as I copy/pasted text around, so Hesham should remove the "*#". > * Have a statement, that the transport CHILD_SA might already have > been made in the previous foreign network (v4 or v6), or might > have been made proactively in the home network. Thus the > illustrated exchange is only for the case of a full re-negotiation. GT> I think you are right, this is worth adding. > * Although also used in RFC 4877, the > "local_mh_type = BU & remote_mh_type = BAck" cannot be true, as > as only one MH type is supplied in a BU or BA. Probably not > worth to effort to change. > > For section 2's IKE exchange, this exchange could also have been made > proactively, and then only require installation when moving to the > foreign IPv4 network. Thus the illustrated exchange is only for the > case of re-negotiation. > GT> Again, I agree. Thanks George > Christian > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > Behalf Of George Tsirtsis > > Sent: 17. april 2008 10:22 > > To: mext > > Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > > > Hi all, > > > > Here is the clarification text for IKEv2/IPSEC and DSMIPv6 > > interactions. In particular, the text clarifies the behavior > > when the MN is connected to an IPv4 network, which RFC4877 > > does not cover. > > > > Thanks to Pasi for his review and his help with defining the > > required SPDs; also thanks to Wassim and Hesham for their review. > > Hesham will fold the following text appropriately into the > > DSMIPv6 draft following a hopefully quick review from the group. > > > > Best Regards > > George > > P.S.: I will have intermittent connectivity Friday-Sunday. > > > > > > -------------------------------------------------------------- > > --------------------------------------------------------- > > DSMIPv6 defines a number of possible data encapsulations > > depending on the MN's connectivity and MN's and HA's > > configuration. These encapsulations and the signaling > > required to establish them, are straight forward when the MN > > is connected to an IPv6 capable network. > > Some clarification is, however, needed for IKEv2/IPSEC > > operations when the MN is connected to an IPv4-only network. > > > > > > 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 > > > > RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 > > includes information about how IKEv2 runs over IPv4/UDP for > > NAT Traversal. A > > DSMIPv6 MN connected to an IPv4-only network then, needs to > > follow the procedures described below. > > > > To establish an SA for the protection of BU/BA messages, the > > DSMIPv6 MN and the HA SHOULD implement the following IKEv2 compatible > > procedure: > > > > Mobile Node Home Agent > > ----------- ---------- > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > > UDP (500, 500) HDR, SAi1, KEi, Ni > > NAT-D, NAT-D --> > > <-- IPv4(source_addr=HAADDR, > > dest_addr=V4ADDR) > > UDP(500,X) HDR, SAr1, > > KEr, Nr, [CERTREQ] > > NAT-D, NAT-D > > > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > > UDP (4500,4500) HDR, SK > > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > > --> > > > > <-- IPv4(source_addr=HAADDR, > > dest_addr=V4ADDR) > > UDP (4500,Y) > Marker> HDR*#, SK > > {IDr, [CERT,] AUTH, > > SAr2, TSi, TSr} > > > > > > The SPDs are as shown in RFC 4877 Section 7.2.1 > > > > mobile node SPD-S: > > - IF local_address = home_address_1 & > > remote_address = home_agent_1 & > > proto = MH & local_mh_type = BU & remote_mh_type = BAck > > Then use SA ESP transport mode > > Initiate using IDi = user_1 to address home_agent_1 > > > > home agent SPD-S: > > - IF local_address = home_agent_1 & > > remote_address = home_address_1 & > > proto = MH & local_mh_type = BAck & remote_mh_type = BU > > Then use SA ESP transport mode > > > > where home_address_1 is the MN's registered IPv6 home address and > > home_agent_1 is the IP address of the home agent > > > > The above should result in BU/BA messages with the following > > encapsulations: > > Binding update received by the home agent: > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > > UDP header (sport=X, dport=DSMIPv6) > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > > > At the home agent, following UDP de-tunneling the Binding > > Update is delivered to the IPSEC module as shown below: > > > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > The Binding Update following IPSEC processing is delivered to the > > DSMIPv6 home agent module as follows: > > > > IPv6 header (src=V6HOA, dst=HAADDR) > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > > > > > The Binding Acknowledgement sent by the home agent module to > > the IPSEC module is as follows: > > > > IPv6 header (src=HAADDR, dst=V6HOA) > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > (+ other as needed) > > > > The Binding Acknowledgement send by the HA to the MN is as follows: > > > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > > UDP Header (sport=DSMIPv6, dport=Y) > > IPv6 header (src=HAADDR, dst=V6HOA) > > ESP Header in Transport Mode > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > > > > > > > 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 > > > > To secure data traffic when the MN is located on an IPv4 only > > network, the MN MUST establish a child_SA for that purpose. > > The procedure is as > > follows: > > > > Mobile Node Home Agent > > ----------- ---------- > > UDP (4500,4500) HDR, SK > > {[N], SA, Ni, [KEi],[TSi, TSr]} --> > > > > <-- UDP (4500,Y) > Marker> HDR, SK > > {SA, Nr, [KEr], [TSi, TSr]} > > > > > > If no NAT is detected, the encapsulation used will be: > > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > > > If NAT is detected, the encapsulation used will be > > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > > UDP (sport=X, dport=4500) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where v4CoA may be the external IPv4 address of the NAT, IP is either > > IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA > > > > The SPD for data decryption whether NAT is detected or not is > > set as follows. Note that this rule is designed to match all > > data from the MN to nodes other than the HA. This is done so > > that this rule does not overlap with the earlier rule > > securing BU/BA signaling between the MN and the HA. > > > > Mobile Node SPD-S: > > - IF local_address = home_address & > > remote_address != home_agent & > > proto=any > > Then use SA ESP tunnel mode > > Initiate using IDi = user_1 to address home_agent_1 > > > > home agent SPD-S: > > - IF local_address != home_agent & > > remote_address = home_address & > > proto = any > > Then use SA ESP tunnel mode > > > > where home_address is the MN's registered IPv6 or IPv4 home > > address and home_agent is the IPv6 or the IPv4 address of the > > home agent. > > > > _______________________________________________ > > 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 Apr 21 06:24:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5963A6AD4; Mon, 21 Apr 2008 06:24: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 BB7B43A6A53 for ; Mon, 21 Apr 2008 06:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 5AlNuS28EqUp for ; Mon, 21 Apr 2008 06:24:25 -0700 (PDT) Received: from tietoe03.tietoenator.com (mail1.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id AD5553A6AD4 for ; Mon, 21 Apr 2008 06:24:24 -0700 (PDT) X-AuditID: c26e2f18-00001ecc0000050c-0f-480c95935441 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 16:24:35 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:24:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:24:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions Thread-Index: AcijsHCGw8izSZUbSmy3yofF0wu+tQAAHH7A References: From: To: X-OriginalArrivalTime: 21 Apr 2008 13:24:29.0893 (UTC) FILETIME=[076A2750:01C8A3B3] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 Thanks. I have clarified my statements inline. Christian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: 21. april 2008 15:05 > To: Kaas-Petersen Christian > Cc: mext@ietf.org > Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > Hi Christian, > > Thanks for your comments, see inline... > > On Mon, Apr 21, 2008 at 1:50 PM, > wrote: > > A few comments. > > > > As a result of section 1's IKE exchanges, the NAT box has the > > mappings > > > > new new > > src dst src dst > > ---- ---- ---- ---- > > UDP 500 500 maps to UDP X 500 > > UDP 4500 4500 maps to UDP Y 4500 > > > > The following BU and BA packets will then create the mapping > > > > UDP DSMIP DSMIP maps to UDP Z DSMIP > > > > calling for a change in the UDP headers of the BU and BA packets. > > > > GT> It is not clear to me if the above is an observation or whether > you are suggesting something specific. I think the text > already shows all this and the fact that the UDP header > changes (if NAT exists) does not affect the IKEv2 SA for the BU/BA. > In "1. IKEv2 operation for ..." I read the lines (a) UDP(500,X) HDR, SAr1, KEr, Nr, ... (b) UDP(4500,Y) HDR*#, SK... (c) UDP header (sport=X, dport=DSMIPv6) ... (d) UDP Header (sport=DSMIPv6, dport=Y) and I asked myself, is the X in (a) the same X as in (c), and is the Y in (b) the same as the Y in (d), and I believe the answer is no (which I tried illustrate in the NAT table), so I suggest X in (c) replaced by Z and the Y in (d) replaced by Z. > > > For section 1's IKE exchanges, the following details might be > > considered > > > > * Use N(USE_TRANSPORT_MODE) > > GT> Use that where? the packet formats already indicate ESP > Transport mode. Insert, such that IPv4(source_addr=V4ADDR, dest_addr=HAADDR) UDP (4500,4500) HDR, SK {IDi, [CERT+], [CERTREQ+], [IDr], AUTH, N(USE_TRANSPORT_MODE), SAr2, TSi, TSr} Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 21 06:30:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC273A6BBB; Mon, 21 Apr 2008 06:30: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 2D9C93A6AD4 for ; Mon, 21 Apr 2008 06:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 C+hzU3ibh7hy for ; Mon, 21 Apr 2008 06:30:30 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id C7C8E3A6F35 for ; Mon, 21 Apr 2008 06:30:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1338641wfa.31 for ; Mon, 21 Apr 2008 06:30:37 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0DjNzId050GPftAy+l/r5xg0mCp56UE+SXtec3YqMsE=; b=bD4i8sxksi5AsafjqpXQHt7qCscsO9xgcuEkCimGVOeHxHZ4TWGT6Vdq26oh1CTnBCKSR33bkCYJZbhS6zwStXgRlWKlJbiiXfHyjRrd++eL+nK54JJ9KWluqYYzqkWagePe2eSHoPeKWFE2K1UkE2koULeOOKUtr2rBql6seZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=F+MVvqLm3XRtAWJ+uhf3Kq/9xtSj4ojqRoYaAWgJZQS+WeCDBGnuodEP1qJUyTkTd9mU+bBF7gUC7DrhQHzNBD7H8NJhqrgZ1d6iw5HeTy+8vWWMXTaW/OIxW/HV0CH5MMfMU0nfKuHcvSMlN8sSEoxa2LEwzkbXnSQxHhFRxTw= Received: by 10.142.71.2 with SMTP id t2mr1683188wfa.344.1208784637429; Mon, 21 Apr 2008 06:30:37 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Mon, 21 Apr 2008 06:30:37 -0700 (PDT) Message-ID: Date: Mon, 21 Apr 2008 14:30:37 +0100 From: "George Tsirtsis" To: Christian.Kaas-Petersen@tietoenator.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 OK I am fine with all of that. Hesham can incorporate all this in the draft. Thanks George On Mon, Apr 21, 2008 at 2:24 PM, wrote: > Thanks. I have clarified my statements inline. > > Christian > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of George Tsirtsis > > > > Sent: 21. april 2008 15:05 > > To: Kaas-Petersen Christian > > Cc: mext@ietf.org > > Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > > > Hi Christian, > > > > Thanks for your comments, see inline... > > > > On Mon, Apr 21, 2008 at 1:50 PM, > > wrote: > > > A few comments. > > > > > > As a result of section 1's IKE exchanges, the NAT box has the > > > mappings > > > > > > new new > > > src dst src dst > > > ---- ---- ---- ---- > > > UDP 500 500 maps to UDP X 500 > > > UDP 4500 4500 maps to UDP Y 4500 > > > > > > The following BU and BA packets will then create the mapping > > > > > > UDP DSMIP DSMIP maps to UDP Z DSMIP > > > > > > calling for a change in the UDP headers of the BU and BA packets. > > > > > > > GT> It is not clear to me if the above is an observation or whether > > you are suggesting something specific. I think the text > > already shows all this and the fact that the UDP header > > changes (if NAT exists) does not affect the IKEv2 SA for the BU/BA. > > > > In "1. IKEv2 operation for ..." I read the lines > > (a) UDP(500,X) HDR, SAr1, KEr, Nr, ... > (b) UDP(4500,Y) HDR*#, SK... > (c) UDP header (sport=X, dport=DSMIPv6) ... > (d) UDP Header (sport=DSMIPv6, dport=Y) > > and I asked myself, is the X in (a) the same X as in (c), and is > the Y in (b) the same as the Y in (d), and I believe > the answer is no (which I tried illustrate in the NAT table), > so I suggest X in (c) replaced by Z and the Y in (d) replaced by Z. > > > > > > > > For section 1's IKE exchanges, the following details might be > > > considered > > > > > > * Use N(USE_TRANSPORT_MODE) > > > > GT> Use that where? the packet formats already indicate ESP > > Transport mode. > > Insert, such that > > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT+], [CERTREQ+], [IDr], AUTH, N(USE_TRANSPORT_MODE), > SAr2, TSi, TSr} > > Christian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 22 00:57:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4CD3A6FBA; Tue, 22 Apr 2008 00:57: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 C6A933A6FBA for ; Tue, 22 Apr 2008 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW6d9Jw-9drs for ; Tue, 22 Apr 2008 00:57:04 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 7F0423A6C5A for ; Tue, 22 Apr 2008 00:57:04 -0700 (PDT) Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZP001Q9VF8UT@mailout1.samsung.com> for mext@ietf.org; Tue, 22 Apr 2008 16:57:08 +0900 (KST) Received: from ep_spt03 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZP005CWVF87X@ms5.samsung.com> for mext@ietf.org; Tue, 22 Apr 2008 16:57:08 +0900 (KST) Content-return: prohibited Date: Tue, 22 Apr 2008 07:57:08 +0000 (GMT) From: Heejin Jang To: Alexandru Petrescu Message-id: <20147779.109051208851028461.JavaMail.weblogic@epml05> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080422075347227@heejin.jang X-MTR: 20080422075347227@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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, Alexandru. Thanks for your concerns. Kindly see the below. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Alexandru Petrescu > Sent: Monday, April 21, 2008 6:34 PM > To: Jari Arkko > Cc: mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Jari Arkko wrote: > > The last edits are in -15 now. Any additional people who want to > > comment on this before its approved? > > Hi Jari, > > I am not familiar with the advancement of this document and the recent > discussion. > > I have just quickly skimmed through it. > > I am surprised by the intention to pursue the document and get it > approved. Because I find a few incoherencies. It may be I'm > not enough familiar with the document, if so my message can > be discarded. > > For example: > > 3. DHCP options for HA Dynamic Discovery > > > > This section introduces new DHCP options and their > sub-options which > > are used for dynamic discovery of the home agent's IPv6 > address, IPv6 > > home network prefix, > > So the home network prefix is discovered, presumably by MN. > > > 3.1. Home Network Information Option > > > > This option is proposed to allow the exchange of home network > > information between the mobile node (DHCP client) and the DHCP > > server. It is used to indicate the target home network > requested by the mobile node to the DHCP server in the Information-request > > message. In the Reply message, it conveys the home network > > information assigned by the DHCP server to the mobile node. > > The MN indicates the home network information to DHCP Server, and then > the DHCP Server indicates back to MN the home network information. Is > this information the same? Can it change? It can change. As described 4.3, the server provides the home network information according the id-type in the request. For e.g., if id-type = 0 is in the request, the server returns the configured local information irrespective of information received from NAS. > If the MN knows the home network information then why does it need the > DHCP Server to tell it back the home network information? This is a part of integrated-bootstrapping scenario. So, if the MN knows its home information, it does not need to send an Information-request at all. > Is the home network prefix part of the home network information? Yes. it is home network information but its use is limited only to dynamic HA discovery. I mean, it cannot be used for address auto-configuration. I'm not sure I understood your questino well. > > 4.3. DHCP Server Behavior > > > > When the server receives a Relay-forward message, it may include the > > MIP6 Relay Agent option in case there was home information available > > for the mobile node at the relay. > > DHCP Server includes the MIP6 Relay Agent option into what? See to Sec 3.2. "The DHCP relay agent sends this option to the DHCP server in the Relay-forward message." > Overall comments about some paragraphs: > > New DHCP options are defined which allow a mobile node to request the > > home agent IP address, FQDN, or home network prefix and obtain it > > via the DHCP response. > > If this is a MN, then it could be a MR, and MR may need to learn Mobile > Network Prefixes. Is it necessary to learn Mobile Network Prefixes as > well? Just a question. As answered previously, the prefix is provided only for dynamic HA discovery, not for auto-configuration or MIP6 binding. In that sense, I don't think the MNP discovery is in the scope of this document. > > A mobile node can indicate its home network identity when roaming to > > a visited network in order to obtain the MIP6 bootstrap parameters > > from the home network. As an example, the visited network may > > determine the home network of the mobile node based on the realm > > portion of the NAI (Network Access Identifier) [RFC4282] used in > > access authentication. > > This is not a good example, it is not a good idea to decide > the identity of a subnet based on the realm part of NAI. There is no relationship > about domain names and subnet addresses, and there shouldn't be any. If > one needs to identify a subnet then it's by its IP subnet address, not > by its fqdn (there's no fqdn-subnet relationship). This is not about deciding the identity of a subnet from NAI. For e.g., if my NAI is heejin.jang@samsung.com, it can be assumed that my ISP is samsung. This is just one of possible scenarios. > I haven't read further. > > 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 22 02:24:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E663A6A2D; Tue, 22 Apr 2008 02:24: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 67A553A699C for ; Tue, 22 Apr 2008 02:24:25 -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 vPcXXzu6avMA for ; Tue, 22 Apr 2008 02:24:24 -0700 (PDT) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.242]) by core3.amsl.com (Postfix) with ESMTP id 641343A6917 for ; Tue, 22 Apr 2008 02:24:24 -0700 (PDT) Received: by hs-out-0708.google.com with SMTP id 4so1127080hsl.5 for ; Tue, 22 Apr 2008 02:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; bh=YGU/SJ5U8Y6+/aUJ3SinL838eJWBdA1qUT22UzyX+zY=; b=VaoQ4NeLEFxgO5QhhQVfMy88nDkq2tj8AGPKBvzWbL7Iy4xu0coyayKInKkDmUbWMethu0AU5FUHZqOYBDx+fdNf7K8kb/0JfYadqrJATjQKhfZ1eKhRXM8I2MkwYK2RHQFa6aC8/R42pw6YQ6lhixorqjMC6A2z81lDmbG3ffA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; b=nxmQLnAqsAxa5LtHqhtD8t8fAy7ADTnyUZLq7P4O+Cdr70JdfDBqqQAgTzaW1hH3vWnwkHUsrDydfZa58CCQ5MSNShFeLucJCU+YV5UrSUpc+6ycRShwNqZpzeiAp+3sVwWpn5jmABLrcC8lYFhiuRbiDRzmqrscUorN7ludCQA= Received: by 10.90.91.2 with SMTP id o2mr548184agb.56.1208856270102; Tue, 22 Apr 2008 02:24:30 -0700 (PDT) Received: from EM60-254-220-170.pool.e-mobile.ne.jp ( [60.254.220.170]) by mx.google.com with ESMTPS id s30sm9850171elf.16.2008.04.22.02.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Apr 2008 02:24:28 -0700 (PDT) Message-Id: From: Ryuji Wakikawa To: George Tsirtsis , mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 18:24:15 +0900 X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] MCoA Update again [pre07-2] 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 George and all, Thanks for your detail comments. I modify the document according to your inputs. I haven't talked to Sri yet for reusing the mobile node identifier option instead of defining the new link-layer address option. I upload the new document on the web, again. http://www.sfc.wide.ad.jp/~ryuji/draft-ietf-monami6-multiplecoa-pre07-2.txt The diff from the previous draft is also available at http://www.sfc.wide.ad.jp/~ryuji/mcoadiff2.html I hope we are ready for WGLC:-) regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 22 02:40:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DBF28C30F; Tue, 22 Apr 2008 02:40: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 428843A6FC5 for ; Tue, 22 Apr 2008 02:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=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 mWolAk8SkUb4 for ; Tue, 22 Apr 2008 02:40:14 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 09AE43A6840 for ; Tue, 22 Apr 2008 02:40:13 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3M9ffH4012300; Tue, 22 Apr 2008 04:42:44 -0500 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 12:40:10 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 12:40:10 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 12:40:09 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB726E05DE@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions Thread-index: AcigZCCthi5WACYpQbaaFocHGlO9JgD9oDUg References: From: To: , X-OriginalArrivalTime: 22 Apr 2008 09:40:10.0182 (UTC) FILETIME=[DB36FE60:01C8A45C] X-Nokia-AV: Clean Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions 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 Looks quite good; couple of comments in-line: > -----Original Message----- > From: George Tsirtsis > Sent: 17 April, 2008 11:22 > To: mext > Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions > > Hi all, > > Here is the clarification text for IKEv2/IPSEC and DSMIPv6 > interactions. In particular, the text clarifies the behavior when > the MN is connected to an IPv4 network, which RFC4877 does not > cover. > > Thanks to Pasi for his review and his help with defining the > required SPDs; also thanks to Wassim and Hesham for their review. > Hesham will fold the following text appropriately into the DSMIPv6 > draft following a hopefully quick review from the group. > > Best Regards > George > P.S.: I will have intermittent connectivity Friday-Sunday. > > > -------------------------------------------------------------- > --------------------------------------------------------- > DSMIPv6 defines a number of possible data encapsulations depending on > the MN's connectivity and MN's and HA's configuration. These > encapsulations and the signaling required to establish them, are > straight forward when the MN is connected to an IPv6 capable network. > Some clarification is, however, needed for IKEv2/IPSEC operations when > the MN is connected to an IPv4-only network. > > > 1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4 > > RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 > includes information about how IKEv2 runs over IPv4/UDP for NAT > Traversal. A DSMIPv6 MN connected to an IPv4-only network then, > needs to follow the procedures described below. > > To establish an SA for the protection of BU/BA messages, the DSMIPv6 > MN and the HA SHOULD implement the following IKEv2 compatible > procedure: > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (500, 500) HDR, SAi1, KEi, Ni > NAT-D, NAT-D --> > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP(500,X) HDR, SAr1, > KEr, Nr, [CERTREQ] > NAT-D, NAT-D > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > --> As Christian already pointed out, this needs N(USE_TRANSPORT_MODE). Also, a sentence saying that the contents of TSi/TSr are described below (in the SPD entries) wouldn't hurt. > <-- IPv4(source_addr=HAADDR, > dest_addr=V4ADDR) > UDP (4500,Y) Marker> HDR*#, SK > {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} N(USE_TRANSPORT_MODE) here, too (and just "HDR" instead of "HDR*#"?) > The SPDs are as shown in RFC 4877 Section 7.2.1 > > mobile node SPD-S: > - IF local_address = home_address_1 & > remote_address = home_agent_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BAck > Then use SA ESP transport mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address = home_agent_1 & > remote_address = home_address_1 & > proto = MH & local_mh_type = BAck & remote_mh_type = BU > Then use SA ESP transport mode > > where home_address_1 is the MN's registered IPv6 home address and > home_agent_1 is the IP address of the home agent > > The above should result in BU/BA messages with the following > encapsulations: > Binding update received by the home agent: > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP header (sport=X, dport=DSMIPv6) > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) Perhaps use sport=Z, since the port is not likely to be the same as above? > At the home agent, following UDP de-tunneling the Binding Update is > delivered to the IPSEC module as shown below: > > IPv6 header (src=V6HOA, dst=HAADDR) > ESP Header in Transport Mode > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) I would suggest explicitly saying that this packet comes with additional information that is needed later to process the BU correctly. E.g. + additional information: V4ADDR, Z > The Binding Update following IPSEC processing is delivered to the > DSMIPv6 home agent module as follows: > > IPv6 header (src=V6HOA, dst=HAADDR) > Mobility header > BU [IPv4 HAO] > IPv4 CoA option > (+ other as needed) + additional information: V4ADDR, Z > The Binding Acknowledgement sent by the home agent module to the IPSEC > module is as follows: > > IPv6 header (src=HAADDR, dst=V6HOA) > Mobility Header > BA ([IPv4 ACK], NAT DET) > (+ other as needed) + additional information: V4ADDR, Z, force vanilla UDP encaps > The Binding Acknowledgement send by the HA to the MN is as follows: > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > UDP Header (sport=DSMIPv6, dport=Y) > IPv6 header (src=HAADDR, dst=V6HOA) > ESP Header in Transport Mode > Mobility Header > BA ([IPv4 ACK], NAT DET) dport=Z > 2. IKEv2 operation for securing DSMIPv6 Data over IPv4 > > To secure data traffic when the MN is located on an IPv4 only network, > the MN MUST establish a child_SA for that purpose. The procedure is as > follows: > > Mobile Node Home Agent > ----------- ---------- > UDP (4500,4500) HDR, SK > {[N], SA, Ni, [KEi],[TSi, TSr]} --> > > <-- UDP (4500,Y) Marker> HDR, SK > {SA, Nr, [KEr], [TSi, TSr]} IP header should be shown here, too. TSi/TSr are not optional when creating an ESP child SA, so remove the brackets []. > If no NAT is detected, the encapsulation used will be: > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > If NAT is detected, the encapsulation used will be > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > UDP (sport=X, dport=4500) > ESP > IP (source_addr=HoA, set_addr=CNAddr) > Upper_layer_HDR > where v4CoA may be the external IPv4 address of the NAT, IP is either > IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA sport=Y. Should also mention that this shows the packet as seen by HA (not as sent by the MN). > The SPD for data decryption whether NAT is detected or not is set as > follows. Note that this rule is designed to match all data from the MN > to nodes other than the HA. This is done so that this rule does not > overlap with the earlier rule securing BU/BA signaling between the MN > and the HA. > > Mobile Node SPD-S: > - IF local_address = home_address & > remote_address != home_agent & > proto=any > Then use SA ESP tunnel mode > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > - IF local_address != home_agent & > remote_address = home_address & > proto = any > Then use SA ESP tunnel mode > > where home_address is the MN's registered IPv6 or IPv4 home address > and home_agent is the IPv6 or the IPv4 address of the home agent. Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 22 03:44:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7804528C24D; Tue, 22 Apr 2008 03:44: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 1FA9128C1F8 for ; Tue, 22 Apr 2008 03:44:08 -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 ewFwtiuZDA86 for ; Tue, 22 Apr 2008 03:44:03 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 903D928C19D for ; Tue, 22 Apr 2008 03:44:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1208861047!24925261!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 14519 invoked from network); 22 Apr 2008 10:44:07 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-119.messagelabs.com with SMTP; 22 Apr 2008 10:44:07 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m3MAi3BX014403; Tue, 22 Apr 2008 03:44:03 -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 m3MAi2Px022290; Tue, 22 Apr 2008 05:44:02 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m3MAhx1N022275; Tue, 22 Apr 2008 05:44:00 -0500 (CDT) Message-ID: <480DC16F.3000800@gmail.com> Date: Tue, 22 Apr 2008 12:43:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <20147779.109051208851028461.JavaMail.weblogic@epml05> In-Reply-To: <20147779.109051208851028461.JavaMail.weblogic@epml05> X-Antivirus: avast! (VPS 080422-0, 22/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 Heejin, thanks for the reply, [...] >>> 3.1. Home Network Information Option >>> >>> This option is proposed to allow the exchange of home network >>> information between the mobile node (DHCP client) and the DHCP >>> server. It is used to indicate the target home network >> requested by the mobile node to the DHCP server in the >> Information-request >>> message. In the Reply message, it conveys the home network >>> information assigned by the DHCP server to the mobile node. >> The MN indicates the home network information to DHCP Server, and >> then the DHCP Server indicates back to MN the home network >> information. Is this information the same? Can it change? > > It can change. As described 4.3, the server provides the home network > information according the id-type in the request. For e.g., if > id-type = 0 is in the request, the server returns the configured > local information irrespective of information received from NAS. I'm not sure current semantics of DHCP exchanges between Client and Server allow the Client to send information to Server and Server to send it back Information that changed. Isn't the proposal a departure from the DHCP semantics? >> If the MN knows the home network information then why does it need >> the DHCP Server to tell it back the home network information? > > This is a part of integrated-bootstrapping scenario. So, if the MN > knows its home information, it does not need to send an > Information-request at all. So why does the draft say that the "[Home Network Information Option] is used to indicate the target home network requested by the mobile node to the DHCP server in the Information-request message." >> Is the home network prefix part of the home network information? > > Yes. it is home network information but its use is limited only to > dynamic HA discovery. I mean, it cannot be used for address > auto-configuration. I'm not sure I understood your questino well. I don't understand what is the available information at MN prior to doing DHCP. >>> 4.3. DHCP Server Behavior >>> >>> When the server receives a Relay-forward message, it may include >>> the MIP6 Relay Agent option in case there was home information >>> available for the mobile node at the relay. >> DHCP Server includes the MIP6 Relay Agent option into what? > > See to Sec 3.2. > > "The DHCP relay agent sends this option to the DHCP server in the > Relay-forward message." Ok that, but I wondered where does the DHCP Server put its MIP6 Relay Agent option in? In what message? Relay puts it in Relay-Forward message, but the Server puts it in what? >>> New DHCP options are defined which allow a mobile node to request >>> the home agent IP address, FQDN, or home network prefix and >>> obtain it via the DHCP response. >> If this is a MN, then it could be a MR, and MR may need to learn >> Mobile Network Prefixes. Is it necessary to learn Mobile Network >> Prefixes as well? Just a question. > > As answered previously, the prefix is provided only for dynamic HA > discovery, not for auto-configuration or MIP6 binding. In that sense, > I don't think the MNP discovery is in the scope of this document. Ok. >>> A mobile node can indicate its home network identity when roaming >>> to a visited network in order to obtain the MIP6 bootstrap >>> parameters from the home network. As an example, the visited >>> network may determine the home network of the mobile node based >>> on the realm portion of the NAI (Network Access Identifier) >>> [RFC4282] used in access authentication. >> This is not a good example, it is not a good idea to decide the >> identity of a subnet based on the realm part of NAI. There is no >> relationship about domain names and subnet addresses, and there >> shouldn't be any. If one needs to identify a subnet then it's by >> its IP subnet address, not by its fqdn (there's no fqdn-subnet >> relationship). > > This is not about deciding the identity of a subnet from NAI. For > e.g., if my NAI is heejin.jang@samsung.com, it can be assumed that my > ISP is samsung. This is just one of possible scenarios. I'm sure this is impossible. samsung has many subnets. It's impossible to identify all samsung's subnets only by one realm samsung.com. HA acts on a subnet (HA and subnet are tightly related by HA doing proxy ND) not across an entire domain. Most often a domain is made of several subnets. That's why I thought it's not a good example. 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 Apr 22 06:06:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E7128C1EF; Tue, 22 Apr 2008 06:06: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 E1C133A69C2 for ; Tue, 22 Apr 2008 06:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 XnOmxQugaGL9 for ; Tue, 22 Apr 2008 06:06:08 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D31263A6DDC for ; Tue, 22 Apr 2008 06:06:05 -0700 (PDT) Received: from dummyhost16.it.uc3m.es (unknown [163.117.139.80])by smtp02.uc3m.es (Postfix) with ESMTP id 1B93F39BE4D;Tue, 22 Apr 2008 15:06:10 +0200 (CEST) Message-ID: <480DE2C1.1020502@it.uc3m.es> Date: Tue, 22 Apr 2008 15:06:09 +0200 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.5405 TC:1F TRN:34 TV:5.5.1026(15864.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: Julien Laganier Subject: [MEXT] New items in MEXT charter 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, These are the modifications that we are planning to include in the MEXT chrter. They are the items that have been accepted by the WG and we have proposed some rogh dates for each of those. Please let us know if you have a problem with the dates. We are planning to submit this next week (deadline for comments 28 april) Regards, Julien and marcelo 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. 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. 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.Extend DSMIPv6 Home Network Support Extend 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. July 08 - Submit 00 draft on Binding Revocation Oct 08 - Submit 00 draft on Generic Notification Oct 08 - Submit 00 draft on Virtual Home link configuration Oct 08 - Submit 00 draft on Extended DSMIPv6 Home Network support Dec 08 - Submit draft on Binding Revocation to IESG Jan 09 - Submit draft on Generic Notification to IESG Jan 09 - Submit draft on Virtual Home link configuration to IESG Jan 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 Apr 22 09:58:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3773A69DF; Tue, 22 Apr 2008 09:58: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 607DD3A6CF4 for ; Tue, 22 Apr 2008 09:58:45 -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_13=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 338oSSl4dRy3 for ; Tue, 22 Apr 2008 09:58:42 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2AF363A69DF for ; Tue, 22 Apr 2008 09:58:42 -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=1208883528; x=1240419528; 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]=20New=20items=20in =20MEXT=20charter|Date:=20Tue,=2022=20Apr=202008=2009:58: 45=20-0700|Message-ID:=20|In-Reply-To:=20<480DE2C 1.1020502@it.uc3m.es>|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20New=20 items=20in=20MEXT=20charter|Thread-Index:=20AcikebMu1Z7p/ +lbQJCV015PPyGbWQAH/M3A|References:=20<480DE2C1.1020502@i t.uc3m.es>|From:=20"Giaretta,=20Gerardo"=20|To:=20"marcelo=20bagnulo"=20,=20"mext"=20|Cc:=20"Julien=20Laganier" =20|X-OriginalArrivalTime:=2022 =20Apr=202008=2016:58:46.0364=20(UTC)=20FILETIME=3D[20E1B 1C0:01C8A49A]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,216 0,5278"=3B=20a=3D"2433808"; bh=dCRHc400YmWIWQnlmoqIlZdbyhXuLIL90/Wq9xrmiQI=; b=Q9weSkBBPDyob3S/T2l2+deJ0pZ8yEqAsYCTMypOXql+H0tm5hVjvW1e ANrHwl9vsG4LwPxFdTd82Z0lp4yCk1Y/kG/4ZOrl3duvMrji2Rn3beAYO d07TooWAqUG3Oqj0D26X4njJEXZnh+kDqwcrd/25RHt+F5ZOAwyUvgNQc w=; X-IronPort-AV: E=McAfee;i="5200,2160,5278"; a="2433808" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2008 09:58:48 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3MGwldo019861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Apr 2008 09:58:47 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3MGwk4w032157; Tue, 22 Apr 2008 09:58:47 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 09:58:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 09:58:45 -0700 Message-ID: In-Reply-To: <480DE2C1.1020502@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items in MEXT charter Thread-Index: AcikebMu1Z7p/+lbQJCV015PPyGbWQAH/M3A References: <480DE2C1.1020502@it.uc3m.es> From: "Giaretta, Gerardo" To: "marcelo bagnulo" , "mext" X-OriginalArrivalTime: 22 Apr 2008 16:58:46.0364 (UTC) FILETIME=[20E1B1C0:01C8A49A] Cc: Julien Laganier Subject: Re: [MEXT] New items in MEXT charter 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 and Marcelo, Thanks for providing the list of new items. Please see one question below > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo > Sent: Tuesday, April 22, 2008 6:06 AM > To: mext > Cc: Julien Laganier > Subject: [MEXT] New items in MEXT charter > > Hi, > > These are the modifications that we are planning to include in the MEXT > chrter. > > They are the items that have been accepted by the WG and we have > proposed some rogh dates for each of those. > > Please let us know if you have a problem with the dates. > > We are planning to submit this next week (deadline for comments 28 april) > > Regards, Julien and marcelo > > 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. > > 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. > > 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.Extend DSMIPv6 Home Network Support > > Extend 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. > > > July 08 - Submit 00 draft on Binding Revocation > > Oct 08 - Submit 00 draft on Generic Notification > > Oct 08 - Submit 00 draft on Virtual Home link configuration > > Oct 08 - Submit 00 draft on Extended DSMIPv6 Home Network support > > > Dec 08 - Submit draft on Binding Revocation to IESG > There is a 3GPP dependency on this item (based on TS 24.303) and it would be good to have it published before the end of 08. The draft has been around for a while and has already received some good reviews. Do you think it is feasible to submit the draft to IESG by September/October? I also think having 00 version in July is way too late. Isn't just the draft ready for a 00 WG item version? Thanks Gerardo > Jan 09 - Submit draft on Generic Notification to IESG > > Jan 09 - Submit draft on Virtual Home link configuration to IESG > > Jan 09 - Submit draft on Extended DSMIPv6 Home Network support to IESG > > _______________________________________________ > 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 Apr 22 12:28:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B3A3A6ACB; Tue, 22 Apr 2008 12:28: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 733E93A6ACB for ; Tue, 22 Apr 2008 12:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 CEr-6LekS8PJ for ; Tue, 22 Apr 2008 12:28:40 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 508493A6A52 for ; Tue, 22 Apr 2008 12:28:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3MJSVh21897; Tue, 22 Apr 2008 19:28:32 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 14:28:23 -0500 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items in MEXT charter Thread-index: AcikebMu1Z7p/+lbQJCV015PPyGbWQAH/M3AAAU9btA= References: <480DE2C1.1020502@it.uc3m.es> From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "marcelo bagnulo" , "mext" Cc: Julien Laganier Subject: Re: [MEXT] New items in MEXT charter 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 Gerardo, Just as an FYI, The authors of the binding revocation draft will publish the 00 MEXT personal draft next week to address the latest comments we have received. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Giaretta, Gerardo > Sent: Tuesday, April 22, 2008 11:59 AM > To: marcelo bagnulo; mext > Cc: Julien Laganier > Subject: Re: [MEXT] New items in MEXT charter > > Hi Julien and Marcelo, > > Thanks for providing the list of new items. Please see one > question below > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > > marcelo bagnulo > > Sent: Tuesday, April 22, 2008 6:06 AM > > To: mext > > Cc: Julien Laganier > > Subject: [MEXT] New items in MEXT charter > > > > Hi, > > > > These are the modifications that we are planning to include in the > MEXT > > chrter. > > > > They are the items that have been accepted by the WG and we have > > proposed some rogh dates for each of those. > > > > Please let us know if you have a problem with the dates. > > > > We are planning to submit this next week (deadline for comments 28 > april) > > > > Regards, Julien and marcelo > > > > 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. > > > > 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. > > > > 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.Extend DSMIPv6 Home Network Support > > > > Extend 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. > > > > > > July 08 - Submit 00 draft on Binding Revocation > > > > Oct 08 - Submit 00 draft on Generic Notification > > > > Oct 08 - Submit 00 draft on Virtual Home link configuration > > > > Oct 08 - Submit 00 draft on Extended DSMIPv6 Home Network support > > > > > > Dec 08 - Submit draft on Binding Revocation to IESG > > > > There is a 3GPP dependency on this item (based on TS 24.303) > and it would be good to have it published before the end of > 08. The draft has been around for a while and has already > received some good reviews. Do you think it is feasible to > submit the draft to IESG by September/October? > > I also think having 00 version in July is way too late. Isn't > just the draft ready for a 00 WG item version? > > Thanks > Gerardo > > > Jan 09 - Submit draft on Generic Notification to IESG > > > > Jan 09 - Submit draft on Virtual Home link configuration to IESG > > > > Jan 09 - Submit draft on Extended DSMIPv6 Home Network > support to IESG > > > > _______________________________________________ > > 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 Apr 22 18:13:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA543A691F; Tue, 22 Apr 2008 18:13: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 146C63A6F51 for ; Tue, 22 Apr 2008 18:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SxTByiAT09x for ; Tue, 22 Apr 2008 18:13:24 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 3B6C13A6B5D for ; Tue, 22 Apr 2008 18:13:20 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZR00CP07E8P7@mailout2.samsung.com> for mext@ietf.org; Wed, 23 Apr 2008 10:13:20 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZR000IJ7E8JU@ms5.samsung.com> for mext@ietf.org; Wed, 23 Apr 2008 10:13:20 +0900 (KST) Content-return: prohibited Date: Wed, 23 Apr 2008 01:13:20 +0000 (GMT) From: Heejin Jang To: Alexandru Petrescu Message-id: <33507041.147991208913200413.JavaMail.weblogic@epml11> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080423011300581@heejin.jang X-MTR: 20080423011300581@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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, Alexandru. Please read the document carefully. I think that answers to some of your questions can be found in the draft already. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 22, 2008 7:44 PM > To: heejin.jang@samsung.com > Cc: Jari Arkko; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Hi Heejin, thanks for the reply, > [...] > >>> 3.1. Home Network Information Option > >>> > >>> This option is proposed to allow the exchange of home network > >>> information between the mobile node (DHCP client) and the DHCP > >>> server. It is used to indicate the target home network > >> requested by the mobile node to the DHCP server in the > >> Information-request > >>> message. In the Reply message, it conveys the home network > >>> information assigned by the DHCP server to the mobile node. > >> The MN indicates the home network information to DHCP Server, and > >> then the DHCP Server indicates back to MN the home network > >> information. Is this information the same? Can it change? > > > > It can change. As described 4.3, the server provides the > home network > > information according the id-type in the request. For e.g., if > > id-type = 0 is in the request, the server returns the configured > > local information irrespective of information received from NAS. > > I'm not sure current semantics of DHCP exchanges between Client and > Server allow the Client to send information to Server and Server to send > it back Information that changed. Isn't the proposal a departure > from the DHCP semantics? HN info option is used differently in the request & reply, respectively. In the request, it specifies its preference where the home information is assigned. while, in the request, it carries the information provided by the server. > > >> If the MN knows the home network information then why does it need > >> the DHCP Server to tell it back the home network information? > > > > This is a part of integrated-bootstrapping scenario. So, if the MN > > knows its home information, it does not need to send an > > Information-request at all. > > So why does the draft say that the "[Home Network Information Option] is > used to indicate the target home network requested by the mobile node to > the DHCP server in the Information-request message." As document saids, the procedures follow the stateless DHCPv6. So, only when the MN wants to retrieve the required information, it intiates the stateless DHCPv6. > >> Is the home network prefix part of the home network information? > > > > Yes. it is home network information but its use is limited only to > > dynamic HA discovery. I mean, it cannot be used for address > > auto-configuration. I'm not sure I understood your questino well. > > I don't understand what is the available information at MN prior to > doing DHCP. > > >>> 4.3. DHCP Server Behavior > >>> > >>> When the server receives a Relay-forward message, it may include > >>> the MIP6 Relay Agent option in case there was home information > >>> available for the mobile node at the relay. > >> DHCP Server includes the MIP6 Relay Agent option into what? > > > > See to Sec 3.2. > > > > "The DHCP relay agent sends this option to the DHCP server in the > > Relay-forward message." > > Ok that, but I wondered where does the DHCP Server put its MIP6 Relay > Agent option in? In what message? Relay puts it in Relay-Forward > message, but the Server puts it in what? Server puts the HN information option in the Reply, not MIP6 Relay option. Sever replies with the HN information option according to the HN info option in the request, based on the collected information which may have been delivered from NAS with MIP6 relay option or pre-configured by admin. This is described in the 1st paragraph of Sec 4.3. > >>> New DHCP options are defined which allow a mobile node to request > >>> the home agent IP address, FQDN, or home network prefix and > >>> obtain it via the DHCP response. > >> If this is a MN, then it could be a MR, and MR may need to learn > >> Mobile Network Prefixes. Is it necessary to learn Mobile Network > >> Prefixes as well? Just a question. > > > > As answered previously, the prefix is provided only for dynamic HA > > discovery, not for auto-configuration or MIP6 binding. In > that sense, > > I don't think the MNP discovery is in the scope of this document. > > Ok. > > >>> A mobile node can indicate its home network identity when roaming > >>> to a visited network in order to obtain the MIP6 bootstrap > >>> parameters from the home network. As an example, the visited > >>> network may determine the home network of the mobile node based > >>> on the realm portion of the NAI (Network Access Identifier) > >>> [RFC4282] used in access authentication. > >> This is not a good example, it is not a good idea to decide the > >> identity of a subnet based on the realm part of NAI. There is no > >> relationship about domain names and subnet addresses, and there > >> shouldn't be any. If one needs to identify a subnet then it's by > >> its IP subnet address, not by its fqdn (there's no fqdn-subnet > >> relationship). > > > > This is not about deciding the identity of a subnet from NAI. For > > e.g., if my NAI is heejin.jang@samsung.com, it can be > assumed that my ISP is samsung. This is just one of possible scenarios. > > I'm sure this is impossible. samsung has many subnets. It's impossible > to identify all samsung's subnets only by one realm samsung.com. > > HA acts on a subnet (HA and subnet are tightly related by HA doing proxy > ND) not across an entire domain. Most often a domain is made of several > subnets. > > That's why I thought it's not a good example. There can be many deployment ways to enable the scenario. For e.g., 1) the server simply returns the HN prefix. Then the MN perform dynamic HN discovery according to rfc3775. 2) the NAS is configured a proper HA info. For example, AAA server may deliver to NAS the nearest HA info considering each NAS's location such as "ha_philly.samsung.com" in Philly. 2) suppose the server replied with the FQDN ("ha.samsung.com"). But it does not necessarily mean phisycally a single HA instance all the time. The fqdn may be shared among multiple HAs and dns server may return the different IP based on a source IP of the DNS request or simply as a round-robin. There can be multiple ways to implement this. however, how to do depends on deployment policy, and not in the scope of the hiopt document. > 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 Wed Apr 23 03:21:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416053A6CA8; Wed, 23 Apr 2008 03: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 7AD4C3A6A8A for ; Wed, 23 Apr 2008 03:21:28 -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 9Re21EHqcX0A for ; Wed, 23 Apr 2008 03:21:26 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 62E593A6CA8 for ; Wed, 23 Apr 2008 03:21:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1208946090!22949272!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21315 invoked from network); 23 Apr 2008 10:21:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 23 Apr 2008 10:21:30 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m3NALPVS002002; Wed, 23 Apr 2008 03:21:30 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m3NALPdd013387; Wed, 23 Apr 2008 05:21:25 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m3NALNhS013375; Wed, 23 Apr 2008 05:21:24 -0500 (CDT) Message-ID: <480F0DA2.5030900@gmail.com> Date: Wed, 23 Apr 2008 12:21:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <33507041.147991208913200413.JavaMail.weblogic@epml11> In-Reply-To: <33507041.147991208913200413.JavaMail.weblogic@epml11> X-Antivirus: avast! (VPS 080422-0, 22/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 Heejin Jang wrote: > > Hi, Alexandru. > > Please read the document carefully. I think that answers to some of > your questions can be found in the draft already. Hi Heejin, please take my remarks as speaking from my own experience of using DHCP. I don't have a vast DHCP experience and you may be right at some points. I just find that some logic is a bit flawed. >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 22, 2008 >> 7:44 PM To: heejin.jang@samsung.com Cc: Jari Arkko; mext@ietf.org >> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 >> >> Hi Heejin, thanks for the reply, [...] >>>>> 3.1. Home Network Information Option >>>>> >>>>> This option is proposed to allow the exchange of home network >>>>> information between the mobile node (DHCP client) and the >>>>> DHCP server. It is used to indicate the target home network >>>> requested by the mobile node to the DHCP server in the >>>> Information-request >>>>> message. In the Reply message, it conveys the home network >>>>> information assigned by the DHCP server to the mobile node. >>>> The MN indicates the home network information to DHCP Server, >>>> and then the DHCP Server indicates back to MN the home network >>>> information. Is this information the same? Can it change? >>> It can change. As described 4.3, the server provides the >> home network >>> information according the id-type in the request. For e.g., if >>> id-type = 0 is in the request, the server returns the configured >>> local information irrespective of information received from NAS. >>> >> I'm not sure current semantics of DHCP exchanges between Client and >> Server allow the Client to send information to Server and Server >> to send it back Information that changed. Isn't the proposal a >> departure from the DHCP semantics? > > HN info option is used differently in the request & reply, > respectively. In the request, it specifies its preference where the > home information is assigned. while, in the request, it carries the > information provided by the server. Ok. Is there another example of non-mip6 information exchanged with DHCP that follows this kind of logic? For example, is there an existing DHCPv6 possibility for Client to suggest e.g. Printer-Address to Server and Server reply back to Client another Printer-Address? Or some other information: DNS Server suggested by Client and suggested back differently by Server, or similar example. >>>> If the MN knows the home network information then why does it >>>> need the DHCP Server to tell it back the home network >>>> information? >>> This is a part of integrated-bootstrapping scenario. So, if the >>> MN knows its home information, it does not need to send an >>> Information-request at all. >> So why does the draft say that the "[Home Network Information >> Option] is used to indicate the target home network requested by >> the mobile node to the DHCP server in the Information-request >> message." > > As document saids, the procedures follow the stateless DHCPv6. So, > only when the MN wants to retrieve the required information, it > intiates the stateless DHCPv6. I'm not sure I understand you. First, do you mean the "Stateless DHCPv6" described in RFC3736? I think that RFC doesn't suggest the Client to put data in a request and the Server to suggest back a different data. Or, apparently, a hiopt-13 Client puts IPv6 home network prefix in a Request, with sub-opt-code equal 2, Relay forwards it to Server, and Server puts another IPv6 home network prefix in a Reply, apparently. Is this the intended hiop-13 behaviour? Is this behaviour in this sense completely different than the typical DHCPv6 operation? >>>> Is the home network prefix part of the home network >>>> information? >>> Yes. it is home network information but its use is limited only >>> to dynamic HA discovery. I mean, it cannot be used for address >>> auto-configuration. I'm not sure I understood your questino well. >>> >> I don't understand what is the available information at MN prior to >> doing DHCP. >> >>>>> 4.3. DHCP Server Behavior >>>>> >>>>> When the server receives a Relay-forward message, it may >>>>> include the MIP6 Relay Agent option in case there was home >>>>> information available for the mobile node at the relay. >>>> DHCP Server includes the MIP6 Relay Agent option into what? >>> See to Sec 3.2. >>> >>> "The DHCP relay agent sends this option to the DHCP server in the >>> Relay-forward message." >> Ok that, but I wondered where does the DHCP Server put its MIP6 >> Relay Agent option in? In what message? Relay puts it in >> Relay-Forward message, but the Server puts it in what? > > Server puts the HN information option in the Reply, not MIP6 Relay > option. In the Relay-Reply or in the Reply? I think the document should be clear about this. I would go as far as to suggest two new subsections (1) that describes simply and clearly the overall hiopt message exchanges and (2) list a concentrate of what are the modifications to DHCPv6 RFC3315 that this document suggests. A subsection picturing the topology involved wouldn't hurt either. > Sever replies with the HN information option according to the HN info > option in the request, based on the collected information which may > have been delivered from NAS with MIP6 relay option or pre-configured > by admin. I don't understand how the Reply is based on the collected information. To understand that, the hiopt-13 draft suggests reading mip6-integrated, mip6-bootstrapping-integrated-dhc and mip6-radius drafts. Could hiopt-13 document be made standalone, so I could understand it without reading other documents? > This is described in the 1st paragraph of Sec 4.3. Ok. It should say Relay-Reply sometimes, not only Reply. >>>>> New DHCP options are defined which allow a mobile node to >>>>> request the home agent IP address, FQDN, or home network >>>>> prefix and obtain it via the DHCP response. >>>> If this is a MN, then it could be a MR, and MR may need to >>>> learn Mobile Network Prefixes. Is it necessary to learn Mobile >>>> Network Prefixes as well? Just a question. >>> As answered previously, the prefix is provided only for dynamic >>> HA discovery, not for auto-configuration or MIP6 binding. In >> that sense, >>> I don't think the MNP discovery is in the scope of this document. >>> >> Ok. >> >>>>> A mobile node can indicate its home network identity when >>>>> roaming to a visited network in order to obtain the MIP6 >>>>> bootstrap parameters from the home network. As an example, >>>>> the visited network may determine the home network of the >>>>> mobile node based on the realm portion of the NAI (Network >>>>> Access Identifier) [RFC4282] used in access authentication. >>>> This is not a good example, it is not a good idea to decide the >>>> identity of a subnet based on the realm part of NAI. There is >>>> no relationship about domain names and subnet addresses, and >>>> there shouldn't be any. If one needs to identify a subnet then >>>> it's by its IP subnet address, not by its fqdn (there's no >>>> fqdn-subnet relationship). >>> This is not about deciding the identity of a subnet from NAI. For >>> e.g., if my NAI is heejin.jang@samsung.com, it can be >> assumed that my ISP is samsung. This is just one of possible >> scenarios. >> >> I'm sure this is impossible. samsung has many subnets. It's >> impossible to identify all samsung's subnets only by one realm >> samsung.com. >> >> HA acts on a subnet (HA and subnet are tightly related by HA doing >> proxy ND) not across an entire domain. Most often a domain is made >> of several subnets. >> >> That's why I thought it's not a good example. > > There can be many deployment ways to enable the scenario. For e.g., > > 1) the server simply returns the HN prefix. Then the MN perform > dynamic HN discovery according to rfc3775. Ok, but the NAI identification of a subnet is still a wrong example, right? > 2) the NAS is configured a proper HA info. For example, AAA server > may deliver to NAS the nearest HA info considering each NAS's > location such as "ha_philly.samsung.com" in Philly. And thus DHCP is not involved, right? > 2) suppose the server replied with the FQDN ("ha.samsung.com"). > > But it does not necessarily mean phisycally a single HA instance all > the time. The fqdn may be shared among multiple HAs and dns server > may return the different IP based on a source IP of the DNS request > or simply as a round-robin. This is typically what happens with VPN servers, not Home Agents. It is very rare if at all feasible to use a Home Agent as a VPN Server. The goals of a HA (mainly support continuous sessions and permanent publicly reachable HoA) are completely different than the goals of a VPN Server (mainly offering secure access to private non-reachable network). These goals are completely different. It is wrong to give an example of HA when you actually mean VPN. Please use VPN in the above description. > There can be multiple ways to implement this. however, how to do > depends on deployment policy, and not in the scope of the hiopt > document. Please don't redirect me to policy. Thanks, 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 Thu Apr 24 00:29:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7843A6A46; Thu, 24 Apr 2008 00:29: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 C384C3A6A46 for ; Thu, 24 Apr 2008 00:28:59 -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_DE=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 tg0hRdvxQvAo for ; Thu, 24 Apr 2008 00:28:58 -0700 (PDT) Received: from smtp-2.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id 098A23A693D for ; Thu, 24 Apr 2008 00:28:56 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-2.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 09:29:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 09:28:48 +0200 Message-ID: In-Reply-To: <47F60F77.7000809@mccallumwhyman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MEXT] A Proposed Solution for Aeronautical RO thread-index: AciWRkcpJlS7KKYdRbSZab4SWllH6QO9CaiA References: <47F60F77.7000809@mccallumwhyman.com> From: To: , X-OriginalArrivalTime: 24 Apr 2008 07:29:00.0985 (UTC) FILETIME=[DDA25290:01C8A5DC] Subject: Re: [MEXT] A Proposed Solution for Aeronautical RO 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 Dear Tony, Having read through your proposal, I have some remarks. 1. "No Authentication SA" You propose to provide a kind of "null AUTH" inside the IKE_AUTH message so= that authentication of the Mobile Node can be omitted. However, to at leas= t provide assurance that the HoA is valid, you suggest running the initial = IKE exchanges with the HoA as source address and therefore over the Home Ag= ent and switch to the CoA later on, based on MOBIKE. In this case, the latency is not better than that in MIPv6 RR, that you say= is not efficient: 2 RTTs for the IKE exchange over the HoA, one for updati= ng the SA address with MOBIKE and an additional one for the RR procedure fo= r validating the new CoA. This results in 4 RTTs - more than in MIPv6 with = BU/BA exchange followed by RR and BU/BA, making it 3 RTTs. 2. "Authenticated SA" I assume this is the first part of the mechanism the draft presents as the = main solution, as opposed to the "Non Authenticated SA". It is heavily worded on Mobile Hosts/Home Addresses instead of Mobile Route= rs/Mobile Network Prefixes. You mention setting Traffic Selectors to routes (=3Dprefix instead of a sin= gle address?) for the Mobile Router and, later on, that NAT traversal is im= plicitly possible. IIRC in the case of NAT traversal, the Traffic Selectors= can only consist of a single IP address, and not of a range. 3. "Host to Subnet Transport Mode" This is an evolution to the "No Protection SA", based on creating a new IKE= Child SA alongside the existing AH/ESP options? At this stage I started to wonder about the relationship of your proposal a= nd MIPv6/NEMO. If instead of using a Home Address Option/Type 2 Routing Header you introdu= ce an arbitrary Type X and Y Routing Header and you stick to the "Authentic= ated SA with permission to use the HoA", this is completely independent of = MIPv6/NEMO. In addition you assume that the Mobile Router not just performs the mobilit= y signalling but also the end2end IPsec management. Your key idea is to modify IKEv2 so that instead of just setting up IPSec r= elated SAs it becomes a more generic framework, independent of MEXT that ca= n be used for mobility purposes. I am wondering whether these modifications on IKEv2 (that extend its purpos= e) are within the scope of the working group? Christian > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von > Tony Whyman > Gesendet: Freitag, 4. April 2008 13:23 > An: mext@ietf.org > Betreff: [MEXT] A Proposed Solution for Aeronautical RO > = > Dear all, > = > I have prepared a proposed IPsec based RO scheme that is intended to > meet the requirements contained in draft-ietf-mext-aero-reqs-01. The > paper can be downloaded from: > = > http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.pd > f > = > It's a large paper (15,000+ words) but that is because of the large > Appendix A, which is an analysis of how the proposal meets the current > aeronautical use cases. Appendix B also provides a compliancy check > against draft-ietf-mext-aero-reqs-01. > = > The main body of the paper is likely to be of most interest to this > group. In this, I have tried to evolve the IPsec RO approach proposed in > draft-ietf-mip6-cn-ipsec-07 into a common framework with the > recommendations of Eurocontrol 2006 IP Study. This study was intended > to "assess the feasibility of using IP to support the next generation of > collaborative ATS applications, in the 2020+ timeframe". The published > results of that study can be downloaded from the ICAO website (URL in > the references list of my paper). > = > Although the focus of the paper is on meeting the requirements for > Aeronautical use, I do not believe that the requirements are unique to > civil aviation. The UK Railways Safety and Standards Board (RSSB) is > also about to publish a Guidance Note (Ref: GE/GN8579) which is intended > to co-ordinate the use of IP Networking for mobile networking to trains. > SATCOM, GPRS, WiFi and WiMAX networks are already being used to support > passenger "on train" internet access and some operational use, and this > Guidance Note is intended to co-ordinate the use of IP for operational > comms, leading into Safety Related applications. It was the result of > industry consultation and workshops and resulted in a very similar set > of operational scenarios to those seen in ATC, and a similar proposal > for IPsec based mobile communications. > = > My own conclusion from all this, is that there is a real need for an > IPsec based Mobility Framework to meet the needs of Operational > Communications in (at least) Transport Infrastructure applications. > = > My paper has made some specific criticisms of > draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the needs > of aeronautical communications. However, the underlying criticism is > that draft-ietf-mip6-cn-ipsec-07 is relatively neutral as regards IKEv1 > and IKEv2. My view is that IKEv2 is not just a better protocol, but with > improved Traffic Selection signalling and the MOBIKE (RFC 4555), it is > the only flavour of IPsec IKE that should be considered for an IPsec > based mobility framework. > = > Starting with the assumption that IKEv2/MOBIKE is used, I believe that > it is possible to demonstrate a much improved strategy for IPsec based > Route Optimisation, that starts with the use of the Home Address as the > MN SA end-point and then moves it to the care-of address. Thus > demonstrating both authorisation to use the Home Address and Return > Routability to both addresses before any user data is exchanged. > Interestingly, if user data is to be protected by ESP or AH tunnelling > then there seems to be no need to exchange a Binding Update, as Child > SAs with appropriate Traffic Selectors seem to be sufficient. > = > A further step is also possible if both MN and CN support a common PKI > that provides both authentication and authorisation of the MN to use its > Home Address. In this case, it appears possible for the MN to start the > IPsec based RO procedure direct from its care-of address without there > needing to be any Home Agent involvement. This is particularly > interesting to aeronautical use, where communication is generally > aircraft initiated, as it avoids both availability and regulatory issues > with Home Agents, and fits with the recommendations of the Eurocontrol > IP Study. Although it did not call it as such, this study essentially > proposed an IPsec based RO scheme, which it called "tunnel movement" and > assumed a PKI that authenticated aircraft and their use of their static > IP Addresses. > = > The study limited itself to what was possible with published RFCs, and > thus all air/ground communications had to be ESP tunnelled, due to the > use of IKEv2/MOBIKE to manage the communications paths. Two specific > criticisms arise from this. One is that there are many cases where an > RFC 3775 Home Address Option/Type 2 Routing Header and Transport mode > ESP would be more efficient than ESP tunnelling, and the other is that > it forces all air/ground communications to be protected, even when the > overhead of doing so is not otherwise justifiable. > = > In my paper, I have tried to resolve both criticisms. > = > I have resolved the first, by proposing a new IPsec SA mode that > essentially combines ESP/AH transport mode with use of the RFC 3775 Home > Address Option/Type 2 Routing Header. > = > I have resolved the second by proposing the notion of "No Protection" > SAs - i.e. using the IKEv2 to negotiate IP-in-IP tunnels, or use of the > RFC 3775 Home Address Option/Type 2 Routing Header. Although this seems > to be counter-intuitive for the IPsec IKE to negotiate off security, the > benefit is in having a single mechanism to manage unprotected mobile > communications, when there is also a need for secure mobile communication= s. > = > My paper also examines the case where the IKE is used to manage secure > mobile communications but has no means of authenticating the MN to the > CN. This appears to be interesting as part of a wider framework, but is > not of direct interest to aeronautical communications. > = > I have also investigated possible implications for MN to HA > communications, and proposed IKEv2/MOBIKE scenarios where Binding > Updates are no longer needed here. Again, this is not of direct interest > to aeronautical communications, but should be of wider interest. > = > Looking back on the paper, although I started writing assuming IPv6 > only, almost everything proposed is also relevant to IPv4. Only the use > of the RFC 3775 Home Address Option/Type 2 Routing Header is IPv6 specifi= c. > = > Using the IKE to manage mobility also seems to have some other > interesting implications. Like it or not, NAT Gateways are well > supported by IPsec, and a Mobile Node that uses IKEv2/MOBIKE to manage > both its HA binding and RO, seems to be able to move behind NAT Gateways > and then re-emerge without any obvious problems - although this mode of > operation is limited to ESP tunnels. > = > Basic NEMO operations should really be just a case of an appropriate set > of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that > allows a CN to authenticate a Mobile Router and authorise the routes it > offers, then the use of the IKE to manage Mobile Router Route > Optimisation also appears to be an interesting approach. This is very > relevant to Aeronautical use. > = > IKEv2/MOBIKE has limited multi-homing capability, in respect of > supporting the use of multi-homing for increasing availability. Load > sharing is not part of the current framework. The use of multi-homing > for increasing availability meets a perceived aeronautical requirement > to enable high availability of air/ground communications through agility > in the use of alternative networks. Extension to load sharing seems to a > suitable topic for future work, but not essential for aeronautical use. > = > The purpose of this paper is to develop an IPsec based RO strategy > suitable for aeronautical use and one that is also suitable for similar > transport infrastructure uses, but I believe the use of IPsec based > mobility management using IKEv2 and MOBIKE should be of general interest. > = > Regards > = > Tony Whyman > = > = > = > _______________________________________________ > 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 Apr 27 19:39:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2063E3A6CF2; Sun, 27 Apr 2008 19:39: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 04B2528C130 for ; Sun, 27 Apr 2008 19:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inva0wjMAQtf for ; Sun, 27 Apr 2008 19:38:57 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 7D5A93A6C0C for ; Sun, 27 Apr 2008 19:38:57 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0000CIKKOQH0@mailout2.samsung.com> for mext@ietf.org; Mon, 28 Apr 2008 11:38:50 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K000015AKOQQC@ms5.samsung.com> for mext@ietf.org; Mon, 28 Apr 2008 11:38:50 +0900 (KST) Content-return: prohibited Date: Mon, 28 Apr 2008 02:38:50 +0000 (GMT) From: Heejin Jang To: Alexandru Petrescu Message-id: <28997989.108781209350329950.JavaMail.weblogic@epml09> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080428023434920@heejin.jang X-MTR: 20080428023434920@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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. Please see below. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, April 23, 2008 7:21 PM > To: heejin.jang@samsung.com > Cc: Jari Arkko; mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Heejin Jang wrote: > > > > Hi, Alexandru. > > > > Please read the document carefully. I think that answers to some of > > your questions can be found in the draft already. > > Hi Heejin, please take my remarks as speaking from my own > experience of using DHCP. I don't have a vast DHCP > experience and you may be right at some points. I just find > that some logic is a bit flawed. > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 22, 2008 > >> 7:44 PM To: heejin.jang@samsung.com Cc: Jari Arkko; mext@ietf.org > >> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > >> > >> Hi Heejin, thanks for the reply, [...] > >>>>> 3.1. Home Network Information Option > >>>>> > >>>>> This option is proposed to allow the exchange of home network > >>>>> information between the mobile node (DHCP client) and the DHCP > >>>>> server. It is used to indicate the target home network > >>>> requested by the mobile node to the DHCP server in the > >>>> Information-request > >>>>> message. In the Reply message, it conveys the home network > >>>>> information assigned by the DHCP server to the mobile node. > >>>> The MN indicates the home network information to DHCP > Server, and > >>>> then the DHCP Server indicates back to MN the home network > >>>> information. Is this information the same? Can it change? > >>> It can change. As described 4.3, the server provides the > >> home network > >>> information according the id-type in the request. For e.g., if > >>> id-type = 0 is in the request, the server returns the configured > >>> local information irrespective of information received from NAS. > >>> > >> I'm not sure current semantics of DHCP exchanges between > Client and > >> Server allow the Client to send information to Server and > Server to > >> send it back Information that changed. Isn't the proposal a > >> departure from the DHCP semantics? > > > > HN info option is used differently in the request & reply, > > respectively. In the request, it specifies its preference where the > > home information is assigned. while, in the request, it carries the > > information provided by the server. > > Ok. Is there another example of non-mip6 information > exchanged with DHCP that follows this kind of logic? > > For example, is there an existing DHCPv6 possibility for > Client to suggest e.g. Printer-Address to Server and Server > reply back to Client another Printer-Address? Or some other > information: DNS Server suggested by Client and suggested > back differently by Server, or similar example. Server does not reply differently. Once MN sends a preference about HA's location with an id-type field, then server replies with the corresponding HA information that satisfies a preference in the request. > >>>> If the MN knows the home network information then why > does it need > >>>> the DHCP Server to tell it back the home network information? > >>> This is a part of integrated-bootstrapping scenario. So, > if the MN > >>> knows its home information, it does not need to send an > >>> Information-request at all. > >> So why does the draft say that the "[Home Network > Information Option] > >> is used to indicate the target home network requested by > the mobile > >> node to the DHCP server in the Information-request message." > > > > As document saids, the procedures follow the stateless DHCPv6. So, > > only when the MN wants to retrieve the required information, it > > intiates the stateless DHCPv6. > > I'm not sure I understand you. First, do you mean the > "Stateless DHCPv6" described in RFC3736? Yes. > I think that RFC doesn't suggest the Client to put data in a > request and the Server to suggest back a different data. Or, > apparently, a hiopt-13 Client puts IPv6 home network prefix > in a Request, with sub-opt-code equal 2, Relay forwards it to > Server, and Server puts another IPv6 home network prefix in a > Reply, apparently. Is this the intended hiop-13 behaviour? > > Is this behaviour in this sense completely different than the typical > DHCPv6 operation? Section 3.3 says " While the Sub-opt-code 1 is only available in both the requesting and the returned Home Network Information options, Sub-opt-codes 2, 3, 4, and 5 are available only in the returned Home Network Information option and the MIP6 Relay Agent option." Section 4.1 says " A value of 1 is the only Sub-opt-code available in the request." An MN cannot carry sub-opt-codes other than 1. This means that a sub-option in the request is used only to carry the MN's prefered target MSP in case of id-type 1 so that the server can reply the matching HA information. So, the server never replys with "the different" data. > >>>> Is the home network prefix part of the home network information? > >>> Yes. it is home network information but its use is > limited only to > >>> dynamic HA discovery. I mean, it cannot be used for address > >>> auto-configuration. I'm not sure I understood your questino well. > >>> > >> I don't understand what is the available information at MN > prior to > >> doing DHCP. > >> > >>>>> 4.3. DHCP Server Behavior > >>>>> > >>>>> When the server receives a Relay-forward message, it > may include > >>>>> the MIP6 Relay Agent option in case there was home information > >>>>> available for the mobile node at the relay. > >>>> DHCP Server includes the MIP6 Relay Agent option into what? > >>> See to Sec 3.2. > >>> > >>> "The DHCP relay agent sends this option to the DHCP > server in the > >>> Relay-forward message." > >> Ok that, but I wondered where does the DHCP Server put its > MIP6 Relay > >> Agent option in? In what message? Relay puts it in Relay-Forward > >> message, but the Server puts it in what? > > > > Server puts the HN information option in the Reply, not MIP6 Relay > > option. > > In the Relay-Reply or in the Reply? I think the document > should be clear about this. First of all Severs construct a Reply message, and then it makes Rely-Reply with the Reply message before relaying the messages to the relays. Actually, I mentioned it in detail in Section 4.3 previously (you can see this in hiopt-09), but it was commented to be deleted by Gen-art review results (Francis) because it is too trivial. In hiopt-09, " The DHCP server MUST follow the following logic to construct a Reply message with the Home Network Information option, and include the Reply message in the payload of a Relay Message option of Relay-reply message." In hiopt-15, " It MUST construct the Home Network Information option(s) according to the following logic, and include it or them in the Reply." > I would go as far as to suggest two new subsections (1) that > describes simply and clearly the overall hiopt message > exchanges and (2) list a concentrate of what are the > modifications to DHCPv6 RFC3315 that this document suggests. > A subsection picturing the topology involved wouldn't hurt either. The complete procedures and the message flow figure are described in the integrated-scenario draft. > > Sever replies with the HN information option according to > the HN info > > option in the request, based on the collected information which may > > have been delivered from NAS with MIP6 relay option or > pre-configured > > by admin. > > I don't understand how the Reply is based on the collected > information. > To understand that, the hiopt-13 draft suggests reading > mip6-integrated, mip6-bootstrapping-integrated-dhc and > mip6-radius drafts. Alex. This has been discussed in MIP6 WG long before. Over one year ago (or more than that) there has been discussion on the merge of this draft and integrated-draft, and finally the concensus was to make them separated. I don't think we need to mention this again now. > Could hiopt-13 document be made standalone, so I could > understand it without reading other documents? > > This is described in the 1st paragraph of Sec 4.3. > > Ok. It should say Relay-Reply sometimes, not only Reply. > > >>>>> New DHCP options are defined which allow a mobile node > to request > >>>>> the home agent IP address, FQDN, or home network prefix > and obtain > >>>>> it via the DHCP response. > >>>> If this is a MN, then it could be a MR, and MR may need to learn > >>>> Mobile Network Prefixes. Is it necessary to learn > Mobile Network > >>>> Prefixes as well? Just a question. > >>> As answered previously, the prefix is provided only for > dynamic HA > >>> discovery, not for auto-configuration or MIP6 binding. In > >> that sense, > >>> I don't think the MNP discovery is in the scope of this document. > >>> > >> Ok. > >> > >>>>> A mobile node can indicate its home network identity > when roaming > >>>>> to a visited network in order to obtain the MIP6 bootstrap > >>>>> parameters from the home network. As an example, the visited > >>>>> network may determine the home network of the mobile > node based on > >>>>> the realm portion of the NAI (Network Access > Identifier) [RFC4282] > >>>>> used in access authentication. > >>>> This is not a good example, it is not a good idea to decide the > >>>> identity of a subnet based on the realm part of NAI. > There is no > >>>> relationship about domain names and subnet addresses, and there > >>>> shouldn't be any. If one needs to identify a subnet > then it's by > >>>> its IP subnet address, not by its fqdn (there's no fqdn-subnet > >>>> relationship). > >>> This is not about deciding the identity of a subnet from > NAI. For > >>> e.g., if my NAI is heejin.jang@samsung.com, it can be > >> assumed that my ISP is samsung. This is just one of possible > >> scenarios. > >> > >> I'm sure this is impossible. samsung has many subnets. It's > >> impossible to identify all samsung's subnets only by one realm > >> samsung.com. > >> > >> HA acts on a subnet (HA and subnet are tightly related by HA doing > >> proxy ND) not across an entire domain. Most often a > domain is made > >> of several subnets. > >> > >> That's why I thought it's not a good example. > > > > There can be many deployment ways to enable the scenario. For e.g., > > > > 1) the server simply returns the HN prefix. Then the MN perform > > dynamic HN discovery according to rfc3775. > > Ok, but the NAI identification of a subnet is still a wrong > example, right? See below. > > 2) the NAS is configured a proper HA info. For example, AAA > server may > > deliver to NAS the nearest HA info considering each NAS's location > > such as "ha_philly.samsung.com" in Philly. > > And thus DHCP is not involved, right? The NAS will deliver the information to the server finally by using MIP6 relay agent option, so DHCP is involved here. > > 2) suppose the server replied with the FQDN ("ha.samsung.com"). > > > > But it does not necessarily mean phisycally a single HA > instance all > > the time. The fqdn may be shared among multiple HAs and dns > server may > > return the different IP based on a source IP of the DNS request or > > simply as a round-robin. > > This is typically what happens with VPN servers, not Home > Agents. It is very rare if at all feasible to use a Home > Agent as a VPN Server. > > The goals of a HA (mainly support continuous sessions and > permanent publicly reachable HoA) are completely different > than the goals of a VPN Server (mainly offering secure access > to private non-reachable network). > These goals are completely different. > > It is wrong to give an example of HA when you actually mean > VPN. Please use VPN in the above description. Such method is very well-known and typical method for load-balancing. > > There can be multiple ways to implement this. however, how to do > > depends on deployment policy, and not in the scope of the hiopt > > document. > > Please don't redirect me to policy. > > Thanks, > > 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 Apr 28 00:39:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C665928C235; Mon, 28 Apr 2008 00:39: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 5906A3A6B59 for ; Mon, 28 Apr 2008 00:39:01 -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 I6qVFU1QOA0I for ; Mon, 28 Apr 2008 00:38:59 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 227623A6AF7 for ; Mon, 28 Apr 2008 00:38:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1209368341!24545766!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 27716 invoked from network); 28 Apr 2008 07:39:01 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 28 Apr 2008 07:39:01 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m3S7csvZ022883; Mon, 28 Apr 2008 00:38:54 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m3S7croZ009604; Mon, 28 Apr 2008 02:38:53 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m3S7coVW009443; Mon, 28 Apr 2008 02:38:51 -0500 (CDT) Message-ID: <48157F00.1030501@gmail.com> Date: Mon, 28 Apr 2008 09:38:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <28997989.108781209350329950.JavaMail.weblogic@epml09> In-Reply-To: <28997989.108781209350329950.JavaMail.weblogic@epml09> X-Antivirus: avast! (VPS 080427-0, 27/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) 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 Heejin Jang wrote: >> For example, is there an existing DHCPv6 possibility for Client to >> suggest e.g. Printer-Address to Server and Server reply back to >> Client another Printer-Address? Or some other information: DNS >> Server suggested by Client and suggested back differently by >> Server, or similar example. > > Server does not reply differently. Once MN sends a preference about > HA's location with an id-type field, then server replies with the > corresponding HA information that satisfies a preference in the > request. Ok, I retain this. Thanks for the clarification. >>>>>> If the MN knows the home network information then why does >>>>>> it need the DHCP Server to tell it back the home network >>>>>> information? This is a part of integrated-bootstrapping >>>>>> scenario. So, if the MN knows its home information, it does >>>>>> not need to send an Information-request at all. So why >>>>>> does the draft say that the "[Home Network Information >>>>>> Option] is used to indicate the target home network >>>>>> requested by the mobile node to the DHCP server in the >>>>>> Information-request message." As document saids, the >>>>>> procedures follow the stateless DHCPv6. So, only when the >>>>>> MN wants to retrieve the required information, it intiates >>>>>> the stateless DHCPv6. >> >> I'm not sure I understand you. First, do you mean the "Stateless >> DHCPv6" described in RFC3736? > > Yes. Then I don't see why stateless DHCPv6 is needed for this? Plain full DHCPv6 can accommodate this scenario. >> I think that RFC doesn't suggest the Client to put data in a >> request and the Server to suggest back a different data. Or, >> apparently, a hiopt-13 Client puts IPv6 home network prefix in a >> Request, with sub-opt-code equal 2, Relay forwards it to Server, >> and Server puts another IPv6 home network prefix in a Reply, >> apparently. Is this the intended hiop-13 behaviour? >> >> Is this behaviour in this sense completely different than the >> typical DHCPv6 operation? > > Section 3.3 says > > " While the Sub-opt-code 1 is only available in both the requesting > and the returned Home Network Information options, Sub-opt-codes 2, > 3, 4, and 5 are available only in the returned Home Network > Information option and the MIP6 Relay Agent option." > > Section 4.1 says > > " A value of 1 is the only Sub-opt-code available in the request." > > An MN cannot carry sub-opt-codes other than 1. This means that a > sub-option in the request is used only to carry the MN's prefered > target MSP in case of id-type 1 so that the server can reply the > matching HA information. > > So, the server never replys with "the different" data. Right, thanks, now I understand it better as being the basic hiopt behaviour. Let me agree with you for a short while that it's good to identify the subnet by a FQDN. If so basically MN (DHCP Client) puts FQDN in the request and the DHCP Server sends back an IP address of the Home Agent. How is this different than DNS Resolution? Why do we need DHCP to do DNS Resolution? >> In the Relay-Reply or in the Reply? I think the document should be >> clear about this. > > First of all Severs construct a Reply message, and then it makes > Rely-Reply with the Reply message before relaying the messages to the > relays. > > Actually, I mentioned it in detail in Section 4.3 previously (you can > see this in hiopt-09), but it was commented to be deleted by Gen-art > review results (Francis) because it is too trivial. > > In hiopt-09, > > " The DHCP server MUST follow the following logic to construct a > Reply message with the Home Network Information option, and include > the Reply message in the payload of a Relay Message option of > Relay-reply message." > > In hiopt-15, > > " It MUST construct the Home Network Information option(s) according > to the following logic, and include it or them in the Reply." Ah ok, thanks for the gen-art explanation. It's not trivial to me as implementor. >> I would go as far as to suggest two new subsections (1) that >> describes simply and clearly the overall hiopt message exchanges >> and (2) list a concentrate of what are the modifications to DHCPv6 >> RFC3315 that this document suggests. A subsection picturing the >> topology involved wouldn't hurt either. > > The complete procedures and the message flow figure are described in > the integrated-scenario draft. You mean that this (hiopt) draft can not work without the integrated-scenario draft? >>> Sever replies with the HN information option according to the HN >>> info option in the request, based on the collected information >>> which may have been delivered from NAS with MIP6 relay option or >>> pre-configured by admin. >> >> I don't understand how the Reply is based on the collected >> information. To understand that, the hiopt-13 draft suggests >> reading mip6-integrated, mip6-bootstrapping-integrated-dhc and >> mip6-radius drafts. > > Alex. This has been discussed in MIP6 WG long before. Over one year > ago (or more than that) there has been discussion on the merge of > this draft and integrated-draft, and finally the concensus was to > make them separated. I don't think we need to mention this again now. Ok. I wanted to understand hiopt separately but if you think it absolutely needs integrated-scenario then so be it. >>> 2) the NAS is configured a proper HA info. For example, AAA >>> server may deliver to NAS the nearest HA info considering each >>> NAS's location such as "ha_philly.samsung.com" in Philly. >> >> And thus DHCP is not involved, right? > > The NAS will deliver the information to the server finally by using > MIP6 relay agent option, so DHCP is involved here. If the 'NAS' is a DHCP Relay I'd prefer to always call it DHCP Relay instead of NAS. Generally, it's good to me to have as few entities as possible. >>> 2) suppose the server replied with the FQDN ("ha.samsung.com"). >>> >>> But it does not necessarily mean phisycally a single HA instance >>> all the time. The fqdn may be shared among multiple HAs and dns >>> server may return the different IP based on a source IP of the >>> DNS request or simply as a round-robin. >> >> This is typically what happens with VPN servers, not Home Agents. >> It is very rare if at all feasible to use a Home Agent as a VPN >> Server. >> >> The goals of a HA (mainly support continuous sessions and permanent >> publicly reachable HoA) are completely different than the goals of >> a VPN Server (mainly offering secure access to private >> non-reachable network). These goals are completely different. >> >> It is wrong to give an example of HA when you actually mean VPN. >> Please use VPN in the above description. > > Such method is very well-known and typical method for load-balancing. I'm sorry I'm afraid there are many things mixed up here. MIP6 HAs do load-balancing in the form of DHAAD. How do VPN Servers do load balancing, which RFC? I'm sure it's different than what MIP6 does. Why mixing VPN and HA concepts here? And finally, I completely disagree identifying a subnet with a FQDN. I also disagree relying the workings of a protocol on that identification. That said, we seem to be in complete respectful disagreement. 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 Apr 28 01:20:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1C63A6E39; Mon, 28 Apr 2008 01:20: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 4FC153A6A35 for ; Mon, 28 Apr 2008 01:20:02 -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 7du8VcvzjiuM for ; Mon, 28 Apr 2008 01:19:58 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7F65C3A6E0A for ; Mon, 28 Apr 2008 01:19:58 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 14E351987F2; Mon, 28 Apr 2008 11:20:01 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B72AF19877E; Mon, 28 Apr 2008 11:20:00 +0300 (EEST) Message-ID: <481588B0.1030206@piuha.net> Date: Mon, 28 Apr 2008 11:20:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <28997989.108781209350329950.JavaMail.weblogic@epml09> In-Reply-To: <28997989.108781209350329950.JavaMail.weblogic@epml09> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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 We're not changing the document structure. Hiopt contains the options, the bootstrapping document contains the bigger picture. The readers have to read all... Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 28 03:41:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BC628C20B; Mon, 28 Apr 2008 03:41: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 E8A5528C21D for ; Mon, 28 Apr 2008 03:41: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 3dl-8Ju2K-P2 for ; Mon, 28 Apr 2008 03:41:37 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8E48228C26D for ; Mon, 28 Apr 2008 03:41:31 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 810F91987F2; Mon, 28 Apr 2008 13:41:34 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 401E819877E; Mon, 28 Apr 2008 13:41:34 +0300 (EEST) Message-ID: <4815A9DD.2000400@piuha.net> Date: Mon, 28 Apr 2008 13:41:33 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Alexandru Petrescu References: <28997989.108781209350329950.JavaMail.weblogic@epml09> <48157F00.1030501@gmail.com> In-Reply-To: <48157F00.1030501@gmail.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? 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, >> Section 3.3 says >> >> " While the Sub-opt-code 1 is only available in both the requesting >> and the returned Home Network Information options, Sub-opt-codes 2, >> 3, 4, and 5 are available only in the returned Home Network >> Information option and the MIP6 Relay Agent option." >> >> Section 4.1 says >> >> " A value of 1 is the only Sub-opt-code available in the request." >> >> An MN cannot carry sub-opt-codes other than 1. This means that a >> sub-option in the request is used only to carry the MN's prefered >> target MSP in case of id-type 1 so that the server can reply the >> matching HA information. >> >> So, the server never replys with "the different" data. > > Right, thanks, now I understand it better as being the basic hiopt > behaviour. > > Let me agree with you for a short while that it's good to identify the > subnet by a FQDN. > > If so basically MN (DHCP Client) puts FQDN in the request and the DHCP > Server sends back an IP address of the Home Agent. > > How is this different than DNS Resolution? Why do we need DHCP > to do DNS Resolution? Having DHCP provide address and other parameter information relating to services is an established practice. This draft is no different from that. I would expect one simple use case for the draft to be sending a request with no preference and getting back an address for an HA. This cannot be done with DNS. Similarly, even where you do have a preference, DNS does not easily allow the response to be decided based on local policy, proximity of the home agent, etc. >>> I would go as far as to suggest two new subsections (1) that >>> describes simply and clearly the overall hiopt message exchanges and >>> (2) list a concentrate of what are the modifications to DHCPv6 >>> RFC3315 that this document suggests. A subsection picturing the >>> topology involved wouldn't hurt either. >> >> The complete procedures and the message flow figure are described in >> the integrated-scenario draft. > > You mean that this (hiopt) draft can not work without the > integrated-scenario draft? No, hiopt is the technical content that needs to be implemented. But to understand the overall system behavior, rationale, etc. one has to read other documents, too. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Apr 28 04:37:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1DB28C26E; Mon, 28 Apr 2008 04:37: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 5A2F928C259 for ; Mon, 28 Apr 2008 04:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 punj4jlu37-q for ; Mon, 28 Apr 2008 04:37:28 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 4B1BD28C26B for ; Mon, 28 Apr 2008 04:37:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1209382651!6379082!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5385 invoked from network); 28 Apr 2008 11:37:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 28 Apr 2008 11:37:31 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m3SBbPbU005097; Mon, 28 Apr 2008 04:37:26 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m3SBbPFe004130; Mon, 28 Apr 2008 06:37:25 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m3SBbObC004110; Mon, 28 Apr 2008 06:37:24 -0500 (CDT) Message-ID: <4815B6F3.6020705@gmail.com> Date: Mon, 28 Apr 2008 13:37:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jari Arkko References: <28997989.108781209350329950.JavaMail.weblogic@epml09> <48157F00.1030501@gmail.com> <4815A9DD.2000400@piuha.net> In-Reply-To: <4815A9DD.2000400@piuha.net> X-Antivirus: avast! (VPS 080427-0, 27/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] why having DHCP do DNS resolution? 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, > >>> Section 3.3 says >>> >>> " While the Sub-opt-code 1 is only available in both the >>> requesting and the returned Home Network Information options, >>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned >>> Home Network Information option and the MIP6 Relay Agent option." >>> >>> >>> >>> >>> Section 4.1 says >>> >>> " A value of 1 is the only Sub-opt-code available in the >>> request." >>> >>> An MN cannot carry sub-opt-codes other than 1. This means that a >>> sub-option in the request is used only to carry the MN's prefered >>> target MSP in case of id-type 1 so that the server can reply the >>> matching HA information. >>> >>> So, the server never replys with "the different" data. >> Right, thanks, now I understand it better as being the basic hiopt >> behaviour. >> >> Let me agree with you for a short while that it's good to identify >> the subnet by a FQDN. >> >> If so basically MN (DHCP Client) puts FQDN in the request and the >> DHCP Server sends back an IP address of the Home Agent. >> >> How is this different than DNS Resolution? Why do we need DHCP to >> do DNS Resolution? > > Having DHCP provide address and other parameter information relating > to services is an established practice. This draft is no different > from that. I would expect one simple use case for the draft to be > sending a request with no preference and getting back an address for > an HA. That yes. The simplest case like that makes a lot of sense to me too. Should be described alone I believe, put first and foremost. This could be described in a much shorter document. It could be described independently of the bootsrapping-integrated scenario. The current hiopt document puts "A part of the solution is the capability to deliver home network prefix information to the mobile node by means of the stateless DHCPv6 [RFC3736] [RFC3315]." first in Section 1 Introduction, first paragraph. Or, "home network prefix information" is much more that what you're saying "an address for an HA". The simplest and most straightforward DHCP options is to have them in the Reply only. The Solicit and/or Request already have many identifiers (NAI, MAC address), no need to add new ones. Why do people think there's a need for new identifiers in the Request? > This cannot be done with DNS. Well, yes, more or less, there is multicast DNS that could address this request, but not much widely deployed. >>>> I would go as far as to suggest two new subsections (1) that >>>> describes simply and clearly the overall hiopt message >>>> exchanges and (2) list a concentrate of what are the >>>> modifications to DHCPv6 RFC3315 that this document suggests. A >>>> subsection picturing the topology involved wouldn't hurt >>>> either. >>> The complete procedures and the message flow figure are described >>> in the integrated-scenario draft. >> You mean that this (hiopt) draft can not work without the >> integrated-scenario draft? > > No, hiopt is the technical content that needs to be implemented. But > to understand the overall system behavior, rationale, etc. one has > to read other documents, too. Jari, sorry, I don't agree. The paragraph that disturbs me most is the following: > The Mobile IPv6 specification [RFC3775] describes how home agents can > be dynamically discovered by mobile nodes that know the home network > prefix. This scheme does not work when prefix information is not > already available to the mobile node. One architecture to solve this > problem is described in > [I-D.ietf-mip6-bootstrapping-integrated-dhc]. If there's a need to specify architecture it's good to specify them separately from protocols, IMHO. Have protocols work with whatever architecture one may come up with. Sorry, I will stop here, 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 Apr 29 08:04:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A23F28C33A; Tue, 29 Apr 2008 08:04: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 B0A9B3A6B26 for ; Tue, 29 Apr 2008 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsZ+Mh5SQ2EN for ; Tue, 29 Apr 2008 08:04:08 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id EB62A28C363 for ; Tue, 29 Apr 2008 08:02:59 -0700 (PDT) Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0300EBTDT1M9@mailout1.samsung.com> for mext@ietf.org; Wed, 30 Apr 2008 00:03:01 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0300F0IDT1H2@ms5.samsung.com> for mext@ietf.org; Wed, 30 Apr 2008 00:03:01 +0900 (KST) Content-return: prohibited Date: Tue, 29 Apr 2008 15:03:01 +0000 (GMT) From: Heejin Jang To: Alexandru Petrescu Message-id: <1930951.197971209481381025.JavaMail.weblogic@epml18> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080429145807586@heejin.jang X-MTR: 20080429145807586@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: lprosee@gmail.com, "mext@ietf.org" Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com 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. See below. ps> I'm supposed to have a vacation till next Monday, and cannot access my samsung account. So kindly refer my gmail account as well. (lprosee@gmail.com) > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Monday, April 28, 2008 4:39 PM > To: heejin.jang@samsung.com > Cc: Jari Arkko; mext@ietf.org > Subject: Re: why having DHCP do DNS resolution? (was: [MEXT] > FW: Summary for the changes in hiopt-13) > > Heejin Jang wrote: > >> For example, is there an existing DHCPv6 possibility for > Client to > >> suggest e.g. Printer-Address to Server and Server reply back to > >> Client another Printer-Address? Or some other information: DNS > >> Server suggested by Client and suggested back differently > by Server, > >> or similar example. > > > > Server does not reply differently. Once MN sends a preference about > > HA's location with an id-type field, then server replies with the > > corresponding HA information that satisfies a preference in the > > request. > > Ok, I retain this. Thanks for the clarification. > > >>>>>> If the MN knows the home network information then why does it > >>>>>> need the DHCP Server to tell it back the home network > >>>>>> information? This is a part of > integrated-bootstrapping scenario. > >>>>>> So, if the MN knows its home information, it does not need to > >>>>>> send an Information-request at all. So why does the draft say > >>>>>> that the "[Home Network Information Option] is used to > indicate > >>>>>> the target home network requested by the mobile node > to the DHCP > >>>>>> server in the Information-request message." As document saids, > >>>>>> the procedures follow the stateless DHCPv6. So, only > when the MN > >>>>>> wants to retrieve the required information, it intiates the > >>>>>> stateless DHCPv6. > >> > >> I'm not sure I understand you. First, do you mean the "Stateless > >> DHCPv6" described in RFC3736? > > > > Yes. > > Then I don't see why stateless DHCPv6 is needed for this? Plain full > DHCPv6 can accommodate this scenario. Basically plain (stateful) DHCPv6 is used for address configuration while stateless DHCPv6 is for other parameters configuration such as DNS server address. So this HN information should be delivered through stateless DHCPv6. > >> I think that RFC doesn't suggest the Client to put data in > a request > >> and the Server to suggest back a different data. Or, > apparently, a > >> hiopt-13 Client puts IPv6 home network prefix in a Request, with > >> sub-opt-code equal 2, Relay forwards it to Server, and Server puts > >> another IPv6 home network prefix in a Reply, apparently. > Is this the > >> intended hiop-13 behaviour? > >> > >> Is this behaviour in this sense completely different than > the typical > >> DHCPv6 operation? > > > > Section 3.3 says > > > > " While the Sub-opt-code 1 is only available in both the requesting > > and the returned Home Network Information options, > Sub-opt-codes 2, 3, > > 4, and 5 are available only in the returned Home Network > Information > > option and the MIP6 Relay Agent option." > > > > Section 4.1 says > > > > " A value of 1 is the only Sub-opt-code available in the request." > > > > An MN cannot carry sub-opt-codes other than 1. This means that a > > sub-option in the request is used only to carry the MN's prefered > > target MSP in case of id-type 1 so that the server can reply the > > matching HA information. > > > > So, the server never replys with "the different" data. > > Right, thanks, now I understand it better as being the basic > hiopt behaviour. > > Let me agree with you for a short while that it's good to > identify the subnet by a FQDN. > > If so basically MN (DHCP Client) puts FQDN in the request and > the DHCP Server sends back an IP address of the Home Agent. > > How is this different than DNS Resolution? Why do we need > DHCP to do DNS Resolution? While MNs are required to know an exact FQDN of the target (HA) for DNS resolution, DHCP discovery enables HA discovery in variable ways even in case MN does not have exact information about its home network. For e.g. it can request the local HAs with the id-type 0. Or the server may return partially matching HA information as described in Section 4.3. > >> In the Relay-Reply or in the Reply? I think the document > should be > >> clear about this. > > > > First of all Severs construct a Reply message, and then it makes > > Rely-Reply with the Reply message before relaying the > messages to the > > relays. > > > > Actually, I mentioned it in detail in Section 4.3 > previously (you can > > see this in hiopt-09), but it was commented to be deleted > by Gen-art > > review results (Francis) because it is too trivial. > > > > In hiopt-09, > > > > " The DHCP server MUST follow the following logic to > construct a Reply > > message with the Home Network Information option, and include the > > Reply message in the payload of a Relay Message option of > Relay-reply > > message." > > > > In hiopt-15, > > > > " It MUST construct the Home Network Information option(s) > according > > to the following logic, and include it or them in the Reply." > > Ah ok, thanks for the gen-art explanation. It's not trivial > to me as implementor. Ok. > >> I would go as far as to suggest two new subsections (1) that > >> describes simply and clearly the overall hiopt message > exchanges and > >> (2) list a concentrate of what are the modifications to DHCPv6 > >> RFC3315 that this document suggests. A subsection picturing the > >> topology involved wouldn't hurt either. > > > > The complete procedures and the message flow figure are > described in > > the integrated-scenario draft. > > You mean that this (hiopt) draft can not work without the > integrated-scenario draft? > > >>> Sever replies with the HN information option according to the HN > >>> info option in the request, based on the collected > information which > >>> may have been delivered from NAS with MIP6 relay option or > >>> pre-configured by admin. > >> > >> I don't understand how the Reply is based on the collected > >> information. To understand that, the hiopt-13 draft > suggests reading > >> mip6-integrated, mip6-bootstrapping-integrated-dhc and mip6-radius > >> drafts. > > > > Alex. This has been discussed in MIP6 WG long before. Over one year > > ago (or more than that) there has been discussion on the > merge of this > > draft and integrated-draft, and finally the concensus was > to make them > > separated. I don't think we need to mention this again now. > > Ok. I wanted to understand hiopt separately but if you think > it absolutely needs integrated-scenario then so be it. > > >>> 2) the NAS is configured a proper HA info. For example, > AAA server > >>> may deliver to NAS the nearest HA info considering each NAS's > >>> location such as "ha_philly.samsung.com" in Philly. > >> > >> And thus DHCP is not involved, right? > > > > The NAS will deliver the information to the server finally by using > > MIP6 relay agent option, so DHCP is involved here. > > If the 'NAS' is a DHCP Relay I'd prefer to always call it > DHCP Relay instead of NAS. > > Generally, it's good to me to have as few entities as possible. > > >>> 3) suppose the server replied with the FQDN ("ha.samsung.com"). > >>> > >>> But it does not necessarily mean phisycally a single HA > instance all > >>> the time. The fqdn may be shared among multiple HAs and > dns server > >>> may return the different IP based on a source IP of the > DNS request > >>> or simply as a round-robin. > >> > >> This is typically what happens with VPN servers, not Home Agents. > >> It is very rare if at all feasible to use a Home Agent as a VPN > >> Server. > >> > >> The goals of a HA (mainly support continuous sessions and > permanent > >> publicly reachable HoA) are completely different than the > goals of a > >> VPN Server (mainly offering secure access to private non-reachable > >> network). These goals are completely different. > >> > >> It is wrong to give an example of HA when you actually mean VPN. > >> Please use VPN in the above description. > > > > Such method is very well-known and typical method for > load-balancing. > > I'm sorry I'm afraid there are many things mixed up here. > > MIP6 HAs do load-balancing in the form of DHAAD. How do VPN > Servers do load balancing, which RFC? I'm sure it's > different than what MIP6 does. > > Why mixing VPN and HA concepts here? > > And finally, I completely disagree identifying a subnet with > a FQDN. I also disagree relying the workings of a protocol > on that identification. > > That said, we seem to be in complete respectful disagreement. IMHO, such a load-balancing approach is wellknown and does not need to be limited to VPN. Anyway here the key point is "to provide HA information based on NAI" can be implemented in various ways as least by using 1) and 2) as described in previous mails. > 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 Apr 29 18:30:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B6728C33F; Tue, 29 Apr 2008 18:30:06 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B3FA3A6C64; Tue, 29 Apr 2008 18:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080430013001.6B3FA3A6C64@core3.amsl.com> Date: Tue, 29 Apr 2008 18:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-07.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 : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-07.txt Pages : 44 Date : 2008-04-29 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.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-monami6-multiplecoa-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-29182558.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 Apr 29 18:33:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B303A6D1C; Tue, 29 Apr 2008 18:33: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 8F0053A6D12 for ; Tue, 29 Apr 2008 18:33:48 -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 VZO1FtJTFVrK for ; Tue, 29 Apr 2008 18:33:47 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 38C4E3A6C39 for ; Tue, 29 Apr 2008 18:33:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m3U1WaI05453; Wed, 30 Apr 2008 01:32:36 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8AA62.16B2E7F3" Date: Tue, 29 Apr 2008 20:32:43 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AciqYdf7LgFa8T++R/6yJVpx/1PdNQAAAzMQ From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA62.16B2E7F3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello All, Please find the latest Binding Revocation for IPv6 Mobility draft at the below link. We highly value your review and comments! Many Thanks in advance! Best Regards, Ahmad -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 29, 2008 8:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-00.txt Pages : 32 Date : 2008-04-29 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio n-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_001_01C8AA62.16B2E7F3 Content-Type: application/octet-stream; name="draft-muhanna-mext-binding-revocation-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-mext-binding-revocation-00.URL Content-Disposition: attachment; filename="draft-muhanna-mext-binding-revocation-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTAwLnR4dA0K ------_=_NextPart_001_01C8AA62.16B2E7F3 Content-Type: text/plain; name="ATT1106489.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1106489.txt Content-Disposition: attachment; filename="ATT1106489.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8AA62.16B2E7F3 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_001_01C8AA62.16B2E7F3-- From mext-bounces@ietf.org Tue Apr 29 18:36:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BACC3A6C44; Tue, 29 Apr 2008 18:36:37 -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 0903F3A6BE7 for ; Tue, 29 Apr 2008 18:36: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=[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 AQco4jva2-lb for ; Tue, 29 Apr 2008 18:36:36 -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 D120228C354 for ; Tue, 29 Apr 2008 18:36:18 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so127745and.122 for ; Tue, 29 Apr 2008 18:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:subject:mime-version:date:references:x-mailer; bh=vGucOZb/i4RG26TGAueu8Xg11/r21OrjmGbwz9+tVEU=; b=qT+GTIOR8EiJrUGI9ZVbn7OQI/9y/mxDmBTl+BcRvcLhl4IS+SfwoTyynlnVrzofc6mOgy4BJ0zy4GdM6Vl6Pu5bG2v+W0dTdsYN/KrlMPa9s51TaOEIINz4GtYB2QmxEog7++FJ1Akgb3uYrcG5wbZ6tmzrMw5+/53oPf+zFzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:subject:mime-version:date:references:x-mailer; b=myxLBP0Q6mVoY1/8Wu7dAOwoKlhSnRVV+qYcf/2ls34VlMie0fWj/v5LUl3DUncFE4KVQYLnCBjhyrgceRN86cN6m4OiKARC9nqV7LIrgojZHKUcM+OA013U9OmTzAzzocTPMIGv/t8/8/Pcl8gdrrzL1GwyWyiSEG6j4RjFJQ4= Received: by 10.100.120.6 with SMTP id s6mr196934anc.72.1209519380743; Tue, 29 Apr 2008 18:36:20 -0700 (PDT) Received: from EM117-55-77-97.pool.e-mobile.ne.jp ( [117.55.77.97]) by mx.google.com with ESMTPS id 5sm1030707wrh.24.2008.04.29.18.36.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Apr 2008 18:36:19 -0700 (PDT) Message-Id: <06F7F475-156A-4BC4-A3B2-0B97522296D1@gmail.com> From: Ryuji Wakikawa To: mext@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-5--716064320 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 30 Apr 2008 10:36:09 +0900 References: <20080430013001.6B3FA3A6C64@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] Fwd: I-D Action:draft-ietf-monami6-multiplecoa-07.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 --Apple-Mail-5--716064320 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi all, We submitted the new version of MCoA. As we discussed at the previous meeting, We will have the second WGLC to this -07 document. regards, ryuji Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 2008 4/30 10:30:01:JST > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: I-D Action:draft-ietf-monami6-multiplecoa-07.txt > > 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 : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-07.txt > Pages : 44 > Date : 2008-04-29 > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. However, for matters of cost, bandwidth, delay, > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.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. --Apple-Mail-5--716064320 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-04-29182558.I-D@ietf.org>

--Apple-Mail-5--716064320 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > 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 --Apple-Mail-5--716064320 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 --Apple-Mail-5--716064320-- From mext-bounces@ietf.org Tue Apr 29 22:53:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8B23A6C49; Tue, 29 Apr 2008 22:53: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 DADCE3A694E for ; Tue, 29 Apr 2008 22:53: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=[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 rQOGHn8Towoc for ; Tue, 29 Apr 2008 22:53:11 -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 137703A6C26 for ; Tue, 29 Apr 2008 22:53:11 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so221332wfg.31 for ; Tue, 29 Apr 2008 22:53: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+Mv0InO1x4/fgSqtuc7k38AGDGBI1kTCCAoRv2Unef4=; b=eemFlAXptA7oudRJrYCU4g4tfkgU8hCKFi1urwGGCyLwKVoJWOIDmiShidJUq8jcibnVqGyt/w5aohgYLicwb0X3pdeghuksqo4GtfGGO4i+8XPwaqsnYLljPabX+IrFpBwrz76Ow0YDkGgtCjJrhieSDpypjyrfd2AkE+DaFKg= 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=iDghTQ18RVopZmbfz/3CXOLngrSWCu30eHW0UxxX7EiwHTC2pVF3iMZexKV07n+l8pcxdnf0VjBce4/4ADXcqtSNz2Ytck+BIZ7XO8e0ttDG7+NPEH51Q7FlF5/O4GzxPxNomHe6nVAqyU7XJUoymDt3iO3J9YXiHNR0Fkz0UhU= Received: by 10.142.216.9 with SMTP id o9mr139191wfg.172.1209534794068; Tue, 29 Apr 2008 22:53:14 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Tue, 29 Apr 2008 22:53:13 -0700 (PDT) Message-ID: Date: Tue, 29 Apr 2008 22:53:13 -0700 From: "Vijay Devarapallli" To: "Jari Arkko" , heejin.jang@samsung.com In-Reply-To: <480C3F56.9090901@piuha.net> MIME-Version: 1.0 Content-Disposition: inline References: <0MKp8S-1Jmq343X4w-0005gv@mrelay.perfora.net> <480C3F56.9090901@piuha.net> Cc: mext@ietf.org Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 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, Heejin, Its been a while since I looked at this document. A few minor comments. The IANA registry for the sub-opt-code in the Home Network Information option and the MIP6 Relay agent option should be relaxed to "Standards Action or IESG approval". It would be good if the sub-opt-code can be extended to carry additional pieces of information using Experimental or Informational RFCs in the future. Mentioning "Standards Action" means the sub-opt-code can only be extended by Standards Track RFCs. This would require a minor change in the IANA considerations section. I think a new registry should be created for the Id-type field in the Home Network Information option (section 3.1). This is missing in the IANA considerations section. Another minor comment related to this. The value '0' should be used to indicate that the MN has no preference, instead of the value '2' being used for no preference and '0' used for visited domain home agent information. That seems more conventional. But if this needs too many changes in the document, don' t bother. Finally, the introduction needs to be slightly re-written to say that the main goal of this document is to deliver the home agent information to the mobile node using stateless DHCPv6. It currently seems to say that the mail goal is to deliver a prefix so that the mobile node can run DHAAD using that prefix. I don't remember if the introduction always used to say this or if it was changed recently. The document otherwise looks fine. Ready for approval by the IESG. :) Vijay On Mon, Apr 21, 2008 at 12:16 AM, Jari Arkko wrote: > The last edits are in -15 now. Any additional people who want to comment > on this before its approved? > > 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 Wed Apr 30 02:41:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251ED3A6B3A; Wed, 30 Apr 2008 02:41: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 9D2613A6BCA for ; Wed, 30 Apr 2008 02:41:43 -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 mryGdFWHKr7Q for ; Wed, 30 Apr 2008 02:41:39 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id EF79C3A6B72 for ; Wed, 30 Apr 2008 02:41:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1209548500!23641316!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 20442 invoked from network); 30 Apr 2008 09:41:40 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-5.tower-119.messagelabs.com with SMTP; 30 Apr 2008 09:41:40 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m3U9fUR2023582; Wed, 30 Apr 2008 02:41:35 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m3U9fTZF020239; Wed, 30 Apr 2008 04:41:30 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m3U9fR9O020219; Wed, 30 Apr 2008 04:41:28 -0500 (CDT) Message-ID: <48183EC6.7000301@gmail.com> Date: Wed, 30 Apr 2008 11:41:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <1930951.197971209481381025.JavaMail.weblogic@epml18> In-Reply-To: <1930951.197971209481381025.JavaMail.weblogic@epml18> X-Antivirus: avast! (VPS 080429-1, 29/04/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) 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 Heejin Jang wrote: > Hi, Alex. See below. > > ps> I'm supposed to have a vacation till next Monday, and cannot > access my samsung account. So kindly refer my gmail account as well. Heejin, enjoy vacations :-) when back in office see below. [...] >> Then I don't see why stateless DHCPv6 is needed for this? Plain >> full DHCPv6 can accommodate this scenario. > > Basically plain (stateful) DHCPv6 is used for address configuration > while stateless DHCPv6 is for other parameters configuration such as > DNS server address. So this HN information should be delivered > through stateless DHCPv6. Let's clarify this use of Stateless DHCPv6 RFC3736. Why does a hiopt MN need to include a Home Network Identifier (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information Option in the Information-Request? Why isn't it sufficient to use the Client Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. Why isn't the DUID enough to identify the Client (1 - Link-layer address plus time, 2 - vendor-assigned unique id based on enterprise number, 3 - link-layer address). Why is it thought that it is necessary to specify Home Network Identifier Sub-Opt-Code 1 as being, for example, the realm part of a NAI, when the DUID exists, is used and covers a different range of cases. >>>> I think that RFC doesn't suggest the Client to put data in a >>>> request and the Server to suggest back a different data. Or, >>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in >>>> a Request, with sub-opt-code equal 2, Relay forwards it to >>>> Server, and Server puts another IPv6 home network prefix in a >>>> Reply, apparently. Is this the intended hiop-13 behaviour? >>>> >>>> Is this behaviour in this sense completely different than the >>>> typical >>>> >>>> DHCPv6 operation? >>> >>> Section 3.3 says >>> >>> " While the Sub-opt-code 1 is only available in both the >>> requesting and the returned Home Network Information options, >>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned >>> Home Network Information option and the MIP6 Relay Agent option." >>> >>> >>> >>> >>> >>> Section 4.1 says >>> >>> " A value of 1 is the only Sub-opt-code available in the >>> request." Right, now makes better sense. For easing my humble reading this statement could appear in section 3.1 where the message encoding of Home Network Information Option is described. >>> An MN cannot carry sub-opt-codes other than 1. This means that a >>> sub-option in the request is used only to carry the MN's >>> prefered target MSP in case of id-type 1 so that the server can >>> reply the matching HA information. >>> >>> So, the server never replys with "the different" data. >> Right, thanks, now I understand it better as being the basic hiopt >> behaviour. >> >> Let me agree with you for a short while that it's good to identify >> the subnet by a FQDN. >> >> If so basically MN (DHCP Client) puts FQDN in the request and the >> DHCP Server sends back an IP address of the Home Agent. >> >> How is this different than DNS Resolution? Why do we need DHCP to >> do DNS Resolution? > > While MNs are required to know an exact FQDN of the target (HA) for > DNS resolution, DHCP discovery enables HA discovery in variable ways > even in case MN does not have exact information about its home > network. For e.g. it can request the local HAs with the id-type 0. Or > the server may return partially matching HA information as described > in Section 4.3. I agree at high level but not in detail. The really big problem here - and in all bootstrapping documents - is that we have not precisely described what is the information available at the MN prior to bootstrapping phase. Different documents make different assumptions and they overlap. [skipped some for focusing the discussion] > IMHO, such a load-balancing approach is wellknown and does not need > to be limited to VPN. Anyway here the key point is "to provide HA > information based on NAI" can be implemented in various ways as least > by using 1) and 2) as described in previous mails. If it is the key point then it should be much more clear than that. It is far from being clear. Now here it's said "NAI" but in the document it's said "for example, the realm part of NAI". If we decide to do only NAI-based HA address bootstrapping with DHCPv6 then I can agree we can have a better document. That is a big if. Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or parameter configuration? I don't think so. They use MAC address (or DUID) but not NAI. I find hiopt very much different than DHCPv6 in this sense. IMHO. ?. If one wants to use NAI (or its realm part) to find the corresponding IP address then use DNS straight resolution, not DHCP. 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 Wed Apr 30 04:31:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D0528C359; Wed, 30 Apr 2008 04:31: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 419413A6D5F for ; Wed, 30 Apr 2008 04:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.300, 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 qAPS1gCjdPlG for ; Wed, 30 Apr 2008 04:31:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 76BCD3A6DD7 for ; Wed, 30 Apr 2008 04:31:43 -0700 (PDT) Received: from dummyhost22.it.uc3m.es (unknown [163.117.139.63])by smtp02.uc3m.es (Postfix) with ESMTP id 3175E39C2B3;Wed, 30 Apr 2008 13:31:44 +0200 (CEST) Message-ID: <481858A0.20102@it.uc3m.es> Date: Wed, 30 Apr 2008 13:31:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext@ietf.org References: <20080430013001.6B3FA3A6C64@core3.amsl.com> In-Reply-To: <20080430013001.6B3FA3A6C64@core3.amsl.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.3565 TC:1F TRN:20 TV:5.5.1026(15880.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: Julien Laganier Subject: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.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, This is the WGLC for draft-ietf-monami6-multiplecoa-07.txt. Please check if all the issues that were raised have been addressed in this new version. If you have issues with the document, please raise them. If you are ok with the document and you think it should be sent to the ISEG, please also say so. Provide comments till may 14. For your convinience, the document can be found at: Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-07.txt Pages : 44 Date : 2008-04-29 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.txt Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 30 11:04:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9386E3A6889; Wed, 30 Apr 2008 11: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 4210F3A6AA5 for ; Wed, 30 Apr 2008 11:04:49 -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 kMb0sbWDrrg5 for ; Wed, 30 Apr 2008 11:04: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 9203A3A6B85 for ; Wed, 30 Apr 2008 11:04:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so465857wfg.31 for ; Wed, 30 Apr 2008 11:04: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=8OYaYJiu4AZQ+vkOlnf7/3a/Ny5rTWHIvtxgE3h80fg=; b=uHbemICwCSfyGyHdwbl2o3b70Jn0M95wqJASkLq2r8HV8wn0Ya3dwLdKXfwK6xjbZQQa7Zg7pWE2Hc01mWPvC/hymL8A6VtkhFq5rTLIH9UEoh6QYbVaTptpn0UcCFCkDuN3ID/hH5/dvtA3owfjKyBl4pm8gFRUZzKWeGyqEko= 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=fnt235GlgwB8l7gxP88K0M8Q88+PFS9a8Boe2BNaQEPkYOkz2JRS3+GqKRzeQ5ZHo9ZSwH0u6biUAtWjpiKku8PA+GYa07Fyw7lENCJ/J6fupFrC7DMuUqbqaz3PGg3r0Vp6fPiI34HI7zu/CdYFwT7mAoHxAyslN7jOVTvmvVE= Received: by 10.142.53.20 with SMTP id b20mr411810wfa.280.1209578683029; Wed, 30 Apr 2008 11:04:43 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Wed, 30 Apr 2008 11:04:42 -0700 (PDT) Message-ID: Date: Wed, 30 Apr 2008 11:04:42 -0700 From: "Vijay Devarapallli" To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 Ahmad and others, We previously had a discussion on this draft on the MIP6 mailing list and it was agreed that the binding revocation message will be a sub-type in the Generic Notification Message. http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt We would need to modify the generic notification message to include a new 'subtype' field. We had discussed this in the past and made no progress. We can start with the following values 0 - Reserved, not used 1 - Notification message indicated by Mobility Options 2 - Binding Revocation Indication 3 - Binding Revocation Acknowledgement 4-255 reserved The Generic Notification message draft is quite simple and shouldn't take too long to standardize. It would be a good idea to use the Generic Notification message as much as possible when you have something to notify to either the mobile node or the home agent. Otherwise we might end up with a proliferation of notification messages using up a lot of mobility header message types. Vijay On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: > Hello All, > > Please find the latest Binding Revocation for IPv6 Mobility draft at the > below link. > We highly value your review and comments! > > Many Thanks in advance! > > Best Regards, > Ahmad > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, April 29, 2008 8:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-00.txt > Pages : 32 > Date : 2008-04-29 > > This document defines the revocation semantics for terminating a mobile > node's mobility session and associated resources. These semantics are > generic enough and can be used by mobility entities in the case of > Client Mobile IPv6 and its extensions. This mechanism allows the > mobility entity which initiates the revocation procedure to request its > corresponding one to terminate either one, multiple or all specified > binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio > n-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 Apr 30 11:44:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898EF3A6A3F; Wed, 30 Apr 2008 11:44: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 DEF813A6A3F for ; Wed, 30 Apr 2008 11:44:00 -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 Ezdb7UagmeMy for ; Wed, 30 Apr 2008 11:44:00 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 09F653A6A25 for ; Wed, 30 Apr 2008 11:44:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so478801wfg.31 for ; Wed, 30 Apr 2008 11:44: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=TxftvlZ8JJ12b75KcHat4vw1kVso9W9+aFg4WIw7k3g=; b=Do6DSH4g/MQIXYUcEPQ//DrYCIebjnguzNr4rdIN4DfWONyfs1WkuturfipkV36sjdenIgCz5JnxwRfxlBAbnJ4NjODJ2IkLR3kjPn9j/9f+/K/Yiw6YsMNV5EqSntZJ6qn2Luxux7fLMLspe7zGSujAcC89q8+JEXjusodTbXA= 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=ua3VRa6LSIpjgct+3k1dVQcLaCj44TDP48szhc7WXUTfmhND4R0flaPT+kDPo6vj2hW5K52VxD6Mica0AhXBZbpcEBOTOwscAYF8rCKVjENSA2pAn7GvzmAoMwZp/VIsrD0xTHeI8E5MRc0WVjo/EH0Ftga997ZkfNCkKxVZTl4= Received: by 10.142.213.9 with SMTP id l9mr438722wfg.104.1209581042768; Wed, 30 Apr 2008 11:44:02 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Wed, 30 Apr 2008 11:44:02 -0700 (PDT) Message-ID: Date: Wed, 30 Apr 2008 11:44:02 -0700 From: "Vijay Devarapallli" To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 Ahmad, One comment on the security considerations section. The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. The security association setup between the MN and the HA or between the MAG and the LMA may not be usable for protecting the mobility header message that carries the binding revocation. According to RFC 4877, if fine grain selectors are used, the following will be the SPD entry on the MN. mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use SA ESP transport mode Initiate using IDi = user_1 to address home_agent_1 This can only protect the BU/BAck messages, not the new mobility header message that carries the binding revocation messages. So we might need some text in the security considerations section that says you must negotiate selectors such that the new mobility header message is also included along with the BU/BAck. Or we can define new SPD entries in the binding revocation document (or in the generic notification draft, if we re-use the generic notification messages for binding revocation). Vijay On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: > Hello All, > > Please find the latest Binding Revocation for IPv6 Mobility draft at the > below link. > We highly value your review and comments! > > Many Thanks in advance! > > Best Regards, > Ahmad > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, April 29, 2008 8:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-00.txt > Pages : 32 > Date : 2008-04-29 > > This document defines the revocation semantics for terminating a mobile > node's mobility session and associated resources. These semantics are > generic enough and can be used by mobility entities in the case of > Client Mobile IPv6 and its extensions. This mechanism allows the > mobility entity which initiates the revocation procedure to request its > corresponding one to terminate either one, multiple or all specified > binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio > n-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 Apr 30 11:48:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107493A6B4D; Wed, 30 Apr 2008 11:48: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 2A6EE3A6964 for ; Wed, 30 Apr 2008 11:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 nU8654rBR+72 for ; Wed, 30 Apr 2008 11:48:02 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 04A013A6A33 for ; Wed, 30 Apr 2008 11:48:01 -0700 (PDT) Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by g1t0029.austin.hp.com (Postfix) with ESMTP id D714D38B01; Wed, 30 Apr 2008 18:48:03 +0000 (UTC) Received: from wrx.zko.hp.com (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 7B6011E7090; Wed, 30 Apr 2008 18:44:45 +0000 (UTC) Message-ID: <4818BEE2.50806@hp.com> Date: Wed, 30 Apr 2008 14:48:02 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Vijay Devarapallli References: In-Reply-To: Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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, I've been talking with Ahmad and Sri about this off-line and we're trying to come to an agreement over some of the text in gen-notification to more easily support the revocation draft. Hopefully an update will be agreeable to everyone, but I wouldn't necessarily hold-up the current revocation draft for it. That's my thoughts at least. -Brian Vijay Devarapallli wrote: > Hi Ahmad and others, > > We previously had a discussion on this draft on the MIP6 mailing list > and it was agreed that the binding revocation message will be a > sub-type in the Generic Notification Message. > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt > > We would need to modify the generic notification message to include a > new 'subtype' field. We had discussed this in the past and made no > progress. We can start with the following values > > 0 - Reserved, not used > 1 - Notification message indicated by Mobility Options > 2 - Binding Revocation Indication > 3 - Binding Revocation Acknowledgement > 4-255 reserved > > The Generic Notification message draft is quite simple and shouldn't > take too long to standardize. It would be a good idea to use the > Generic Notification message as much as > possible when you have something to notify to either the mobile node > or the home agent. Otherwise we might end up with a proliferation of > notification messages using up a lot of mobility header message types. > > Vijay > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: >> Hello All, >> >> Please find the latest Binding Revocation for IPv6 Mobility draft at the >> below link. >> We highly value your review and comments! >> >> Many Thanks in advance! >> >> Best Regards, >> Ahmad >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mext-binding-revocation-00.txt >> Pages : 32 >> Date : 2008-04-29 >> >> This document defines the revocation semantics for terminating a mobile >> node's mobility session and associated resources. These semantics are >> generic enough and can be used by mobility entities in the case of >> Client Mobile IPv6 and its extensions. This mechanism allows the >> mobility entity which initiates the revocation procedure to request its >> corresponding one to terminate either one, multiple or all specified >> binding cache entries. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio >> n-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 Apr 30 12:46:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BF03A6BA6; Wed, 30 Apr 2008 12:46: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 B4D163A698A for ; Wed, 30 Apr 2008 12:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 vUrhz+JqRzqa for ; Wed, 30 Apr 2008 12:46:44 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 265553A6CE0 for ; Wed, 30 Apr 2008 12:46:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m3UJjLm00051; Wed, 30 Apr 2008 19:45:21 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:46:10 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: Aciq8jBD+aEHVf7zT+CQyIzwEugpugACFFyQ References: From: "Ahmad Muhanna" To: "Vijay Devarapallli" Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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, I agree. We will work offline on some clarification text which we can include in the next revision. Thanks! Regards, Ahmad > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Wednesday, April 30, 2008 1:44 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-00.txt > > Hi Ahmad, > > One comment on the security considerations section. > > The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. > > The security association setup between the MN and the HA or > between the MAG and the LMA may not be usable for protecting > the mobility header message that carries the binding > revocation. According to RFC 4877, if fine grain selectors > are used, the following will be the SPD entry on the MN. > > mobile node SPD-S: > - IF local_address = home_address_1 & > remote_address = home_agent_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BAck > Then use SA ESP transport mode > Initiate using IDi = user_1 to address home_agent_1 > > This can only protect the BU/BAck messages, not the new > mobility header message that carries the binding revocation messages. > > So we might need some text in the security considerations > section that says you must negotiate selectors such that the > new mobility header message is also included along with the BU/BAck. > > Or we can define new SPD entries in the binding revocation > document (or in the generic notification draft, if we re-use > the generic notification messages for binding revocation). > > Vijay > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > wrote: > > Hello All, > > > > Please find the latest Binding Revocation for IPv6 > Mobility draft at > > the below link. > > We highly value your review and comments! > > > > Many Thanks in advance! > > > > Best Regards, > > Ahmad > > > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, April 29, 2008 8:30 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > directories. > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : > draft-muhanna-mext-binding-revocation-00.txt > > Pages : 32 > > Date : 2008-04-29 > > > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. These > > semantics are generic enough and can be used by mobility > entities in > > the case of Client Mobile IPv6 and its extensions. This mechanism > > allows the mobility entity which initiates the revocation > procedure > > to request its corresponding one to terminate either one, > multiple or > > all specified binding cache entries. > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocat > > io > > n-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 Apr 30 13:23:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2ED128C393; Wed, 30 Apr 2008 13: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 BBD4D28C28C for ; Wed, 30 Apr 2008 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 wZunJwRXwHeg for ; Wed, 30 Apr 2008 13:23:03 -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 367CC28C393 for ; Wed, 30 Apr 2008 13:23:03 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2008 13:23:06 -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 m3UKN6J0027055; Wed, 30 Apr 2008 13:23:06 -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 m3UKN5ib002167; Wed, 30 Apr 2008 20:23:05 GMT Date: Wed, 30 Apr 2008 13:23:05 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapallli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3951; t=1209586986; x=1210450986; 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]=20FW=3A=20I-D=20Action=3Adraft-m uhanna-mext-binding-revocation-00.txt |Sender:=20; bh=FRngRVcbJbq/GG8yg1lwi90wSxJUDvTcZe+iysK5gzw=; b=CThV0LuVl/FDsk6JT1zmxAYEz+krfkvfa126q9gSux603fKkzhDz/849Ex wZFUDtRiixMrE7Edwm4XOtelNTMCDKwZ/I0n/Qtw8mJWZmSh1Q/zgboZUtd3 zXjMIxJqfRh94wd9fuBjbeH12Wf4QsL5uN6tn+OfnPDBiJV81QbOg=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 We need to specify the selectors for the MH type used for Generic Notification Msg type. All sub-type extensions that are using the Generic Notification Message will be within this scope and are not required to deal with the security semantics. Sri On Wed, 30 Apr 2008, Vijay Devarapallli wrote: > Hi Ahmad, > > One comment on the security considerations section. > > The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the > session was established. > > The security association setup between the MN and the HA or between > the MAG and the LMA may not be usable for protecting the mobility > header message that carries the binding revocation. According to RFC > 4877, if fine grain selectors are used, the following will be the SPD > entry on the MN. > > mobile node SPD-S: > - IF local_address = home_address_1 & > remote_address = home_agent_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BAck > Then use SA ESP transport mode > Initiate using IDi = user_1 to address home_agent_1 > > This can only protect the BU/BAck messages, not the new mobility > header message that carries the binding revocation messages. > > So we might need some text in the security considerations section that > says you must negotiate selectors such that the new mobility header > message is also included along with the BU/BAck. > > Or we can define new SPD entries in the binding revocation document > (or in the generic notification draft, if we re-use the generic > notification messages for binding revocation). > > Vijay > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: >> Hello All, >> >> Please find the latest Binding Revocation for IPv6 Mobility draft at the >> below link. >> We highly value your review and comments! >> >> Many Thanks in advance! >> >> Best Regards, >> Ahmad >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mext-binding-revocation-00.txt >> Pages : 32 >> Date : 2008-04-29 >> >> This document defines the revocation semantics for terminating a mobile >> node's mobility session and associated resources. These semantics are >> generic enough and can be used by mobility entities in the case of >> Client Mobile IPv6 and its extensions. This mechanism allows the >> mobility entity which initiates the revocation procedure to request its >> corresponding one to terminate either one, multiple or all specified >> binding cache entries. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio >> n-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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 30 13:29:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3539E28C3B2; Wed, 30 Apr 2008 13:29: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 D758228C39D for ; Wed, 30 Apr 2008 13:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 KPswl6gKf+s3 for ; Wed, 30 Apr 2008 13:29:02 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 965BD28C36E for ; Wed, 30 Apr 2008 13:29:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UKT0p29024; Wed, 30 Apr 2008 20:29:01 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 15:28:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: Aciq7K5J7kXFThdLQgSIrfH+LNAmMgAEJePQ References: From: "Ahmad Muhanna" To: "Vijay Devarapallli" Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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, Yes, we had a lot of discussion on this topic before and it seems that different people have different understanding of what we have agreed upon. The main comment that people used at that time is NOT to use two new MH types for revocation which is a scare resource. Other opinions said that revocation is a kind of notification. At that time and according to what have been presented in Prague, Notification message was supposed to communicate an opaque string where revocation is not as simple as an opaque string of characters. In my understanding the agreement was to create a new subtype header that will be used as a container for different messages which may have specific processing and functionality. For example: 1. when that subtype is set to 1 "using your example below", then it define that the message to follow is "Generic Notification Message" and the processing of that message will be defined in the Generic Notification Message draft. I guess the Generic notification draft currently define two more subtypes which you did not list. (Generic Notification Response) and (Generic Notification Request) 2. In my understanding, when the subtype is set to 2/3 "using your example", the message contained is BRI/BRA and should follow the processing as per the Binding Revocation for IPv6 Mobility draft. Having said all of the above, I am not sure what is missing. If we want to go this route, then we need to define a "Generic Subtype Header" (or call it whatever) in your example referred as subtype field and use it as a container. The subtype value should define a specific message where the processing is defined in a specific draft. That is at my understanding of the agreement. Regards, Ahmad > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Wednesday, April 30, 2008 1:05 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext; Basavaraj Patil; Brian Haley; Sri Gundavelli > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-00.txt > > Hi Ahmad and others, > > We previously had a discussion on this draft on the MIP6 > mailing list and it was agreed that the binding revocation > message will be a sub-type in the Generic Notification Message. > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-n otification-message-00.txt > > We would need to modify the generic notification message to > include a new 'subtype' field. We had discussed this in the > past and made no progress. We can start with the following values > > 0 - Reserved, not used > 1 - Notification message indicated by Mobility Options > 2 - Binding Revocation Indication > 3 - Binding Revocation Acknowledgement > 4-255 reserved > > The Generic Notification message draft is quite simple and > shouldn't take too long to standardize. It would be a good > idea to use the Generic Notification message as much as > possible when you have something to notify to either the > mobile node or the home agent. Otherwise we might end up with > a proliferation of notification messages using up a lot of > mobility header message types. > > Vijay > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > wrote: > > Hello All, > > > > Please find the latest Binding Revocation for IPv6 > Mobility draft at > > the below link. > > We highly value your review and comments! > > > > Many Thanks in advance! > > > > Best Regards, > > Ahmad > > > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, April 29, 2008 8:30 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > directories. > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : > draft-muhanna-mext-binding-revocation-00.txt > > Pages : 32 > > Date : 2008-04-29 > > > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. These > > semantics are generic enough and can be used by mobility > entities in > > the case of Client Mobile IPv6 and its extensions. This mechanism > > allows the mobility entity which initiates the revocation > procedure > > to request its corresponding one to terminate either one, > multiple or > > all specified binding cache entries. > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocat > > io > > n-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 Apr 30 13:30:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9FC28C3B4; Wed, 30 Apr 2008 13:30: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 4224E28C39D for ; Wed, 30 Apr 2008 13: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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsfLr1-IA6Uw for ; Wed, 30 Apr 2008 13:30:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id DEE1A28C3B2 for ; Wed, 30 Apr 2008 13:30:29 -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=1209587432; x=1241123432; 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]=20FW:=20I-DAction:dr aft-muhanna-mext-binding-revocation-00.txt|Date:=20Wed, =2030=20Apr=202008=2013:30:30=20-0700|Message-ID:=20|In-Reply-To:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20FW:=20 I-DAction:draft-muhanna-mext-binding-revocation-00.txt |Thread-Index:=20AcirAA3B5ZXxrjwAQNqMitUI19vutwAAK8/A |References:=20=20|From:=20"Giaretta,=20Gera rdo"=20|To:=20"Sri=20Gundavelli" =20,=0D=0A=20=20=20=20=20=20=20=20"Vi jay=20Devarapallli"=20|Cc:=20"mext"=20< mext@ietf.org>|X-OriginalArrivalTime:=2030=20Apr=202008 =2020:30:31.0045=20(UTC)=20FILETIME=3D[08C42B50:01C8AB01] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5285"=3B=20a =3D"2809586"; bh=QfxzGs2X+b7cOA6yi5poX6qZDvKyEmCOtjNckO+iPW8=; b=xWUtZVquvn9O3CUruo5W/cqEoCkwImKzOWNEMkt+lGnCLFe3tVj2ZNzp iPkk9YBYlWnSD4lewKXq93C6a659WB8EaoGCnvuQPfCx/cbtAU8ZWKZiu /ugYRE4nkTKfvJFeM73gaXTp4Dotbql8EB8yV8N+csJO/GK1foA53uPR0 Y=; X-IronPort-AV: E=McAfee;i="5100,188,5285"; a="2809586" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2008 13:30:32 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3UKUVKU009307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Apr 2008 13:30:32 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3UKUVZI001088; Wed, 30 Apr 2008 13:30:31 -0700 (PDT) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 13:30:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 13:30:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-00.txt Thread-Index: AcirAA3B5ZXxrjwAQNqMitUI19vutwAAK8/A References: From: "Giaretta, Gerardo" To: "Sri Gundavelli" , "Vijay Devarapallli" X-OriginalArrivalTime: 30 Apr 2008 20:30:31.0045 (UTC) FILETIME=[08C42B50:01C8AB01] Cc: mext Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-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 I agree this would be a good approach. BTW, you are suggesting defining the selectors as additional selectors for the IPsec SA used for BU/BA, correct? I guess it would not be acceptable to create a new child SA just for binding revocation messages. Cheers Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Sri Gundavelli > Sent: Wednesday, April 30, 2008 1:23 PM > To: Vijay Devarapallli > Cc: mext > Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation- > 00.txt > > We need to specify the selectors for the MH type used for > Generic Notification Msg type. All sub-type extensions > that are using the Generic Notification Message will be > within this scope and are not required to deal with the > security semantics. > > Sri > > > > On Wed, 30 Apr 2008, Vijay Devarapallli wrote: > > > Hi Ahmad, > > > > One comment on the security considerations section. > > > > The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the > > session was established. > > > > The security association setup between the MN and the HA or between > > the MAG and the LMA may not be usable for protecting the mobility > > header message that carries the binding revocation. According to RFC > > 4877, if fine grain selectors are used, the following will be the SPD > > entry on the MN. > > > > mobile node SPD-S: > > - IF local_address = home_address_1 & > > remote_address = home_agent_1 & > > proto = MH & local_mh_type = BU & remote_mh_type = BAck > > Then use SA ESP transport mode > > Initiate using IDi = user_1 to address home_agent_1 > > > > This can only protect the BU/BAck messages, not the new mobility > > header message that carries the binding revocation messages. > > > > So we might need some text in the security considerations section that > > says you must negotiate selectors such that the new mobility header > > message is also included along with the BU/BAck. > > > > Or we can define new SPD entries in the binding revocation document > > (or in the generic notification draft, if we re-use the generic > > notification messages for binding revocation). > > > > Vijay > > > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > wrote: > >> Hello All, > >> > >> Please find the latest Binding Revocation for IPv6 Mobility draft at > the > >> below link. > >> We highly value your review and comments! > >> > >> Many Thanks in advance! > >> > >> Best Regards, > >> Ahmad > >> > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >> Internet-Drafts@ietf.org > >> Sent: Tuesday, April 29, 2008 8:30 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> Title : Binding Revocation for IPv6 Mobility > >> Author(s) : A. Muhanna, et al. > >> Filename : draft-muhanna-mext-binding-revocation-00.txt > >> Pages : 32 > >> Date : 2008-04-29 > >> > >> This document defines the revocation semantics for terminating a > mobile > >> node's mobility session and associated resources. These semantics are > >> generic enough and can be used by mobility entities in the case of > >> Client Mobile IPv6 and its extensions. This mechanism allows the > >> mobility entity which initiates the revocation procedure to request > its > >> corresponding one to terminate either one, multiple or all specified > >> binding cache entries. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding- > revocatio > >> n-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 > > > _______________________________________________ > 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 Apr 30 13:41:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F263A6CB7; Wed, 30 Apr 2008 13:41: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 26A1F28C0E3 for ; Wed, 30 Apr 2008 13:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 MpPr+EmqoNJu for ; Wed, 30 Apr 2008 13:41:34 -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 5674B28C3BE for ; Wed, 30 Apr 2008 13:41:21 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2008 13:41:24 -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 m3UKfOtg024128; Wed, 30 Apr 2008 13:41:24 -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 m3UKfOe9007311; Wed, 30 Apr 2008 20:41:24 GMT Date: Wed, 30 Apr 2008 13:41:23 -0700 (PDT) From: Sri Gundavelli To: "Giaretta, Gerardo" In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5512; t=1209588084; x=1210452084; 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]=20FW=3A=20I-DAction=3Adraft-muha nna-mext-binding-revocation-00.txt |Sender:=20; bh=Oa5IAYfbv29uh6c+WtaM5bdFm2BwZb8Pmnn+2D9BgvQ=; b=VrM1XhXke3eysHHBJyAMTlYlWYyNWNNheylooIHWO61P1c3n+3YnzScvjm IRBkTMEeSI3Abj8GQF1gdn4vLK/0PoQk+UCIDbqkp9d0WBqcUC2MO8QeL292 jRRIvwLcu9; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-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 Gerardo, On Wed, 30 Apr 2008, Giaretta, Gerardo wrote: > I agree this would be a good approach. > > BTW, you are suggesting defining the selectors as additional selectors > for the IPsec SA used for BU/BA, correct? I guess it would not be > acceptable to create a new child SA just for binding revocation > messages. > The messaging, security semantics and the basic transport aspects for generic notification events are provided by the Generic Notification draft. Revocation is another notification message. The reason why its in a new draft, as it requires more focus and need to specify the receiver action. It should not have deal with security semantics, IMO. It just needs to refer to the format from Notification draft, if the WG concensus is to use that format. Sri > Cheers > Gerardo > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of >> Sri Gundavelli >> Sent: Wednesday, April 30, 2008 1:23 PM >> To: Vijay Devarapallli >> Cc: mext >> Subject: Re: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation- >> 00.txt >> >> We need to specify the selectors for the MH type used for >> Generic Notification Msg type. All sub-type extensions >> that are using the Generic Notification Message will be >> within this scope and are not required to deal with the >> security semantics. >> >> Sri >> >> >> >> On Wed, 30 Apr 2008, Vijay Devarapallli wrote: >> >>> Hi Ahmad, >>> >>> One comment on the security considerations section. >>> >>> The protocol described here uses the same security association >>> between the MN and the HA or the MAG and the LMA that has been > used >>> to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when > the >>> session was established. >>> >>> The security association setup between the MN and the HA or between >>> the MAG and the LMA may not be usable for protecting the mobility >>> header message that carries the binding revocation. According to RFC >>> 4877, if fine grain selectors are used, the following will be the > SPD >>> entry on the MN. >>> >>> mobile node SPD-S: >>> - IF local_address = home_address_1 & >>> remote_address = home_agent_1 & >>> proto = MH & local_mh_type = BU & remote_mh_type = BAck >>> Then use SA ESP transport mode >>> Initiate using IDi = user_1 to address home_agent_1 >>> >>> This can only protect the BU/BAck messages, not the new mobility >>> header message that carries the binding revocation messages. >>> >>> So we might need some text in the security considerations section > that >>> says you must negotiate selectors such that the new mobility header >>> message is also included along with the BU/BAck. >>> >>> Or we can define new SPD entries in the binding revocation document >>> (or in the generic notification draft, if we re-use the generic >>> notification messages for binding revocation). >>> >>> Vijay >>> >>> On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna >> wrote: >>>> Hello All, >>>> >>>> Please find the latest Binding Revocation for IPv6 Mobility draft > at >> the >>>> below link. >>>> We highly value your review and comments! >>>> >>>> Many Thanks in advance! >>>> >>>> Best Regards, >>>> Ahmad >>>> >>>> >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org >>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>>> Internet-Drafts@ietf.org >>>> Sent: Tuesday, April 29, 2008 8:30 PM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Binding Revocation for IPv6 Mobility >>>> Author(s) : A. Muhanna, et al. >>>> Filename : > draft-muhanna-mext-binding-revocation-00.txt >>>> Pages : 32 >>>> Date : 2008-04-29 >>>> >>>> This document defines the revocation semantics for terminating a >> mobile >>>> node's mobility session and associated resources. These semantics > are >>>> generic enough and can be used by mobility entities in the case of >>>> Client Mobile IPv6 and its extensions. This mechanism allows the >>>> mobility entity which initiates the revocation procedure to > request >> its >>>> corresponding one to terminate either one, multiple or all > specified >>>> binding cache entries. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding- >> revocatio >>>> n-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 >>> >> _______________________________________________ >> 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 Apr 30 13:49:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E14228C3AD; Wed, 30 Apr 2008 13:49: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 9CEB828C3BE for ; Wed, 30 Apr 2008 13:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 bnnH8QkXDGs5 for ; Wed, 30 Apr 2008 13:49:54 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 482103A6A8B for ; Wed, 30 Apr 2008 13:49:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UKnku04621; Wed, 30 Apr 2008 20:49:46 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 15:47:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcirAA3B5ZXxrjwAQNqMitUI19vutwAAK8/AAAAW10A= References: From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "Sri Gundavelli" , "Vijay Devarapallli" Cc: mext Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-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 Gerardo, That is not a big deal. The confusion is when we want to refer to every message contained under that type MH as generic Notification message and at the same time define a mechanism for that generic notification message, which is defined by a specific subtype. That does not make any sense. Of course, that was the compromise, to define a new subtype field in order to avoid using new MH types. There is no sense what so ever in calling all messages with all different subtypes "generic notification message" while the understanding of the scope of the generic notification message is as "an opaque string of characters" I do not believe that we have a big problem here but we need to specify the scope precisely to avoid confusion. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Giaretta, Gerardo > Sent: Wednesday, April 30, 2008 3:31 PM > To: Sri Gundavelli; Vijay Devarapallli > Cc: mext > Subject: Re: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation-00.txt > > I agree this would be a good approach. > > BTW, you are suggesting defining the selectors as additional > selectors for the IPsec SA used for BU/BA, correct? I guess > it would not be acceptable to create a new child SA just for > binding revocation messages. > > Cheers > Gerardo > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > > Sri Gundavelli > > Sent: Wednesday, April 30, 2008 1:23 PM > > To: Vijay Devarapallli > > Cc: mext > > Subject: Re: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation- > > 00.txt > > > > We need to specify the selectors for the MH type used for Generic > > Notification Msg type. All sub-type extensions that are using the > > Generic Notification Message will be within this scope and are not > > required to deal with the security semantics. > > > > Sri > > > > > > > > On Wed, 30 Apr 2008, Vijay Devarapallli wrote: > > > > > Hi Ahmad, > > > > > > One comment on the security considerations section. > > > > > > The protocol described here uses the same security association > > > between the MN and the HA or the MAG and the LMA that has been > used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > the > > > session was established. > > > > > > The security association setup between the MN and the HA > or between > > > the MAG and the LMA may not be usable for protecting the mobility > > > header message that carries the binding revocation. > According to RFC > > > 4877, if fine grain selectors are used, the following will be the > SPD > > > entry on the MN. > > > > > > mobile node SPD-S: > > > - IF local_address = home_address_1 & > > > remote_address = home_agent_1 & > > > proto = MH & local_mh_type = BU & > remote_mh_type = BAck > > > Then use SA ESP transport mode > > > Initiate using IDi = user_1 to address home_agent_1 > > > > > > This can only protect the BU/BAck messages, not the new mobility > > > header message that carries the binding revocation messages. > > > > > > So we might need some text in the security considerations section > that > > > says you must negotiate selectors such that the new > mobility header > > > message is also included along with the BU/BAck. > > > > > > Or we can define new SPD entries in the binding > revocation document > > > (or in the generic notification draft, if we re-use the generic > > > notification messages for binding revocation). > > > > > > Vijay > > > > > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > > > wrote: > > >> Hello All, > > >> > > >> Please find the latest Binding Revocation for IPv6 > Mobility draft > at > > the > > >> below link. > > >> We highly value your review and comments! > > >> > > >> Many Thanks in advance! > > >> > > >> Best Regards, > > >> Ahmad > > >> > > >> > > >> -----Original Message----- > > >> From: i-d-announce-bounces@ietf.org > > >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > >> Internet-Drafts@ietf.org > > >> Sent: Tuesday, April 29, 2008 8:30 PM > > >> To: i-d-announce@ietf.org > > >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > > >> > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > >> directories. > > >> > > >> Title : Binding Revocation for IPv6 Mobility > > >> Author(s) : A. Muhanna, et al. > > >> Filename : > draft-muhanna-mext-binding-revocation-00.txt > > >> Pages : 32 > > >> Date : 2008-04-29 > > >> > > >> This document defines the revocation semantics for terminating a > > mobile > > >> node's mobility session and associated resources. > These semantics > are > > >> generic enough and can be used by mobility entities in > the case of > > >> Client Mobile IPv6 and its extensions. This mechanism > allows the > > >> mobility entity which initiates the revocation procedure to > request > > its > > >> corresponding one to terminate either one, multiple or all > specified > > >> binding cache entries. > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding- > > revocatio > > >> n-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 > > > > > _______________________________________________ > > 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 Apr 30 17:30:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60E13A6BCF; Wed, 30 Apr 2008 17:30: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 F1CC73A6BB6 for ; Wed, 30 Apr 2008 17:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 el5vk4Of-jqr for ; Wed, 30 Apr 2008 17:30:45 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B94B43A6B1D for ; Wed, 30 Apr 2008 17:30:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m410Uhv27097; Thu, 1 May 2008 00:30:43 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 19:30:22 -0500 Message-ID: In-Reply-To: <4818BEE2.50806@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: Aciq8r2JDxATRDmGQwWtP6LRKbqb/AAIwE0A References: <4818BEE2.50806@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" , "Vijay Devarapallli" Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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, > > I've been talking with Ahmad and Sri about this off-line and > we're trying to come to an agreement over some of the text in > gen-notification to more easily support the revocation draft. > Hopefully an update will be agreeable to everyone, but I > wouldn't necessarily hold-up the current revocation draft for > it. That's my thoughts at least. [Ahmad] Hi Brian, I appreciate your opinion here. I believe it is inline with the original scope of Generic Notification Message which as I said earlier, was clearly presented in Prague IETF meeting as the following: "communicating an opaque string of information". Actually, when I read the latest Generic Notification draft I found several places in the draft which emphasize the original nature and scope of this draft. Here is some examples: 1. 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. 2. This document describes a generic notification message protocol that can be used by Mobile IPv6 entities for sending and receiving simple notification events. [Ahmad: I do not think revocation as described in Binding Revocation for IPv6 Mobility fits under this scope] 3. The Generic Notification message is used by the home agent to notify the mobile node, or vice-versa, that there is an event that requires attention. [Ahmad: clearly in conflict with the Binding Revocation] I respect your opinion and it seems to me that you probably wrote the draft with that in mind. I agree, It makes sense to keep the revocation separate from the Generic Notification Message. This way there is no dependency on the Generic Notification message and there is no worry on making sure that nothing in one draft restrict or limit the other draft functionality. Finally, both can advance independently. In my mind, if a simple functionality as the HA switch message qualify to have a separate MH type why not Binding Revocation? Regards, Ahmad > > -Brian > > Vijay Devarapallli wrote: > > Hi Ahmad and others, > > > > We previously had a discussion on this draft on the MIP6 > mailing list > > and it was agreed that the binding revocation message will be a > > sub-type in the Generic Notification Message. > > > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notificat > > ion-message-00.txt > > > > We would need to modify the generic notification message to > include a > > new 'subtype' field. We had discussed this in the past and made no > > progress. We can start with the following values > > > > 0 - Reserved, not used > > 1 - Notification message indicated by Mobility Options > > 2 - Binding Revocation Indication > > 3 - Binding Revocation Acknowledgement > > 4-255 reserved > > > > The Generic Notification message draft is quite simple and > shouldn't > > take too long to standardize. It would be a good idea to use the > > Generic Notification message as much as possible when you have > > something to notify to either the mobile node or the home agent. > > Otherwise we might end up with a proliferation of notification > > messages using up a lot of mobility header message types. > > > > Vijay > > > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > wrote: > >> Hello All, > >> > >> Please find the latest Binding Revocation for IPv6 > Mobility draft at > >> the below link. > >> We highly value your review and comments! > >> > >> Many Thanks in advance! > >> > >> Best Regards, > >> Ahmad > >> > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >> Internet-Drafts@ietf.org > >> Sent: Tuesday, April 29, 2008 8:30 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > >> > >> A New Internet-Draft is available from the on-line > Internet-Drafts > >> directories. > >> > >> Title : Binding Revocation for IPv6 Mobility > >> Author(s) : A. Muhanna, et al. > >> Filename : > draft-muhanna-mext-binding-revocation-00.txt > >> Pages : 32 > >> Date : 2008-04-29 > >> > >> This document defines the revocation semantics for terminating a > >> mobile node's mobility session and associated resources. These > >> semantics are generic enough and can be used by mobility > entities in > >> the case of Client Mobile IPv6 and its extensions. This > mechanism > >> allows the mobility entity which initiates the revocation > procedure > >> to request its corresponding one to terminate either one, > multiple > >> or all specified binding cache entries. > >> > >> A URL for this Internet-Draft is: > >> > >> > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revoca > >> tio > >> n-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 Apr 30 17:40:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BBC3A67A1; Wed, 30 Apr 2008 17:40: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 7D4D63A67A1 for ; Wed, 30 Apr 2008 17:39: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 xJ12OHv8e5aJ for ; Wed, 30 Apr 2008 17:39:58 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by core3.amsl.com (Postfix) with ESMTP id A87C73A63EC for ; Wed, 30 Apr 2008 17:39:58 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so699968wxd.31 for ; Wed, 30 Apr 2008 17:40: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=9w+IMqy1O/iqvDBKd6mNqp9S9ytACEzpE4He7q+vT28=; b=InQ3CiWTafF3GWwZQ7Gr2NJomPA0lK5BXOGaNohj3t0JM6qBQdGSv5s0jBYtYYTRe6aPuq5gT8ii/WMv2Gqxc3o7RkeJ9iFPFwWTnQ+K3zkbrMoH3jTgibFP1bCbIKBr3KMK7f9+iwVoYDkCXD+yOvXbmQhgnc0yfGoFQzrwhhM= 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=qEMcj2YcCpg6wKrYZMEN/1mbPd17LFQxI0ZeHvoqzF64Vpa0TO56cnNtJ47r8uKz4HvjslHdlkr8GnxAc8LbX0ZNUkoF0IrkJerJp/xjZeFNJzLjc2xxdNL4w6xP20NbZud4Oj8ItxMObMR/b3/Upi9AQMHyziyw9kALqxQnj7A= Received: by 10.143.163.10 with SMTP id q10mr555638wfo.141.1209602400106; Wed, 30 Apr 2008 17:40:00 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Wed, 30 Apr 2008 17:40:00 -0700 (PDT) Message-ID: Date: Wed, 30 Apr 2008 17:40:00 -0700 From: "Vijay Devarapallli" To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4818BEE2.50806@hp.com> Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 Ahmad, Having not been involved on all these discussions offline, its not clear to me why this should be so complicated. Generic notifications messages are just notification messages. Some can be simple event indicators, some can be events like revoking a binding. I am sure the text in the Generic Notification message draft can be fixed to say "simple" or "complicated" events. :) On Wed, Apr 30, 2008 at 5:30 PM, Ahmad Muhanna wrote: > In my mind, if a simple functionality as the HA switch message qualify > to have a separate MH type why not Binding Revocation? Well, the Generic Notification Message draft was written much later. IMO, it would have made sense to use the Generic Notification Message for the HA switch message too, if it was available back then. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 30 18:29:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0D03A68B0; Wed, 30 Apr 2008 18: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 197123A68B0 for ; Wed, 30 Apr 2008 18:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 RS5k5tjM3oFV for ; Wed, 30 Apr 2008 18:29:15 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DC3643A6884 for ; Wed, 30 Apr 2008 18:29:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m411SJJ21304; Thu, 1 May 2008 01:28:19 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 20:29:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcirI+luDxTQoeghQoqRZHWt/nJALQAAFa8Q References: <4818BEE2.50806@hp.com> From: "Ahmad Muhanna" To: "Vijay Devarapallli" Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Wednesday, April 30, 2008 7:40 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Brian Haley; mext; Basavaraj Patil; Sri Gundavelli > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-00.txt > > Hi Ahmad, > > Having not been involved on all these discussions offline, its not > clear to me why this should be so complicated. > > Generic notifications messages are just notification messages. Some > can be simple event indicators, some can be events like revoking a > binding. I am sure the text in the Generic Notification message draft > can be fixed to say "simple" or "complicated" events. :) [Ahmad] Very good. 1. Some of them simple events and some complicated vents. 2. Some Asynchronous and synchronous. 3. Some can be sent HA==>> MN ONLY and some can be sent MN<<==>>HA. 4. some have mobility options only, some have specific fields only, some have specific fields and mobility options, 5. Some is send and forget about it and some MUST be acknowledged with retransmission. What is Generic in all of this? How can we make sure that it is very generic and that there is no conflict? It is absolutely a noble cause to protect the MH type filed. I agree with that. That is probably the only thing generic in all of what we have here. Defining a Generic Mobility Subtype field/header that can be used to define a Generic Notification message and associated mechanism, a Binding Revocation messages and their mechanism, etc is a good thing. However, we need to carefully lay down a very strong foundation for a common work that can be referenced and easily expanded without complication. Also, processing a Mobility Header with a Generic Mobility subtype field/header is nothing but a MH processing which can be captured in a half page. If we follow that, then the scope can be very specific and Revocation for example can reference the Generic Mobility Subtype field/header definition and processing in anywhere without fear of conflict or contradiction. On the other hand, the Generic Notification draft can continue to define a generic notification subtype which can be used to send, for example, a simple event, asynchronous messages, HA<<==>>MN, with or without mobility options, etc. I believe this is the way to have a common solution in order to reduce any possible conflict. I understand that some people fear that if that kind of proposal adopted some work item merely become an IANA number assignment. But, IMO, that is absolutely not true. > > On Wed, Apr 30, 2008 at 5:30 PM, Ahmad Muhanna > wrote: > > > In my mind, if a simple functionality as the HA switch > message qualify > > to have a separate MH type why not Binding Revocation? > > Well, the Generic Notification Message draft was written much later. > IMO, it would have made sense to use the Generic Notification Message > for the HA switch message too, if it was available back then. > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Apr 30 21:14:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDBC3A6973; Wed, 30 Apr 2008 21:14: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 F09F53A6878 for ; Wed, 30 Apr 2008 21:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 wShGylqmBHXr for ; Wed, 30 Apr 2008 21:14:24 -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 EEA8F3A690A for ; Wed, 30 Apr 2008 21:14:23 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 30 Apr 2008 21:14:26 -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 m414EQkG000677; Wed, 30 Apr 2008 21:14:26 -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 m414EQBG002276; Thu, 1 May 2008 04:14:26 GMT Date: Wed, 30 Apr 2008 21:14:26 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <4818BEE2.50806@hp.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1648; t=1209615266; x=1210479266; 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]=20FW=3A=20I-D=20Action=3Adraft-m uhanna-mext-binding-revocation-00.txt |Sender:=20; bh=XPbPN6YfZzZCuAFBbbvOTHt1xaxr1TR9UJq+dpEH0Ro=; b=HJe07QH9gsnzavdjYyH0ylMhmWSS2+EhoX6um1Enav6OBxIXT1HZcUUZfh nEFFdHHm1z/ogSv02m9NvkTgYp4eAqn7tuwiC+gzZXgpPnqRUhF+ahIeG6MB mMY7MZNX8Q; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-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 Wed, 30 Apr 2008, Ahmad Muhanna wrote: > > I believe this is the way to have a common solution in order to reduce > any possible conflict. I understand that some people fear that if that > kind of proposal adopted some work item merely become an IANA number > assignment. But, IMO, that is absolutely not true. > If that some people includes me, I will just say this. I care the least if revocation uses a new MH Type or the sub-type from Generic Message. Forget about the fear part. However, couple of comments: - Revocation message is *just* another notification message. It does not require semantics beyond a simple request/reply message format. It is not a protocol by itself. The value of the spec is in the use-cases and receiver action specifications. - If there is a Notification message that is defined with the generic event properties in mind, we dont want to replicate that for every event. Let that generic behavior be specified in one place, including the security semantics. Keeping the messages to few MH types, will allow to define one set of selectors and even allow firewall admins to properly apply the required filters. - At the end of the day, revocation message needs a message format. It does not diminish or increase the revocation draft value, if it uses its own MH type or a sub-type from Notification message. Bottom line, Bryan or myself, care the least, if this uses a sub-type from Notification draft or not. Do want you think is right, if the WG and the chairs have no issue. I will leave this thread with this note. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext