From mext-bounces@ietf.org Fri Aug 1 02:41:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0113A6D1E; Fri, 1 Aug 2008 02:41: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 E61743A6D1E for ; Fri, 1 Aug 2008 02:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lALvf5xu2tlR for ; Fri, 1 Aug 2008 02:41:10 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A1BF23A6AE2 for ; Fri, 1 Aug 2008 02:41:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D0DF42C00035A; Fri, 1 Aug 2008 11:40:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKhKRIt2h2Ki; Fri, 1 Aug 2008 11:40:04 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A67ED2C000359; Fri, 1 Aug 2008 11:39:54 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 11:39:54 +0200 Message-ID: <547F018265F92642B577B986577D671C22BFDB@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] correspondent router drafts Thread-Index: AcjwPQuL14ksydTaRkm9H43FxTVrtwDeXA8g From: "Roberto Baldessari" To: "Eddy, Wesley M. \(GRC-RCN0\)[VZ]" , Subject: Re: [MEXT] correspondent router 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 All, Thanks to Ryuji for submitting the draft. I agree with Wesley. The issues raised in the draft exist and we need to take them into account, but those issues might not be that relevant in the deployments we are considering. I see the obvious benefits of targeting a general solution, but if a general solution that fitted every scenario was simple to find we would not be talking about specific industry requirements. For example the C2C-CC deployment scenario (draft-ietf-mext-nemo-ro-automotive-req-01) is not that problematic for CR solutions (CR is on the path, 1 CR per CN, static policies can also be used to trigger RO...). I know ISO CALM has a slightly different view on that (see HA switch requirement) and harmonization is needed, but we have some scenarios on the table and I would like to have the issues of proposed solutions compared to the scenario described in the requirement drafts. Ryuji, if you plan to update this draft, would you consider this? Roberto ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Eddy, Wesley M. (GRC-RCN0)[VZ] Sent: Monday, July 28, 2008 1:04 AM To: mext@ietf.org Subject: [MEXT] correspondent router drafts This includes comments on draft-bernardos-mext-nemo-ro-cr-00 and draft-wakikawa-mext-cr-consideration-00. Both of these are great contributions, in my opinion, the first gives a requirement-by-requirement analysis of the CR approach for aero use, that I largely agree with. For the CR solution possibility, I was thinking there would be a small number of CRs with each ANSP, with under a hundred total. I think it would be possible to configure the list of these in an MR initially as a static configuration, and update it using some new message from the HA that informs it of changes to the set of CRs. This would assume that as operational entities bring CRs online or take them offline that they communicate those changes to each other, and the changes would be pushed from the HAs to the MRs. The nice thing about this is that it is much less overhead than trying to have the MR discover CRs itself, or having the CRs somehow discover the MR's traffic, both of which seem doomed to me. The criticisms with the CR approach that Ryuji's draft brings forward are all credible, but I see most of them as more related to general Internet use of the CR approach, rather than specific to aviation. I believe the CR approach is feasible for the aviation world's constraints. HOWEVER, if it doesn't work for other industries, it violates one of our listed "desirable features", so I believe that finding out if CR can be made to work for other industries needs to be explored now. As I understand, the global HAHA approach has some desirability to other (larger) industries, which gives it a major advantage. One idea I had after reading Ryuji's explanation of the problem of selecting an egress CR from a site is that it may be possible to leverage the possibility to aggregate aero IPv6 addresses in order to reduce the impact of routing advertisements for the MNPs. I know at one point Terry Davis was working with ICAO to request an IPv6 allocation to be used for aeronautics, and this block would be cut up between the various stakeholders. It might be possible to have all the MNPs drawn from the same block so that the routes would aggregate. This doesn't totally remove the problem, though, but it may make it simpler. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 1 09:35:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7EB28C102; Fri, 1 Aug 2008 09:35: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 537F03A67A8 for ; Fri, 1 Aug 2008 09:35: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 iO7nL5dBIyxD for ; Fri, 1 Aug 2008 09:35:30 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 52FA328C0E7 for ; Fri, 1 Aug 2008 09:35:30 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1282061and.122 for ; Fri, 01 Aug 2008 09:35: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=RS4EUMz1pFeE5D8SK4pYew/rp356NyMcEYi9WXHKGE0=; b=PxRSACKgO+SHZd+BawjCkq0PFyF9tvMh1LkZ9g9QEbtsYrJ/rqj3kJ7A/7VIv6LbIW 1sKLIkhgVYBuErroIhblyrRQ+WdjxeeUUCU8WmcFZVMbRtGYWbb4XPSwYYN2LoBFCLzS pUQw/pZBCSP01kQvWh2D7+S2T8X21NFWp6zi4= 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=wXFRsReDGP6dqesn7Mu/P2j/GzpY1gedMUcH8hCZ1rKq//ZpKjNU2jN5BWu/KS67R4 5Pxw0hVc7jvj7Bu/YP4PMFgETvyL6qENRxbOOlPAjN7QpgYX3tJsCcGGszutUyNN5Mx7 e57n73mNtUOfzszzyYDNVBN+jzuXm2QzCSaGA= Received: by 10.100.10.11 with SMTP id 11mr16868023anj.94.1217608549212; Fri, 01 Aug 2008 09:35:49 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Fri, 1 Aug 2008 09:35:49 -0700 (PDT) Message-ID: Date: Fri, 1 Aug 2008 09:35:49 -0700 From: "fan zhao" To: "Mohamed Khalil" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200807311459.15169.julien.IETF@laposte.net> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I agree with the room consensus. Sincerely, fan On Thu, Jul 31, 2008 at 7:07 AM, Mohamed Khalil wrote: > > I am ok that binding revocation will use directly the MH and allocates > its own MH types values. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Thursday, July 31, 2008 7:59 AM > To: mext@ietf.org; marcelo bagnulo braun > Subject: [MEXT] Consensus call: Binding revocation will NOT use GSM > > > Folks, > > During the 2nd MEXT session, there was consensus amongst the session > attendees that Binding Revocation shall NOT use the GSM framework. > Rather, the consensus was that binding revocation shall use directly > the mobility header and allocates its own MH types values. > > Hereby we'd like to confirm that room consensus on the mailing list. If > you haven't expressed an opinion during the session, please send a note > to the list stating whether you agree or disagree with that room > consensus by 2008-08-14. > > -- julien & marcelo, MEXT chairs > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 1 18:31:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D817528C19E; Fri, 1 Aug 2008 18:31: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 BDF8A28C194 for ; Fri, 1 Aug 2008 18:31:44 -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 gHLo1ITIjlZj for ; Fri, 1 Aug 2008 18:31:44 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by core3.amsl.com (Postfix) with ESMTP id D521428C137 for ; Fri, 1 Aug 2008 18:31:43 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so669876pyg.24 for ; Fri, 01 Aug 2008 18:31:37 -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=ILCKAULLSa7bM7tJyvUg2Sf4438IlnXuFtwL3gErQow=; b=SMh9djR2BnYu35dXE6jgbMXfewGi0OIWPZ/uu0IIoqGltBuG8yU9dXqv+hPiZJWaBB n5iOXJj3ZcWOUFgoJR8St2m1+LqUPicbZjOKUx7yTsXb5t2hMfDxGTcXRU5QEZ49wLxH DQjYM8VV65+ZyenL7m47WhWD4sXaw9nn2hmIo= 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=L14sGaXhjiF/v8pS0lLhxlyom8x4rR5cQrIxAKggbFkrasgabyUuQUDYES8nzgCgaA ctMXQYisYaj9LOgml4AI89Up0iEyWedn821RTUu9h5KIVYlb6aI5uSO3juZrc7MMgt9R eGnaX02iApOvZclLLocehOvs0woJse3sMWrl8= Received: by 10.64.233.12 with SMTP id f12mr1778457qbh.77.1217640696603; Fri, 01 Aug 2008 18:31:36 -0700 (PDT) Received: from ?172.16.0.127? ( [207.237.5.3]) by mx.google.com with ESMTPS id s12sm4405431qbs.9.2008.08.01.18.31.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Aug 2008 18:31:35 -0700 (PDT) From: Ryuji Wakikawa To: Julien Laganier In-Reply-To: <200807311459.15169.julien.IETF@laposte.net> References: <200807311459.15169.julien.IETF@laposte.net> Message-Id: <4A54DC23-58F5-4042-B555-A51F8427F632@gmail.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sat, 2 Aug 2008 10:31:34 +0900 X-Mailer: Apple Mail (2.928.1) Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien and Marcelo, I was not in the room at the consensus call, because I had a presentation in the ROLL meeting. I agree. Binding revocation SHOULD use own MH type. regards, ryuji On 2008/07/31, at 21:59, Julien Laganier wrote: > Folks, > > During the 2nd MEXT session, there was consensus amongst the session > attendees that Binding Revocation shall NOT use the GSM framework. > Rather, the consensus was that binding revocation shall use directly > the mobility header and allocates its own MH types values. > > Hereby we'd like to confirm that room consensus on the mailing list. > If > you haven't expressed an opinion during the session, please send a > note > to the list stating whether you agree or disagree with that room > consensus by 2008-08-14. > > -- julien & marcelo, MEXT chairs > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 4 01:01:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF6C3A68C6; Mon, 4 Aug 2008 01:01: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 2DC4B3A68C6 for ; Mon, 4 Aug 2008 01:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 feS7JE9XLico for ; Mon, 4 Aug 2008 01:01:19 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 5E13F3A6896 for ; Mon, 4 Aug 2008 01:01:19 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1644363rvf.49 for ; Mon, 04 Aug 2008 01:01: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:mime-version:content-type; bh=hB2VTeUxAMeGUwmWIFbDyM5+6flPA01zk005UBDt8AA=; b=nTRD9dZOn35djX4FTGEBx1euMaPRxs/uWZwYHiAouE4eXiI9fJlTWRRQxwNgSKbh3S /ddl1d+a9tVYWxl3ZLJ4Fdr1loIe0c1jKEBcubJ+2/tgWjO1h0HfeO5tAtuuxiH6DwHe bM9fKAYorBeZefsZ5j+shoS31IFch6ym3jM2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=iyCbzRERuIMqi2TK753xmSO5BJXLpP+r35kQPAH4aGcF2zMeLyLf1WdpB5m2QRS3CI F6pbFNpp71GPA83Gwe1DS3ExStgnlk+78Tx91Rp6swa1Pr3yB8H/G8cMud+Pt165fkdY dJaVovMs4b9zgMrV/VR/o8hmwBdYRaB8RLwYE= Received: by 10.141.129.14 with SMTP id g14mr7399878rvn.50.1217836877248; Mon, 04 Aug 2008 01:01:17 -0700 (PDT) Received: by 10.141.141.10 with HTTP; Mon, 4 Aug 2008 01:01:17 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2008 13:31:17 +0530 From: Sandesh To: mext@ietf.org MIME-Version: 1.0 Subject: [MEXT] A comment on draft-ietf-mext-binding-revocation-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: multipart/mixed; boundary="===============0880665298==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0880665298== Content-Type: multipart/alternative; boundary="----=_Part_17687_17802589.1217836877241" ------=_Part_17687_17802589.1217836877241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, IMO following case is possible with PMIPv6 protocol defined in http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00 and http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-18 lt = lifetime eth0 is the interface og MAG to the LAN in which MN1 is present. MAG has another interface eth1 through which it is connected to LMA. MN1 ---- eth0 MAG eth1 -------LMA MAG LMA | | | | | | eth0 down | | |\ BRI(G) | eth0 up | \ | (MN1 attaches)| \ PBU(lt!=0)| |----------------->| | \ +-------| | \ / | | +----------->| | / +-------| | BRA / / | |<----/--+ | | / | | / | |<-+ | | PBA | (BUL entry for MN1) (no BCE MN1) Reason - 1. As per these drafts BRI and PBU has their own (independent) sequence numbers. 2. BRI/BRA does not have timestamp option. 3. These drafts do not say that PBU cannot be sent if MAG has already sent BRI(G) to LMA. 4. In IP network missequencing of packets is possible. Thanks and Regards, Sandesh ------=_Part_17687_17802589.1217836877241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,

IMO following case is possible with PMIPv6 protocol
defined in http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00
and http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-18

lt = lifetime
eth0 is the interface og MAG to the LAN in
which MN1 is present. MAG has another
interface eth1 through which it is connected to LMA.

MN1 ---- eth0 MAG eth1 -------LMA


            MAG                LMA
             |                  |
             |                  |
             |                  |
 eth0 down   |                  |
             |\ BRI(G)          |
 eth0 up     | \                |
(MN1 attaches)|  \     PBU(lt!=0)|
             |----------------->|
             |   \      +-------|
             |    \    /        |
             |     +----------->|
             |       /  +-------|
             | BRA  /  /        |
             |<----/--+         |
             |    /             |
             |   /              |
             |<-+               |
             | PBA              |
(BUL entry for MN1)           (no BCE MN1)

Reason -
1. As per these drafts BRI and PBU has their own
  (independent) sequence numbers.
2. BRI/BRA does not have timestamp option.
3. These drafts do not say that PBU cannot be sent
  if MAG has already sent BRI(G) to LMA.
4. In IP network missequencing of packets is possible.

Thanks and Regards,
Sandesh
------=_Part_17687_17802589.1217836877241-- --===============0880665298== 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 --===============0880665298==-- From mext-bounces@ietf.org Mon Aug 4 02:24:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E336F3A6A43; Mon, 4 Aug 2008 02:24: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 819F73A6A43 for ; Mon, 4 Aug 2008 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, 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 7KexwkO4lbgN for ; Mon, 4 Aug 2008 02:24:42 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id A4C573A6768 for ; Mon, 4 Aug 2008 02:24:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1665754rvf.49 for ; Mon, 04 Aug 2008 02:25:10 -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:mime-version:content-type:content-transfer-encoding :content-disposition; bh=wNlGBbj/YHanZSaFpZfmO2xjOqFu3xnDL5yDmzaWtwM=; b=HiPRemGk8O7dQfmh2NNk4Li83MFKJO0Jm4I5WIDxcdz/hV5Jm4t3+L9oJhoUP3XP/C GmX3ntbD0F6JEt0thS8T5IunQlnO62B+PRHnY5cKS/JReY8qIxZfJ2BVRl3ZPfnmTRxC VPFr84DaWlFTHMKf7jtrLxysYYk8aUOHvhRnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=k0m/Tb8g2oSbWeMABAXC7Z7KamS+cvVUnkjTRRxS6rhCeVMl8/bZjtqSmztRlwcPM0 A4hg8p58ZTc00khDE696HrlBsPzMsQyXDxLd1EjJAQTed0c/xVbR+8hT67RFWV3/gFU3 DHwnGz1daywipzjeWC2IV9gSXJ+ApVFFwxS7U= Received: by 10.141.170.10 with SMTP id x10mr7429427rvo.221.1217841910356; Mon, 04 Aug 2008 02:25:10 -0700 (PDT) Received: by 10.141.141.10 with HTTP; Mon, 4 Aug 2008 02:25:10 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2008 14:55:10 +0530 From: Sandesh To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I was going through the draft draft-ietf-mext-binding-revocation-00.txt (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00) I have following queries/comments - 1.------------------------- There should a provision to bring a binding administratively DOWN/UP revoke/unrevoke mechanism without deleing entry from in BUL/BC. Administrator (at LMA or MAG) can use this to prohibit a MN from using a PMIv6 for some time (without deleting entry from in BUL/BC). This provision can be useful during testing/maintenance. 1.------------------------- If administrator at LMA revokes a binding (does a revoke administrative action) (I would call is bringing binding administratively down) in this case a BRI message is sent to MAG (and BRA received in return). If after some time the same administrator unrevokes the binding (i.e. and makes this binding administratively up) Option 1: In this case should there be message which LMA can send to MAG to indicate that MAG can send PBU to register the MN binding with LMA. OR Option 2: When binding is administratively down MAG keeps on transmitting PBU and LMA replies PBA with status = Administratively prohibited. MAG keeps on sending PBU until LMA responds with PBA (status = 0) 2.------------------------- IMHO this draft should include the changes for 'IPv4 Support for Proxy Mobile IPv6' also. i.e. In the sections related to MAG and LMA there should be mention of IPv4 home address also. 3.------------------------- Section 8.2.2. 4th bullet s/The local mobility MAY set/The local mobility anchor MAY set 4.------------------------- Section 8.2.2. 4th bullet It would be good if few cases of 'partial success' can be mentioned. 5.------------------------- Section 9.2.2 It would be good if few guidelines can added for the case when MAG receives BRA (status = partial success) 6.------------------------- As per section 9.2.1 MAG will always set A bit in BRI message which it sends to LMA Following lines gives an impression that that there may be some case in which MAG sends BRI without setting A bit. IMHO following line of section 3.1 should be modified to reflect the spirit of section 9.2.1. "If the local mobility anchor processes the BRI message successfully and the (A) bit is set in the BRI, the local mobility anchor responds to the mobile access gateway by sending a BRA message. Thanks and Regards, Sandesh Kumar Sodhi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From unforgeable@elkfest.org Mon Aug 4 06:31: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 747E828C270 for ; Mon, 4 Aug 2008 06:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.501 X-Spam-Level: **** X-Spam-Status: No, score=4.501 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNBhaUgp1Ysz for ; Mon, 4 Aug 2008 06:31:43 -0700 (PDT) Received: from commandsoftware.plus.com (commandsoftware.plus.com [81.174.165.101]) by core3.amsl.com (Postfix) with SMTP id 8ECFE3A684B for ; Mon, 4 Aug 2008 06:31:43 -0700 (PDT) Date: Mon, 04 Aug 2008 13:32:10 +0000 From: "Dizer Vanatta" X-Mailer: The Bat! (3.5.31) Professional Reply-To: Dizer Vanatta X-Priority: 3 (Normal) Message-ID: <1793181563.20080804132319@elkfest.org> To: Subject: :o) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------9C5F05C87B302A" ------------9C5F05C87B302A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Bonjour, =20 =20 =20 ------------9C5F05C87B302A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =09 =20 =09

Bonjour,


=09
Vf I =09A G jR nA

=09
WWW.BUMAM.COM

------------9C5F05C87B302A-- From mext-bounces@ietf.org Mon Aug 4 10:18:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9073A6BFB; Mon, 4 Aug 2008 10:18: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 C6BEE3A6BFB for ; Mon, 4 Aug 2008 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_32=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 Ro9kyySeEk1k for ; Mon, 4 Aug 2008 10:18:19 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 618443A6B50 for ; Mon, 4 Aug 2008 10:18:19 -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 m74HFpp00022; Mon, 4 Aug 2008 17:15:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 12:15:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] A comment on draft-ietf-mext-binding-revocation-00 Thread-Index: Acj2CGA0e9muQ2FaR5KKrs0XlZFgRgAR7lQQ References: From: "Ahmad Muhanna" To: "Sandesh" , Subject: Re: [MEXT] A comment on draft-ietf-mext-binding-revocation-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 Sandesh, Thanks for reviewing the draft. Let me try to address your concern. It seems to me that sending a BRI with (G) bit when the eth0 goes down, is a MAG local policy and we can not specify that kind of behavior in the draft. I personally believe that the use of the (G) bit should be taken more carefully. In reality, the MAG implementation should use the (G) bit more responsibly or let me say with a clear understanding of its consequences. The intent was to allow the MAG to delete all sessions with a specific LMA for a scheduled maintenance which may take sometime. In your case, the use of the (G) bit may cause the network a problem by introducing an unnecessary signaling traffics. If an implementation would like to use the (G) bit in a less restrictive manner, then I believe that implementation should make sure that its use does not create new complexity or a corner case race condition as you mentioned. In other words, since there is a possibility for eth0 to go up and down relatively quickly, then an implementation should take that in consideration if it decides to send a BRI with the (G) bit for such a case. IMO, that is an implementation decision. Finally, what we could clarify in the draft is to say something like: When the (G) bit is set, the revoking node SHOULD wait for the BRA or exhaust all retransmits before deleting the associated mobile nodes bindings. Will think of some cautious text to add to the LMA behavior in the case when the Revocation Trigger is "Per-Local Policy". Regards, Ahmad ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sandesh Sent: Monday, August 04, 2008 3:01 AM To: mext@ietf.org Subject: [MEXT] A comment on draft-ietf-mext-binding-revocation-00 Hi All, IMO following case is possible with PMIPv6 protocol defined in http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00 and http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-18 lt = lifetime eth0 is the interface og MAG to the LAN in which MN1 is present. MAG has another interface eth1 through which it is connected to LMA. MN1 ---- eth0 MAG eth1 -------LMA MAG LMA | | | | | | eth0 down | | |\ BRI(G) | eth0 up | \ | (MN1 attaches)| \ PBU(lt!=0)| |----------------->| | \ +-------| | \ / | | +----------->| | / +-------| | BRA / / | |<----/--+ | | / | | / | |<-+ | | PBA | (BUL entry for MN1) (no BCE MN1) Reason - 1. As per these drafts BRI and PBU has their own (independent) sequence numbers. 2. BRI/BRA does not have timestamp option. 3. These drafts do not say that PBU cannot be sent if MAG has already sent BRI(G) to LMA. 4. In IP network missequencing of packets is possible. Thanks and Regards, Sandesh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 4 12:10:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389323A68F2; Mon, 4 Aug 2008 12:10: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 BD22E3A6850 for ; Mon, 4 Aug 2008 12:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3cdc0q1K-lo for ; Mon, 4 Aug 2008 12:10:33 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 419CC3A69D3 for ; Mon, 4 Aug 2008 12:10:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m74JAwj25464; Mon, 4 Aug 2008 19:10:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 14:10:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft Thread-Index: Acj2FAzzXvScT+1GSaeLzHkNXel1PwAQo7YQ References: From: "Ahmad Muhanna" To: "Sandesh" , Subject: Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sandesh, Thanks again. Please see inline. Regards, Ahmad > Subject: [MEXT] Queries/comments on 'Binding Revocation for > IPv6 Mobility' draft > > Hi, > > I was going through the draft > draft-ietf-mext-binding-revocation-00.txt > (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00) > > I have following queries/comments - > > > 1.------------------------- > There should a provision to bring a binding administratively > DOWN/UP revoke/unrevoke mechanism without deleing entry from > in BUL/BC. > Administrator (at LMA or MAG) can use this to prohibit a MN > from using a PMIv6 for some time (without deleting entry from > in BUL/BC). > This provision can be useful during testing/maintenance. [Ahmad] If the MN needs to be revoked for sometime, why do we need to keep its BCE. It seems to me that one of the most important functionality that Binding Revocation is trying to do is to help mobility nodes clear resources and avoid stale sessions. May be you can elaborate more to understand what you are trying to do. > > 1.------------------------- > If administrator at LMA revokes a binding (does a revoke > administrative > action) (I would call is bringing binding administratively > down) in this case a BRI message is sent to MAG (and BRA > received in return). > > If after some time the same administrator unrevokes the > binding (i.e. and makes this binding administratively up) [Ahmad] What is your definition of this administrative up and administrative down events. When the MN Binding is revoked for administrative reason, the MN is no longer allowed to receive mobility service. If that the case, then there is no need to keep the BCE around. > > Option 1: > In this case should there be message which LMA can send to > MAG to indicate that MAG can send PBU to register the MN > binding with LMA. > > OR > Option 2: > When binding is administratively down MAG keeps on > transmitting PBU and LMA replies PBA with status = > Administratively prohibited. > MAG keeps on sending PBU until LMA responds with PBA (status = 0) [Ahmad] I seem to have difficulties with the logic here. If the MN session is revoked for administrative reason, all resources associated with the MN session are deleted. If the MN tries to access the network again, the MN should not be allowed to receive PMIPv6 mobility services unless the Mobile node is authorized to receive PMIPv6 which is communicated to the MAG during access authentication. As per PMIPv6 base protocol, the MAG receives the MN profile and also if the MN is allowed for PMIPv6 service or not. Therefore, both options above are not applicable. > > > 2.------------------------- > IMHO this draft should include the changes for > 'IPv4 Support for Proxy Mobile IPv6' also. > i.e. > In the sections related to MAG and LMA there should be > mention of IPv4 home address also. [Ahmad] Okay. I will make sure that we mention the IPv4 address. Although, that is independent of the BRI process. If a BCE is revoked all resources are removed including the IPv4 Home address. > > 3.------------------------- > Section 8.2.2. 4th bullet > s/The local mobility MAY set/The local mobility anchor MAY set [Ahmad] Ok, thx. > > 4.------------------------- > Section 8.2.2. 4th bullet > It would be good if few cases of 'partial success' can be mentioned. [Ahmad] I believe the text is generic and applicable. Do you have a case that is not addressed by the current text? > > 5.------------------------- > Section 9.2.2 > It would be good if few guidelines can added for the case > when MAG receives BRA (status = partial success) [Ahmad] Like what? > > 6.------------------------- > As per section 9.2.1 MAG will always set A bit in BRI message > which it sends to LMA Following lines gives an impression > that that there may be some case in which MAG sends BRI > without setting A bit. > IMHO following line of section 3.1 should be modified to > reflect the spirit of section 9.2.1. > "If the local mobility anchor processes the BRI message > successfully and the (A) bit is set in the BRI, the local > mobility anchor responds to the mobile access gateway by > sending a BRA message. [Ahmad] The intent is to mandate the MAG to set the (A) bit whenever the (G) bit is set. We will try to clarify the text. > > Thanks and Regards, > Sandesh Kumar Sodhi > _______________________________________________ > MEXT mailing 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 Aug 4 22:24:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D8D3A6A99; Mon, 4 Aug 2008 22:24:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B723A6AD4 for ; Mon, 4 Aug 2008 22:24:52 -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_05=-1.11, 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 l2FAyKg+59cJ for ; Mon, 4 Aug 2008 22:24:51 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B65273A6801 for ; Mon, 4 Aug 2008 22:24:35 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m755OUhY027123 for ; Tue, 5 Aug 2008 14:24:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m755OUY26161 for ; Tue, 5 Aug 2008 14:24:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id m755OTT04792 for ; Tue, 5 Aug 2008 14:24:30 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 13:22:41 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 05 Aug 2008 13:22:38 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 05 Aug 2008 13:22:38 +0800 From: "Benjamin Lim" To: Date: Tue, 5 Aug 2008 13:22:38 +0800 Message-ID: <0A6EE6AEB01546768889F5F30C55930A@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acj2u0ZsnUTlG3WSQmCio8d08vWW3g== X-OriginalArrivalTime: 05 Aug 2008 05:22:41.0410 (UTC) FILETIME=[48673620:01C8F6BB] Subject: [MEXT] [RFC3775-update] HA loop threat X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 am unable to ticket this issue on issue list (no permission to create new ticket), so I place proposed text in the ML. Propose to add some text in the security consideration section to highlight such risk of routing loop among HAs. Target section is section 15.1. under "Threats involving Binding Updates sent to home agents and correspondent nodes." Old text ---------- None New text ---------- A malicious mobile node associated to multiple home agents could create a routing loop amongst them. This can be achieved when a mobile node binds one home address located on a first home agent to another home address on a second home agent. This type of binding will force the home agents to route the same packet among each other without knowledge that a routing loop has been created. Such looping problem is limited to cases where a mobile node has multiple home agents. One possible deployment that may encounter such issue is the 3GPP System Architecture Evolution (SAE), where it permits a mobile device to be associated to multiple home agents. These home agents differentiate the different packet networks that the mobile device has association to (e.g. home, office). For the single home agent case, a policy at the home agent would prevent the binding of one home address to another home address hosted by the same home agent. Motivation ---------- This threat will force HAs to route the same packet among each other without knowledge that a routing loop has been created, thus consuming the resources of the home agents. If launched in full scale (e.g. multiple sets of home addresses), this might 'shut down' the HA and affect the network. Hence, the proposal is to document it to allow people to have some knowledge such an issue may occur. Regards, Benjamin Lim _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Aug 5 10:00:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A221F3A6A48; Tue, 5 Aug 2008 10:00: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 E4E613A6A8A for ; Tue, 5 Aug 2008 10:00:35 -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.001, 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 bpYFhT6yiWRb for ; Tue, 5 Aug 2008 10:00:35 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id AF4F53A68B2 for ; Tue, 5 Aug 2008 10:00:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 255E5EC89E; Wed, 6 Aug 2008 02:00:54 +0900 (JST) Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id B6FE5EC87D; Wed, 6 Aug 2008 02:00:53 +0900 (JST) Received: from [127.0.0.1] (c015.vpn.kddilabs.jp [172.19.87.15]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id DD2F31BAAA; Wed, 6 Aug 2008 01:58:38 +0900 (JST) Message-ID: <48988700.8070302@kddilabs.jp> Date: Wed, 06 Aug 2008 01:59:44 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Julien Laganier References: <200807311459.15169.julien.IETF@laposte.net> In-Reply-To: <200807311459.15169.julien.IETF@laposte.net> X-Virus-Scanned: by amavisd-new Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I agree that the Binding Revocation massage should directly use the mobility header. I also think that we should better create a rough guideline about when to use the GSM framework. For example, if the meaning of the message is not directly related to mobility (e.g. policy, user profile, encapsulating other messages, etc.) or is limited to a specific context (e.g. SDO dependent), then GSM should be used, or something like that. This type of guideline does not have to be documented, but at least we should have a common understanding to avoid further confusion. Regards, -- Hidetoshi Julien Laganier wrote: > Folks, > > During the 2nd MEXT session, there was consensus amongst the session > attendees that Binding Revocation shall NOT use the GSM framework. > Rather, the consensus was that binding revocation shall use directly > the mobility header and allocates its own MH types values. > > Hereby we'd like to confirm that room consensus on the mailing list. If > you haven't expressed an opinion during the session, please send a note > to the list stating whether you agree or disagree with that room > consensus by 2008-08-14. > > -- julien & marcelo, MEXT chairs > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 6 04:38:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED90F3A6BF9; Wed, 6 Aug 2008 04:38: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 6BC053A6C01 for ; Wed, 6 Aug 2008 04:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=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 yqVQAYWeAgnR for ; Wed, 6 Aug 2008 04:38:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 49AA03A6BF9 for ; Wed, 6 Aug 2008 04:38:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2630289rvf.49 for ; Wed, 06 Aug 2008 04:39:07 -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=4Uvqm+rq/t1+/ONJsUslTHol0Mlav/gcAkvXFEMd4bY=; b=IW2QhsgPijuSk1U5RCtudz0WEUMFfD2hhNde9l+BbdT3d91bcpF5fWw+xHCXxvit6c iCE/qOSTl1X8kmo6hAyn7VgeuF07hJ8OQtyV+RnHHgWv96YxQg9tjn27RfnRst6DsjBP Od2hvPou29+IKfhk7a3GM1gHvNekR7BIm14Ak= 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=NZETQxJRxXOBHOHAk0k86HzhqX2RhkoVjRVGYusdw8rm+TDllHkGr6qitIcRQXYxhK TbxTSY7J7i2u9BXlo8SUcrqyQXXszlPPS5yRCueag3x/F1OvbUuBzmt8mUcGyxGNWo72 wP9JvS7xjWF7ny2jYKBP63en6AcF4bqdTh3jw= Received: by 10.141.198.9 with SMTP id a9mr8819991rvq.108.1218022747662; Wed, 06 Aug 2008 04:39:07 -0700 (PDT) Received: by 10.141.116.11 with HTTP; Wed, 6 Aug 2008 04:39:07 -0700 (PDT) Message-ID: Date: Wed, 6 Aug 2008 17:09:07 +0530 From: Sandesh To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, My few thoughts inline (marked with [SANDESH]). Thanks and Regards, Sandesh Kumar Sodhi -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com] Sent: Tuesday, August 05, 2008 12:41 AM To: Sandesh; mext@ietf.org Subject: RE: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft Hi Sandesh, Thanks again. Please see inline. Regards, Ahmad > Subject: [MEXT] Queries/comments on 'Binding Revocation for > IPv6 Mobility' draft > > Hi, > > I was going through the draft > draft-ietf-mext-binding-revocation-00.txt > (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00) > > I have following queries/comments - > > > 1.------------------------- > There should a provision to bring a binding administratively DOWN/UP > revoke/unrevoke mechanism without deleing entry from in BUL/BC. > Administrator (at LMA or MAG) can use this to prohibit a MN from using > a PMIv6 for some time (without deleting entry from in BUL/BC). > This provision can be useful during testing/maintenance. [Ahmad] If the MN needs to be revoked for sometime, why do we need to keep its BCE. It seems to me that one of the most important functionality that Binding Revocation is trying to do is to help mobility nodes clear resources and avoid stale sessions. May be you can elaborate more to understand what you are trying to do. ~~~~~~~~~~~~~ [SANDESH] I agree with the you that BRI provides a useful facility to remove BCE for stale sessions. This is a desirable functionality. IMO it is also desirable to have an administrative interface which can disable/enable a particular binding for sometime without deleting BUL/BCE. The session is not stale. It is just that we don't want to allow any data traffic/Signalling for that MN for testing/maintenance activity without the involvement if AAA server (Please see my next comment). I would like to compare this feature of binding revocation to link inhibit/uninhibit in SS7. When a link is inhibited data structures for the particular link are not removed but particular link is marked inhibited so that no traffic goes on that link. ~~~~~~~~~~~~~ > > 1.------------------------- > If administrator at LMA revokes a binding (does a revoke > administrative > action) (I would call is bringing binding administratively > down) in this case a BRI message is sent to MAG (and BRA received in > return). > > If after some time the same administrator unrevokes the binding (i.e. > and makes this binding administratively up) [Ahmad] What is your definition of this administrative up and administrative down events. When the MN Binding is revoked for administrative reason, the MN is no longer allowed to receive mobility service. If that the case, then there is no need to keep the BCE around. > > Option 1: > In this case should there be message which LMA can send to MAG to > indicate that MAG can send PBU to register the MN binding with LMA. > > OR > Option 2: > When binding is administratively down MAG keeps on transmitting PBU > and LMA replies PBA with status = Administratively prohibited. > MAG keeps on sending PBU until LMA responds with PBA (status = 0) [Ahmad] I seem to have difficulties with the logic here. If the MN session is revoked for administrative reason, all resources associated with the MN session are deleted. If the MN tries to access the network again, the MN should not be allowed to receive PMIPv6 mobility services unless the Mobile node is authorized to receive PMIPv6 which is communicated to the MAG during access authentication. As per PMIPv6 base protocol, the MAG receives the MN profile and also if the MN is allowed for PMIPv6 service or not. Therefore, both options above are not applicable. ~~~~~~~~~~~~~ [SANDESH] Policy of an MN is present in the AAA sever and BCE is present in LMA. Does revocation of binding at LMA means - 'marking MN unauthorized in AAA server' AND 'revoking MN binding at LMA' If above is the definition of binding revocation then, if AAA server and LMA are independent servers controlled by different companies, then binding revocation would involve interaction with both AAA server and LMA which might be undesirable in some case. (e.g when AAA server administarator and LMA administrator are not the same person). Also 'marking MN unauthorized in AAA server' needs to be done before 'revoking MN binding at LMA' for the following reason - If 'revoking MN binding at LMA' done first and after that 'marking MN unauthorized in AAA server' is done then following race condition might occur - 1. 'revoking MN binding at LMA' is done at LMA 2. BRI/BRA has been exchanged 3. MN attaches to MAG 4. PBU/PBA gets exchanged before - 5. 'marking MN unauthorized in AAA server' Can we define two types of binding revocation - i. DELETE REVOCATION (revocation defined in the draft) - Mark MN unauthorized for PMIPv6 service in AAA server. Initiate BRI+BRA exchange with MAG. LMA removes BCE. MAG removes BUL entry. LMA and MAG removes data tunnel for the MN. This involves interaction with AAA server. ii. LOCAL REVOCATION - Initiate BRI+BRA exchange. BRI, BRA can carry flag indicating 'local revocation'. LMA marks BCE 'revoked'( i.e. administratively down). MAG marks BUL entry 'revoked' (i.e. administratively down). This does not involve interaction with AAA server. If BUL entry is marked 'revoked' MAG shall not query AAA server for authorization. The binding can be unrevoked by another message exchange between LMA and MAG (say BINDING UNREVOKE + BINDING UNREVOKE ACK) I hope I make some sense here. ~~~~~~~~~~~~~~ > 4.------------------------- > Section 8.2.2. 4th bullet > It would be good if few cases of 'partial success' can be mentioned. [Ahmad] I believe the text is generic and applicable. Do you have a case that is not addressed by the current text? ~~~~~~~~~~~~~ [SANDESH] Could you please let me know few cases in which LMA/MAG may be unable to revoke a binding. IMO the LMA/MAG in all cases should be able to at least set one flag to indicate for the binding is revoked and prohibit that binding from being used until that binding is physically deleted. Does partial success include the case when BCE at LMA or BUL entry at MAG is deleted but data tunnel for that link is not deleted for some reason or the other way around. Is such a case allowed for binding revocation. It would be helpful for me if you can tell the thought process which led to addition of this 'partial success' status to draft. ~~~~~~~~~~~~~ > > 5.------------------------- > Section 9.2.2 > It would be good if few guidelines can added for the case when MAG > receives BRA (status = partial success) [Ahmad] Like what? ~~~~~~~~~~~~~ [SANDESH] The draft mentions that handling of BRA(status = partial success) is defined by LMA's local policy (Section 9.1.1. Third bullet). For MAG the draft does not seem to be mentioning anything. Some guideline (which you feel makes more sense) for actions which can be taken after receiving BRA(status = partial success) can be provided in the draft itself. This guideline will make the draft rich in content. One example guideline which I can think of is - LMA/MAG may choose maintain a 'RevokeTryCounter' per binding initially set to 0. If BRA indicates MAG/LMA is unable to revoke the binding then the counter can be incremented. LMA/MAG retries for 'MaxRevocationTries' and then can delete BCE/revoke binding. (This is similar to BRIMaxRetransmitNumber) ~~~~~~~~~~~~~ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Aug 7 07:00:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB9D3A6A70; Thu, 7 Aug 2008 07:00: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 5679428C184 for ; Thu, 7 Aug 2008 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=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 0sA7lL015WMp for ; Thu, 7 Aug 2008 07:00:13 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A51463A6901 for ; Thu, 7 Aug 2008 07:00:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m77E0iP05186; Thu, 7 Aug 2008 14:00:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 09:00:30 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft Thread-Index: Acj3uQ2XSI8P1b3DQ5+l9+eTcwvY3gAIQouw References: From: "Ahmad Muhanna" To: "Sandesh" Cc: mext@ietf.org Subject: Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sandesh, It is always appreciated to receive comments from people who actually design and implement the protocol! Please see inline. Regards, Ahmad > > Subject: [MEXT] Queries/comments on 'Binding Revocation for > > IPv6 Mobility' draft > > > > Hi, > > > > I was going through the draft > > draft-ietf-mext-binding-revocation-00.txt > > (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00) > > > > I have following queries/comments - > > > > > > 1.------------------------- > > There should a provision to bring a binding > administratively DOWN/UP > > revoke/unrevoke mechanism without deleing entry from in BUL/BC. > > Administrator (at LMA or MAG) can use this to prohibit a MN > from using > > a PMIv6 for some time (without deleting entry from in BUL/BC). > > This provision can be useful during testing/maintenance. > > [Ahmad] > If the MN needs to be revoked for sometime, why do we need to > keep its BCE. It seems to me that one of the most important > functionality that Binding Revocation is trying to do is to > help mobility nodes clear resources and avoid stale sessions. > May be you can elaborate more to understand what you are trying to do. > > ~~~~~~~~~~~~~ > [SANDESH] > I agree with the you that BRI provides a useful facility to > remove BCE for stale sessions. This is a desirable functionality. > > IMO it is also desirable to have an administrative interface > which can disable/enable a particular binding for sometime > without deleting BUL/BCE. The session is not stale. It is > just that we don't want to allow any data traffic/Signalling > for that MN for testing/maintenance activity without the > involvement if AAA server (Please see my next comment). > > I would like to compare this feature of binding revocation to > link inhibit/uninhibit in SS7. When a link is inhibited data > structures for the particular link are not removed but > particular link is marked inhibited so that no traffic goes > on that link. > ~~~~~~~~~~~~~ [Ahmad] Hmmmm .. I have not looked at SS7 for a long time. However, I am not sure if the comparison here is valid. A link associated with an established session in plain vanilla SS7 is a dedicated link that is always used for carrying the traffic of that session. In IP, the data could use different routes all the time and I am not sure if what you are trying to do here is applicable. > > > > > 1.------------------------- > > If administrator at LMA revokes a binding (does a revoke > > administrative > > action) (I would call is bringing binding administratively > > down) in this case a BRI message is sent to MAG (and BRA > received in > > return). > > > > If after some time the same administrator unrevokes the > binding (i.e. > > and makes this binding administratively up) > > [Ahmad] > What is your definition of this administrative up and > administrative down events. > When the MN Binding is revoked for administrative reason, the > MN is no longer allowed to receive mobility service. If that > the case, then there is no need to keep the BCE around. > > > > > > Option 1: > > In this case should there be message which LMA can send to MAG to > > indicate that MAG can send PBU to register the MN binding with LMA. > > > > OR > > Option 2: > > When binding is administratively down MAG keeps on transmitting PBU > > and LMA replies PBA with status = Administratively prohibited. > > MAG keeps on sending PBU until LMA responds with PBA (status = 0) > > [Ahmad] > I seem to have difficulties with the logic here. > If the MN session is revoked for administrative reason, all > resources associated with the MN session are deleted. > If the MN tries to access the network again, the MN should > not be allowed to receive PMIPv6 mobility services unless the > Mobile node is authorized to receive PMIPv6 which is > communicated to the MAG during access authentication. > > As per PMIPv6 base protocol, the MAG receives the MN profile > and also if the MN is allowed for PMIPv6 service or not. > Therefore, both options above are not applicable. > ~~~~~~~~~~~~~ > [SANDESH] > Policy of an MN is present in the AAA sever and BCE is present in LMA. > Does revocation of binding at LMA means - 'marking MN > unauthorized in AAA server' AND 'revoking MN binding at LMA' > If above is the definition of binding revocation then, if AAA > server and LMA are independent servers controlled by > different companies, then binding revocation would involve > interaction with both AAA server and LMA which might be > undesirable in some case. (e.g when AAA server administarator > and LMA administrator are not the same person). > > Also 'marking MN unauthorized in AAA server' needs to be done > before 'revoking MN binding at LMA' for the following reason > - If 'revoking MN binding at LMA' done first and after that > 'marking MN unauthorized in AAA server' is done then > following race condition might occur - 1. 'revoking MN > binding at LMA' is done at LMA 2. BRI/BRA has been exchanged > 3. MN attaches to MAG 4. PBU/PBA gets exchanged before - 5. > 'marking MN unauthorized in AAA server' [Ahmad] I am sorry, I am missing something here. What is the relevance that the AAA and the LMA are run by two different companies here. If that AAA needs to maintain AAA functionality for a specific users where they may be offered service at a specific LMA, then there has to be a specific mechanism to keep these two entities in sync. Otherwise, there is something broken. May be if you give an exact example, then we can see what is broken in there and try to fix it. At any rate, that is also out-of-scope Binding Revocation. > > Can we define two types of binding revocation - i. DELETE > REVOCATION (revocation defined in the draft) - Mark MN > unauthorized for PMIPv6 service in AAA server. > Initiate BRI+BRA exchange with MAG. LMA removes BCE. > MAG removes BUL entry. LMA and MAG removes data tunnel for > the MN. This involves interaction with AAA server. > > ii. LOCAL REVOCATION - Initiate BRI+BRA exchange. > BRI, BRA can carry flag indicating 'local revocation'. > LMA marks BCE 'revoked'( i.e. administratively down). > MAG marks BUL entry 'revoked' (i.e. administratively down). > This does not involve interaction with AAA server. If BUL > entry is marked 'revoked' MAG shall not query AAA server for > authorization. > The binding can be unrevoked by another message exchange > between LMA and MAG (say BINDING UNREVOKE + BINDING UNREVOKE ACK) [Ahmad] This functionality is out-of-scope. > > I hope I make some sense here. > ~~~~~~~~~~~~~~ > > > 4.------------------------- > > Section 8.2.2. 4th bullet > > It would be good if few cases of 'partial success' can be mentioned. > > [Ahmad] > I believe the text is generic and applicable. > Do you have a case that is not addressed by the current text? > > ~~~~~~~~~~~~~ > [SANDESH] > Could you please let me know few cases in which LMA/MAG may > be unable to revoke a binding. IMO the LMA/MAG in all cases > should be able to at least set one flag to indicate for the > binding is revoked and prohibit that binding from being used > until that binding is physically deleted. > [Ahmad] It seems that you have assumed that the MAG and the LMA are always in sync with respect to the state of every single BCE. In my experience there are many cases where the LMA and the MAG could be out of sync with respect to the state of a single or some BCEs. > Does partial success include the case when BCE at LMA or BUL > entry at MAG is deleted but data tunnel for that link is not > deleted for some reason or the other way around. > Is such a case allowed for binding revocation. [Ahmad] The case you mention here is not related to Binding Revocation. Again, IMO, this is an implementation specific. I would be happy to continue this discussion off list if you need my personal opinion. BTW: Is the scenario you are concerned about allowed by base PMIPv6 protocol? I believe that should be allowed there first then we can talk how Binding Revocation or something else need to address it. > > It would be helpful for me if you can tell the thought > process which led to addition of this 'partial success' > status to draft. > ~~~~~~~~~~~~~ > > > > 5.------------------------- > > Section 9.2.2 > > It would be good if few guidelines can added for the case when MAG > > receives BRA (status = partial success) > > [Ahmad] > Like what? > > ~~~~~~~~~~~~~ > [SANDESH] > The draft mentions that handling of BRA(status = partial > success) is defined by LMA's local policy (Section 9.1.1. > Third bullet). [Ahmad] Did you mean a different section. I can not find what you reference here. > For MAG the draft does not seem to be > mentioning anything. > > Some guideline (which you feel makes more sense) for actions > which can be taken after receiving BRA(status = partial > success) can be provided in the draft itself. This guideline > will make the draft rich in content. > > One example guideline which I can think of is - LMA/MAG may > choose maintain a 'RevokeTryCounter' per binding initially set to 0. > If BRA indicates MAG/LMA is unable to revoke the binding then > the counter can be incremented. LMA/MAG retries for > 'MaxRevocationTries' and then can delete BCE/revoke binding. > (This is similar to BRIMaxRetransmitNumber) [Ahmad] If the MAG decides to remove a MN Binding from the BUL for any valid reason that justify sending a BRI, even for a MAG local policy, the MAG sends a Binding Revocation to the LMA to gracefully clean resources and avoid unnecessary traffic, for a specific Mobile node which is no longer is hosted at the MAG, for example. The main concept is to allow this functionality in a flexible manner that different deployment can specify what fits its own. In other words, sometimes the BRI message requires a BRA and that why the draft specify when the (A) bit is set and the retransmission, etc. However, in certain conditions, the revoking node may not set the (A) bit and consequently delete the MN Binding immediately as soon as it sends the BRI. Having that in mind, I agree with you that we probably need some clarification added to this status code. Like a recommendation what to do. IMO, if the MAG has a valid reason to revoke the MN Binding, then the LMA response in BRA is nothing but acknowledgement that the LMA has received the BRI and processed it. Let us assume that one of the identified sessions in the BRI was already removed before the LMA receive the BRI message, in this case, the LMA has the option to either set the status to partial success or success. Another example, let us assume that when the MAG sent the BRI message with the (G) bit is set one of the MN moved to another MAG and a handoff PBU was received at the LAM before the BRI. What the LMA should do here? If I were the designer for any implementation, I would allow the LMA to revoke all other MNs BUT not this one. Then the LMA may send a BRA with 'Partial success" and should include the MN session identity in the BRA. In such a case, the MAG should not do any further actions and should delete that MN resources as well, if it has not done so already. ~~~~~~~~~~~~~ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Aug 7 07:24:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09DBF3A6C06; Thu, 7 Aug 2008 07: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 C0A833A6C08 for ; Thu, 7 Aug 2008 07:24:57 -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 kHhRjNgyq1FV for ; Thu, 7 Aug 2008 07:24:56 -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 3BB2D3A6C06 for ; Thu, 7 Aug 2008 07:24:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,320,1215388800"; d="scan'208";a="62751779" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2008 14:25:26 +0000 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 m77EPQGk025051; Thu, 7 Aug 2008 07:25:26 -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 m77EPQbe000013; Thu, 7 Aug 2008 14:25:26 GMT Date: Thu, 7 Aug 2008 07:25:26 -0700 (PDT) From: Sri Gundavelli To: Sandesh In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2005; t=1218119126; x=1218983126; 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]=20Queries/comments=20on=20'Bindi ng=20Revocation=20for=20IPv6=20Mobility'=0A=20draft |Sender:=20; bh=YyYwdtUeIBLJKjVTK5MIipA2a7FirlIiPibMJpMAmiE=; b=VrY57F97inFzjmAgsxx+AtostgbrdnxXoFDU7FAywLvRZskBUUGCoomoLl QB2CykH2VJvhCO2F8BGUJRDdgiI+M6Ox+U6pvWKnI+nRwObVeUb6maOF2+pI Zyd+2BWyob6Po2c7y0aWk/QcWIMyT9r0nBfy1KbdB2vUPW0Kx47p8=; 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] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sandesh, Couple of comments .. On Wed, 6 Aug 2008, Sandesh wrote: > ~~~~~~~~~~~~~ > [SANDESH] > I agree with the you that BRI provides a useful facility to remove BCE for > stale sessions. This is a desirable functionality. > > IMO it is also desirable to have an administrative interface which > can disable/enable a particular binding for sometime without deleting > BUL/BCE. The session is not stale. It is just that we don't want to allow > any data traffic/Signalling for that MN for testing/maintenance activity > without the involvement if AAA server (Please see my next comment). > I'm not sure, if this concept of session freezing is needed in mobility. Suspending a mobility session (BCE/BUL) will result in the application breakdown. Lets say, the mobile have existing TELNET and other sessions, freezing the traffic for some time will break those sessions. If this is still desired, the operator can simply apply some traffic policies to drop the traffic locally. But, if this needs to notified to the peer (LMA or MAG), we are now looking at rate-limiting notifications and that's not the scope of Binding Revocation. > I would like to compare this feature of binding revocation to > link inhibit/uninhibit in SS7. When a link is inhibited data structures > for the particular link are not removed but particular link is marked > inhibited so that no traffic goes on that link. > ~~~~~~~~~~~~~ > >> >> 1.------------------------- >> If administrator at LMA revokes a binding (does a revoke >> administrative >> action) (I would call is bringing binding administratively >> down) in this case a BRI message is sent to MAG (and BRA received in >> return). >> >> If after some time the same administrator unrevokes the binding (i.e. >> and makes this binding administratively up) > Revocation is an atomic and a permanent action. There is no reversal and no second thoughts. The MAG can always re-establish the session. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Aug 7 08:42:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5563A696D; Thu, 7 Aug 2008 08:42: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 DF1E43A6936 for ; Thu, 7 Aug 2008 08:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, J_CHICKENPOX_36=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 vhDBND1Wspst for ; Thu, 7 Aug 2008 08:42:57 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 31B843A696D for ; Thu, 7 Aug 2008 08:42:57 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so462473rvf.49 for ; Thu, 07 Aug 2008 08:43:31 -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=qVRMcFLOz+4lHUqAvJNlbQlGp/nEHwI72WF1Tg7ohaY=; b=fNK6G4UOAT9uAH+9BCq6lCe2WdERWTp+OL8Ie4a9vQuVZLLHjJz5apApeH+euvhgtk 2r4CrkjEjgDOaovgwQFCTfLh6n5Te6GiocW0zIQQxGBVXg5p4VjbpXvdZ1U+UZmoWlhy 8JTaAByI241pAXd3Tra2FBzseyLpGdV63ZN3U= 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=I+SUGR+cRme6Zi1x7UsYt0j8Ooq2OFnN9iMCQR8GXtmt1RK3B2Wg9lwIwxQqqvb9mk kpKtxBBWqAT0qpR++ChZBUnWfQjT9+XwMk3TPE9xSCSbLOaxP7BPOL7EpAWHTuEelqfK KbAB2h+XD+4E/KsMXTCaDEgLFw+xjD++UuHBg= Received: by 10.141.49.6 with SMTP id b6mr425170rvk.89.1218123811399; Thu, 07 Aug 2008 08:43:31 -0700 (PDT) Received: by 10.141.116.11 with HTTP; Thu, 7 Aug 2008 08:43:31 -0700 (PDT) Message-ID: Date: Thu, 7 Aug 2008 21:13:31 +0530 From: Sandesh To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Thanks very much to you and Sri for valuable inputs. >> ~~~~~~~~~~~~~ >> [SANDESH] >> The draft mentions that handling of BRA(status = partial >> success) is defined by LMA's local policy (Section 9.1.1. >> Third bullet). > >[Ahmad] >Did you mean a different section. I can not find what you reference here. > >> For MAG the draft does not seem to be mentioning anything. [SANDESH] Sorry! I mentioned wrong section number. I meant section '8.1.2 Third bullet'. This section does talk about local policy for handling 'partial success' BRA at LMA. IMO Section 9.2.2 should include similar lines for MAG. Thanks and Regards, Sandesh Kumar Sodhi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 13 03:21:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C673A6C9F; Wed, 13 Aug 2008 03:21: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 4E8563A6C9F for ; Wed, 13 Aug 2008 03:21:04 -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 4ryMGJMXqAQw for ; Wed, 13 Aug 2008 03:21:03 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 32C0C3A6CA3 for ; Wed, 13 Aug 2008 03:21:02 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so987549nfh.39 for ; Wed, 13 Aug 2008 03:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=abRy16bULMpFu8vdM4SY2aoff1MAHY8ZBmU6ZJFhTJE=; b=NalrN5/7Tx1gTMGtVX7Fe9lle4NrAahOPadwg5kHRHFo/BVcFWU91ZZSkuJ1Ac5L1b 7wzTj7nPB3BaMNn8U37kBTbPfRtz9WiULCE+cJnlbfAsWQ/lfcqdDZ5Y0w94fILx5Ck5 4d+V4ikOfbZh4Tazv1+ltUBUaI19/qSf2IrQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=UaoODmS9AIV2y+Ee0tiQTJf6t+4QXoa7LJJ2IqKj5AFteMzUqBGM4WQCaHs4CrQWJj c3iR5z4CIFBBSYzLTYIg/jPef+Zz/w4KiRvwQZS7ppFnNSK2w5wzv1/Wr+2O7c117P9M Xw2dh6JWaBFqX71bpeQbk8M5TR2m1sbYRsDKw= Received: by 10.102.228.2 with SMTP id a2mr7966336muh.79.1218622853480; Wed, 13 Aug 2008 03:20:53 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e8sm283211muf.0.2008.08.13.03.20.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 03:20:52 -0700 (PDT) To: mext@ietf.org, btns@ietf.org Date: Wed, 13 Aug 2008 12:21:17 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808131221.18409.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] FW: Third Nomcom 2008-9 Call for Volunteers! X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.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 Folks, The NomCom chair has requested WG chairs to forward to their WG mailing = list this call for NomCom volunteers. = There are currently 91 volunteers whose qualifications have been = confirmed by the secretariat. However, the more volunteers the better, = thus we need more volunteers! You have until August 18th, 2008 as = stated below. If you are eligible to volunteer, please consider doing so as the NomCom = plays a leading part in choosing the leadership of the IETF. Thanks, --julien From: NomCom Chair To: IETF Announcement list Subject: Third Nomcom 2008-9 Call for Volunteers! Once again, the IETF nominating process has begun, and the community (and I) need your help. =A0The IETF Nominating Committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. =A0The people who do that are 10 folks selected randomly from the pool of volunteers. To make this work well for the community, we need people to volunteer. Lots of people. =A0Please! Volunteers must have attended 3 of the past 5 IETF meetings. =A0As defined by RFC 3777, that is 3 of the past 5 meetings as of the time this announcement goes out to start the solicitation. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. =A0Details on the nominating process can be found in RFC 3777. Below is the list of people and posts whose terms end with the March 2009 IETF meeting, and whose positions therefore the nominating committee is responsible for: IAOC: Jonne Soininen IAB: Loa Andersson Barry Leiba Kurtis Lindqvist Danny McPherson Dave Thaler Lixia Zhang IESG: IETF and IESG Chair: Russ Housley Applications Area (app): Chris Newman Internet Area (int): Mark Townsley Operations and Management Area (ops): Ronald Bonica Real-time Applications and Infrastructure Area (rai): =A0 =A0 =A0Jon Peterson Routing Area (rtg): David Ward Security Area (sec): Tim Polk Transport Area (tsv): Lars Eggert Before volunteering, please think about whether you want to be considered for one of the above positions instead. =A0If you are willing to volunteer, please send email before 5:00 pm EDT (2100 UTC/GMT) August 18, 2008 (otherwise, please read on) Please send email to me using the following skeleton: To: jmh@joelhalpern.com Subject: Nomcom 2008-9 Volunteer Body: =A0// As you enter in the IETF Registration Form, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// First/Given name followed by Last= /Family Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// typically what goes in the Compan= y field =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// =A0in the IETF Registration Form [] =A0// =A0 =A0 =A0 =A0 // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. =A0If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. During the IETF meeting in Dublin, responses will be somewhat slower, due to both my activities at the meeting and the secretariat's many activities in support of the meeting. =A0 I will try to send out at least a prompt confirmation that your email volunteering has been received. Not convinced yet? =A0Please consider that nomcom members play an important role in shaping the leadership of the IETF. =A0If you are a people person, you will enjoy meeting many of the active contributors to the IETF. =A0If you prefer instead to read a lot of email, well, we have that too. =A0Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. =A0The term of this nomcom will begin in early September this year. =A0We will be talking with folks at the Minneapolis IETF (if you are there. =A0It is not mandatory that all nomcom members come to the meeting.) =A0I hope to wrap up our primary selection work by mid-December, and we must complete our selection work by mid-January. We will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. =A0So please volunteer! I will be publishing a more thorough and precise target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you, and I hope to hear from you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 13 06:14:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEAB28C10C; Wed, 13 Aug 2008 06:14: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 54D9228C102 for ; Wed, 13 Aug 2008 06:14:47 -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 rtYslOkoSziW for ; Wed, 13 Aug 2008 06:14:43 -0700 (PDT) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 2195628C10C for ; Wed, 13 Aug 2008 06:14:42 -0700 (PDT) X-AuditID: c26e2f18-000021f800001d68-cc-48a2de667070 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 16:15:18 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 15:14:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 15:14:43 +0200 Message-ID: In-Reply-To: <4877A473.6050109@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New Text for home link detection in RFC3775bis thread-index: AcjjgoaAdbB5yJ0mTfyZ813q9XpKMgZwf5MQ References: <486B8EDD.4070807@ericsson.com> <4876501E.4060908@earthlink.net> <4877A473.6050109@ericsson.com> From: To: , X-OriginalArrivalTime: 13 Aug 2008 13:14:44.0204 (UTC) FILETIME=[8D689AC0:01C8FD46] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I wonder why the new text's second bullet insists on "statically configured" home prefix. When the algorithm (the three bullets) has been completed, the mobile node know its home prefix. Next time the mobile node detects it is on a new link, the home prefix should remain the same as before. Thus I my view "statically configured" should be something like "statically configured or learned on one of its previous links". Christian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: 11. juli 2008 20:21 > To: Charles E. Perkins > Cc: mext@ietf.org > Subject: Re: [MEXT] New Text for home link detection in RFC3775bis > > Hi Charlie, > Your suggested text sounds good. If you are looking for a > new name for these sections may I suggest "Attachment to a > new link" :-) > > Cheers > Suresh > > Charles E. Perkins wrote: > > > > Hello Suresh, > > > > I'm creating a new issue for "home link detection" to go into the > > issue tracker. Your suggested text seems to have found > consensus for > > resolving the issue, as long as it is located in a new section (as > > suggested in later messages). However, I would like to suggest a > > textual revision and simplification. Most of the revision > relies on > > pointing out that one has to get a home network prefix > before using it > > to compare against the list of prefixes received in the RA. > The other > > revision, which I hope is O.K., is to dispense with > creating the new > > acronyms CMA and CLPL. I am biased against having acronyms > that are > > not used elsewhere in the document. > > > > Here is my result: > > > > NEW TEXT > > ======== > > > > Section 11.5.X Home Link Detection > > > > When an MN detects that it has arrived on a new link using the > > movement detection algorithm in use (Section 11.5.1x) it > performs the > > following steps to determine if it is on the home link. > > > > o The MN performs the procedure described in Section 11.5.2x and > > configures an address. It also keeps track of all > the on-link > > prefix(es) > > received in the RA along with their prefix lengths. > > > > o If the home prefix has not been statically configured > the MN uses > > some form of bootstrapping procedure (e.g. RFC5026) to > determine > > the home prefix. > > > > o Given the availability of the home prefix, the MN > checks whether or > > not the home prefix matches one of the prefixes > received in the RA. > > If it does, the MN concludes that it has returned home. > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 13 06:33:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729073A697D; Wed, 13 Aug 2008 06:33: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 62A9F3A697D for ; Wed, 13 Aug 2008 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQzcgtkPeab0 for ; Wed, 13 Aug 2008 06:33:08 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id D18CC3A67D6 for ; Wed, 13 Aug 2008 06:33:07 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2709369fkq.5 for ; Wed, 13 Aug 2008 06:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=IEMNFUSAjivjxcKdO9ISPPzgYg/gJODdVQjWoQ0oNK0=; b=XHT2s6/AO5Ba/jUEpMiW3Ede8CvWtVt6E64sK3Ou/G2kU2FMfDcPCn2PbcBu81Wibg +CNew+sUEAWybsSAUIMwNk74CINDp6TcI4Ej0rJunW3I6Bu/slSNn14D7tNvb7mD2JUe bnlyr7q0EJPwTiB5TdWTdY0tDpqK2KEOfMxkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=fN3gdjhrbcwJm9KwiQvB+4wNZPVQ4kh/3na+OoKHsdiPU37U6JtpE7onTXCEaEgc+4 y8TUZI24Vii64zbhS4A9MiO0kbVch3GF4uVrJAySWfIWLcaHkogLQ7hvfVvit6BjsHkB 16TjTdc7v/poy3EGivA7Ep+rtjYt1HQcgsW6g= Received: by 10.180.215.9 with SMTP id n9mr5828308bkg.59.1218634371435; Wed, 13 Aug 2008 06:32:51 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p9sm359083fkb.5.2008.08.13.06.32.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 06:32:50 -0700 (PDT) To: mext@ietf.org Date: Wed, 13 Aug 2008 15:33:17 +0200 User-Agent: KMail/1.9.9 References: <486B8EDD.4070807@ericsson.com> <4877A473.6050109@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808131533.18204.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Christian.Kaas-Petersen@tietoenator.com Subject: Re: [MEXT] New Text for home link detection in RFC3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Christian, I think you have a point. How about the text below? o If the MN has no knowledge of its home prefix via static configuration, or a previous execution of a bootstrapping mechanism (e.g., RFC5026), the MN executes a bootstrapping mechanism (e.g., RFC5026) to determine its home prefix. --julien > On Wednesday 13 August 2008, Christian.Kaas-Petersen@tietoenator.com > wrote: > I wonder why the new text's second bullet insists on "statically > configured" > home prefix. When the algorithm (the three bullets) has been > completed, > > the mobile node know its home prefix. Next time the mobile node > detects it is on a new link, the home prefix should remain the same > as before. > Thus I my view "statically configured" should be something like > "statically configured or learned on one of its previous links". > > Christian > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Suresh Krishnan > > Sent: 11. juli 2008 20:21 > > To: Charles E. Perkins > > Cc: mext@ietf.org > > Subject: Re: [MEXT] New Text for home link detection in RFC3775bis > > > > Hi Charlie, > > Your suggested text sounds good. If you are looking for a > > new name for these sections may I suggest "Attachment to a > > new link" :-) > > > > Cheers > > Suresh > > > > Charles E. Perkins wrote: > > > Hello Suresh, > > > > > > I'm creating a new issue for "home link detection" to go into the > > > issue tracker. Your suggested text seems to have found > > > > consensus for > > > > > resolving the issue, as long as it is located in a new section > > > (as suggested in later messages). However, I would like to > > > suggest a textual revision and simplification. Most of the > > > revision > > > > relies on > > > > > pointing out that one has to get a home network prefix > > > > before using it > > > > > to compare against the list of prefixes received in the RA. > > > > The other > > > > > revision, which I hope is O.K., is to dispense with > > > > creating the new > > > > > acronyms CMA and CLPL. I am biased against having acronyms > > > > that are > > > > > not used elsewhere in the document. > > > > > > Here is my result: > > > > > > NEW TEXT > > > ======== > > > > > > Section 11.5.X Home Link Detection > > > > > > When an MN detects that it has arrived on a new link using the > > > movement detection algorithm in use (Section 11.5.1x) it > > > > performs the > > > > > following steps to determine if it is on the home link. > > > > > > o The MN performs the procedure described in Section 11.5.2x > > > and configures an address. It also keeps track of all > > > > the on-link > > > > > prefix(es) > > > received in the RA along with their prefix lengths. > > > > > > o If the home prefix has not been statically configured > > > > the MN uses > > > > > some form of bootstrapping procedure (e.g. RFC5026) to > > > > determine > > > > > the home prefix. > > > > > > o Given the availability of the home prefix, the MN > > > > checks whether or > > > > > not the home prefix matches one of the prefixes > > > > received in the RA. > > > > > If it does, the MN concludes that it has returned home. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- --julien [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 13 06:38:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D983A697D; Wed, 13 Aug 2008 06:38:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6A13A697D for ; Wed, 13 Aug 2008 06:38:13 -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 IBOhtAaDsWPX for ; Wed, 13 Aug 2008 06:38:12 -0700 (PDT) Received: from tietoe03.tietoenator.com (mail1.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id ED0EC3A67AF for ; Wed, 13 Aug 2008 06:38:11 -0700 (PDT) X-AuditID: c26e2f18-000021e000001d68-0d-48a2e3c61503 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 16:38:14 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 15:37:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 15:37:39 +0200 Message-ID: In-Reply-To: <200808131533.18204.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New Text for home link detection in RFC3775bis thread-index: Acj9SRbxEmevGTXhR46/6BwyC66irQAAIZ9Q References: <486B8EDD.4070807@ericsson.com> <4877A473.6050109@ericsson.com> <200808131533.18204.julien.laganier.IETF@googlemail.com> From: To: , X-OriginalArrivalTime: 13 Aug 2008 13:37:40.0251 (UTC) FILETIME=[C198B6B0:01C8FD49] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] New Text for home link detection in RFC3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Fine text. Christian > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > Sent: 13. august 2008 15:33 > To: mext@ietf.org > Cc: Kaas-Petersen Christian; suresh.krishnan@ericsson.com; > charles.perkins@earthlink.net > Subject: Re: [MEXT] New Text for home link detection in RFC3775bis > > Hello Christian, > > I think you have a point. How about the text below? > > o If the MN has no knowledge of its home prefix via static > configuration, or a previous execution of a bootstrapping > mechanism (e.g., RFC5026), the MN executes a bootstrapping > mechanism (e.g., RFC5026) to determine its home prefix. > > --julien > > > On Wednesday 13 August 2008, Christian.Kaas-Petersen@tietoenator.com > > wrote: > > I wonder why the new text's second bullet insists on "statically > > configured" > > home prefix. When the algorithm (the three bullets) has been > > completed, > > > > the mobile node know its home prefix. Next time the mobile node > > detects it is on a new link, the home prefix should remain > the same as > > before. > > Thus I my view "statically configured" should be something like > > "statically configured or learned on one of its previous links". > > > > Christian > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > > > Of Suresh Krishnan > > > Sent: 11. juli 2008 20:21 > > > To: Charles E. Perkins > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] New Text for home link detection in RFC3775bis > > > > > > Hi Charlie, > > > Your suggested text sounds good. If you are looking for a new > > > name for these sections may I suggest "Attachment to a > new link" :-) > > > > > > Cheers > > > Suresh > > > > > > Charles E. Perkins wrote: > > > > Hello Suresh, > > > > > > > > I'm creating a new issue for "home link detection" to > go into the > > > > issue tracker. Your suggested text seems to have found > > > > > > consensus for > > > > > > > resolving the issue, as long as it is located in a new > section (as > > > > suggested in later messages). However, I would like to > suggest a > > > > textual revision and simplification. Most of the revision > > > > > > relies on > > > > > > > pointing out that one has to get a home network prefix > > > > > > before using it > > > > > > > to compare against the list of prefixes received in the RA. > > > > > > The other > > > > > > > revision, which I hope is O.K., is to dispense with > > > > > > creating the new > > > > > > > acronyms CMA and CLPL. I am biased against having acronyms > > > > > > that are > > > > > > > not used elsewhere in the document. > > > > > > > > Here is my result: > > > > > > > > NEW TEXT > > > > ======== > > > > > > > > Section 11.5.X Home Link Detection > > > > > > > > When an MN detects that it has arrived on a new link using the > > > > movement detection algorithm in use (Section 11.5.1x) it > > > > > > performs the > > > > > > > following steps to determine if it is on the home link. > > > > > > > > o The MN performs the procedure described in Section 11.5.2x > > > > and configures an address. It also keeps track of all > > > > > > the on-link > > > > > > > prefix(es) > > > > received in the RA along with their prefix lengths. > > > > > > > > o If the home prefix has not been statically configured > > > > > > the MN uses > > > > > > > some form of bootstrapping procedure (e.g. RFC5026) to > > > > > > determine > > > > > > > the home prefix. > > > > > > > > o Given the availability of the home prefix, the MN > > > > > > checks whether or > > > > > > > not the home prefix matches one of the prefixes > > > > > > received in the RA. > > > > > > > If it does, the MN concludes that it has returned home. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > -- > --julien > > [ New email address: julien.laganier.IETF@googlemail.com ] > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Aug 14 08:45:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3CE28C1AD; Thu, 14 Aug 2008 08:45:21 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0864B3A6AE2; Thu, 14 Aug 2008 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080814154502.0864B3A6AE2@core3.amsl.com> Date: Thu, 14 Aug 2008 08:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-generic-signaling-message-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Generic Signaling Message Author(s) : B. Haley, S. Gundavelli Filename : draft-ietf-mext-generic-signaling-message-00.txt Pages : 14 Date : 2008-08-14 This document specifies two new Mobility Header message types that allow Mobile IPv6 entities to send and receive generic signaling messages. Haley Expires - January 2008 [page 1] Mobile IPv6 Generic Signaling Message August 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-generic-signaling-message-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-generic-signaling-message-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-14083714.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 Thu Aug 14 09:41:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F55928C1AF; Thu, 14 Aug 2008 09:41: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 7D58A28C1CC for ; Thu, 14 Aug 2008 09:41:06 -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 JUJCMRzq7xpI for ; Thu, 14 Aug 2008 09:41:05 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 383E428C1A5 for ; Thu, 14 Aug 2008 09:41:05 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so533998fkq.5 for ; Thu, 14 Aug 2008 09:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-disposition :content-type:content-transfer-encoding:message-id:from; bh=/mv6Esnio5QqxJf88w6DleuGLj9zSvhxFDBNf6U/oek=; b=nikN7wI4bHTheJVWPEQhzqMtJkeE+SvcCrQNBzqbCwuxYhvt1ir3m6qvtPK4i3n4GI VGNChivFmGGwBJKo+zyLEZxByI6RApVRbt3SK4/3jOyXSfSYSKALdWIWqt2sBDpe/AJU NsTcTtevZ9XhQCvmtucO9+AQfAa0k4LaDKECI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-disposition:content-type:content-transfer-encoding :message-id:from; b=DJnPtTIwV4K5jdATzbWwqnGuNu2vBxZgz5qKndG1NlISunx1ru/+DjEBZYtTa/K4gK LGqIoSlj9sLgezenfqLhqaaS6Rjo+E9g5uy57PRqAhkIfpXsBp0ge/OP1vq/cqZC9hhM tajOQ95+OG40KN9wiFn+kssSQJYm6xq3zWJDo= Received: by 10.180.215.19 with SMTP id n19mr889238bkg.35.1218732067378; Thu, 14 Aug 2008 09:41:07 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 12sm2754628fks.9.2008.08.14.09.41.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 09:41:06 -0700 (PDT) To: mext@ietf.org Date: Thu, 14 Aug 2008 18:41:02 +0200 User-Agent: KMail/1.9.9 References: <200807311459.15169.julien.IETF@laposte.net> In-Reply-To: <200807311459.15169.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808141841.03575.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: draft-muhanna-mext-binding-revocation@tools.ietf.org Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, This is to confirm that we have a WG consensus on the fact that the Binding Revocation shall NOT use the GSM framework, but rather use its own MH type values. Authors, please take that consensus in account in the next revision of the draft. --julien & marcelo, MEXT chairs On Thursday 31 July 2008, Julien Laganier wrote: > Folks, > > During the 2nd MEXT session, there was consensus amongst the session > attendees that Binding Revocation shall NOT use the GSM framework. > Rather, the consensus was that binding revocation shall use directly > the mobility header and allocates its own MH types values. > > Hereby we'd like to confirm that room consensus on the mailing list. > If you haven't expressed an opinion during the session, please send a > note to the list stating whether you agree or disagree with that room > consensus by 2008-08-14. > > -- julien & marcelo, MEXT chairs > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- --julien [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From asamblea06082008@gmail.com Thu Aug 14 13:20:09 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 E0D623A67F8; Thu, 14 Aug 2008 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.578 X-Spam-Level: **** X-Spam-Status: No, score=4.578 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVLG5t0P3j3B; Thu, 14 Aug 2008 13:20:09 -0700 (PDT) Received: from avas-mr17.fibertel.com.ar (avas-mr17.fibertel.com.ar [24.232.0.249]) by core3.amsl.com (Postfix) with ESMTP id 56ABA3A685C; Thu, 14 Aug 2008 13:20:09 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:3091 "EHLO coloso" smtp-auth: "asamblea06082008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr17.fibertel.com.ar with ESMTPA id S1474429AbYHNTv1 convert rfc822-to-8bit; Thu, 14 Aug 2008 16:51:27 -0300 Message-ID: <3824-220088414195015490@coloso> To: "notebooks" Errors-to: asamblea06082008_@gmail.com From: "asamblea06082008@gmail.com" Subject: NOTEBOOKS EN TODOS LOS PRECIOS Date: Thu, 14 Aug 2008 16:50:15 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: b298b88f45c787cda40614ec2315975a X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea06082008@gmail.com NOTEBOOKS con GARANTIA, ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B CEL: 15-3197-5821 EMail: asamblea060872008@gmail.com ASUS ASUS EEE PC 701 ASUS EEE PC 701 Pesa 900 gramos 7" ideal $ 1.419,00 BANGHO CS1406CC BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO CS1406CC-S BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO DS1406CB BanghóMov DS1406CB Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.499,00 BANGHO DS1406CB-H BanghóMov DS1406CB-H Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.599,00 BANGHO CS1501CB BanghóMov BQ1501CB Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.599,00 BANGHO CS1501CB-H BanghóMov BQ1501CB-H Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.699,00 HEWLETT PACKARD 530 T2600 DOS Procesador Core Duo T2600 HDD 120GB 1GB DDR2 667 15,4'' WI-FI $ 2.799,00 BANGHO DS1501CF BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.499,00 BANGHO CS1202CF-H BanghóMov CS1221C Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.599,00 BANGHO CS1202CF-H BanghóMov CS1202CF-H Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.799,00 BANGHO DS1501CF-P BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.799,00 BANGHO DS1205CF-P BanghóMov DS1205C-P Intel Core 2 Duo T5450 2GB DDR2 667 HDD 120GB $ 4.499,00 From mext-bounces@ietf.org Fri Aug 15 07:33:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C1E3A6AAF; Fri, 15 Aug 2008 07:33:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A3C3A69DF for ; Fri, 15 Aug 2008 07:33:20 -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 pz0G9zCwM1zr for ; Fri, 15 Aug 2008 07:33:14 -0700 (PDT) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 1258F3A6AAF for ; Fri, 15 Aug 2008 07:33:13 -0700 (PDT) X-AuditID: c26e2f18-000021f800001d68-78-48a593ca6eea Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 17:33:46 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Aug 2008 16:33:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 16:33:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UDP checksum in DSMIPv6 thread-index: Acj+49gZ5uE3ntcoTTCrHdhVtblpxw== From: To: X-OriginalArrivalTime: 15 Aug 2008 14:33:12.0106 (UTC) FILETIME=[D85CF0A0:01C8FEE3] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] UDP checksum in DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org It is not stated explicitly in DSMIP draft, but I assume UDP headers are standard RFC 768 headers, and so the UDP checksum is calculated and verified as normal. Only exception is for the UDP headers going with ESP protection of payload packets, which follows RFC 3948 mandating a checksum of zero. Am I right? Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 15 12:37:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A336828C108; Fri, 15 Aug 2008 12:37: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 912A428C0FE for ; Fri, 15 Aug 2008 12:37:05 -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 Gq815VYfv4uk for ; Fri, 15 Aug 2008 12:37:04 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id CE74A3A6C0F for ; Fri, 15 Aug 2008 12:36:52 -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 1KU56E-0004ER-FO; Sat, 16 Aug 2008 05:36:38 +1000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 16 Aug 2008 05:36:32 +1000 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] UDP checksum in DSMIPv6 Thread-Index: Acj+49gZ5uE3ntcoTTCrHdhVtblpxwAKmA8M In-Reply-To: Mime-version: 1.0 Subject: Re: [MEXT] UDP checksum in DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 right, we don't need to say things that are already stated in the RFCs we use. Hesham On 16/08/08 12:33 AM, "Christian.Kaas-Petersen@tietoenator.com" wrote: > It is not stated explicitly in DSMIP draft, but I assume > UDP headers are standard RFC 768 headers, > and so the UDP checksum is calculated and verified as normal. > Only exception is for the UDP headers going with ESP protection > of payload packets, which follows RFC 3948 mandating a > checksum of zero. Am I right? > > Christian > _______________________________________________ > MEXT mailing 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 Aug 17 16:55:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96ABC3A68BC; Sun, 17 Aug 2008 16:55: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 F29613A68BC for ; Sun, 17 Aug 2008 16:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 prHpxikl5-j8 for ; Sun, 17 Aug 2008 16:55:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DE9CF3A6868 for ; Sun, 17 Aug 2008 16:55:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m7HNqsn21316; Sun, 17 Aug 2008 23:52:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Aug 2008 18:55:02 -0500 Message-ID: In-Reply-To: <200808141841.03575.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Consensus call: Binding revocation will NOT use GSM Thread-Index: Acj+LJRm6tGmSIeuSK6+tPgVKBkCvACl8YNw References: <200807311459.15169.julien.IETF@laposte.net> <200808141841.03575.julien.laganier.IETF@googlemail.com> From: "Ahmad Muhanna" To: "Julien Laganier" , Cc: draft-muhanna-mext-binding-revocation@tools.ietf.org Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, We will ASAP and hopefully before end of August 2008. Regards, Ahmad > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > Sent: Thursday, August 14, 2008 11:41 AM > To: mext@ietf.org > Cc: marcelo bagnulo braun; > draft-muhanna-mext-binding-revocation@tools.ietf.org > Subject: Re: [MEXT] Consensus call: Binding revocation will > NOT use GSM > > Folks, > > This is to confirm that we have a WG consensus on the fact > that the Binding Revocation shall NOT use the GSM framework, > but rather use its own MH type values. > > Authors, please take that consensus in account in the next > revision of the draft. > > --julien & marcelo, MEXT chairs > > On Thursday 31 July 2008, Julien Laganier wrote: > > Folks, > > > > During the 2nd MEXT session, there was consensus amongst > the session > > attendees that Binding Revocation shall NOT use the GSM framework. > > Rather, the consensus was that binding revocation shall use > directly > > the mobility header and allocates its own MH types values. > > > > Hereby we'd like to confirm that room consensus on the mailing list. > > If you haven't expressed an opinion during the session, > please send a > > note to the list stating whether you agree or disagree with > that room > > consensus by 2008-08-14. > > > > -- julien & marcelo, MEXT chairs > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > -- > --julien > > [ New email address: julien.laganier.IETF@googlemail.com ] > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 18 02:44:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D543A6A04; Mon, 18 Aug 2008 02:44: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 913A33A6A04 for ; Mon, 18 Aug 2008 02:44: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 kGMTwx0UNMkk for ; Mon, 18 Aug 2008 02:44:27 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 7C80F3A6800 for ; Mon, 18 Aug 2008 02:44:27 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KV1G3-0000xZ-5A; Mon, 18 Aug 2008 11:42:39 +0200 X-Hashcash: 1:20:080818:mext@ietf.org::6hEkGw2WDADxmM50:00008+qB X-Hashcash: 1:20:080818:sdecugis@hongo.wide.ad.jp::zCYOur+rA3x+eJZh:0000000000000000000000000000000000000Jx/ X-Hashcash: 1:20:080818:shinta@sfc.wide.ad.jp::8VthUgW/orxR65CN:00000000000000000000000000000000000000000z/4 X-Hashcash: 1:20:080818:shinta.sugimoto@ericsson.com::7tLV+seckwMvjlG1:00000000000000000000000000000000019jN X-Hashcash: 1:20:080818:nakam@linux-ipv6.org::mZlPlJ+r6qCknQqq:000000000000000000000000000000000000000003E19 X-Hashcash: 1:20:080818:francis.dupont@fdupont.fr::3mmUM2+uDjf4wvRK:0000000000000000000000000000000000000l5f From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Mon, 18 Aug 2008 11:41:20 +0200 Message-ID: <87myjay81r.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Shinta Sugimoto Subject: [MEXT] [gmane.ietf.announce] I-D Action:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0303492647==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0303492647== Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --===-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Hi, for those interested by the topic ... --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: news.gmane.org!not-for-mail From: Internet-Drafts@ietf.org Newsgroups: gmane.ietf.announce Subject: I-D Action:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt Date: Mon, 18 Aug 2008 01:30:01 -0700 (PDT) Approved: news@gmane.org Message-ID: <20080818083001.847EC3A6BB8@core3.amsl.com> Reply-To: internet-drafts@ietf.org NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1219048241 26832 80.91.229.12 (18 Aug 2008 08:30:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Aug 2008 08:30:41 +0000 (UTC) To: i-d-announce@ietf.org Original-X-From: i-d-announce-bounces@ietf.org Mon Aug 18 10:31:23 2008 Return-path: Envelope-to: gia-ietf-announce@gmane.org Original-Received: from mail.ietf.org ([64.170.98.32]) by lo.gmane.org with esmtp (Exim 4.50) id 1KV08x-0000at-Cf for gia-ietf-announce@gmane.org; Mon, 18 Aug 2008 10:31:15 +0200 Original-Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAF13A6BB8; Mon, 18 Aug 2008 01:30:02 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Original-Received: by core3.amsl.com (Postfix, from userid 0) id 847EC3A6BB8; Mon, 18 Aug 2008 01:30:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org Archived-At: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===-=-=" --=-=-=-- --===-=-= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE Author(s) : A. Ebalard, S. Decugis Filename : draft-ebalard-mext-pfkey-enhanced-migrate-00.txt Pages : 21 Date : 2008-08-18 This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IKE in a Mobile IPv6 environment. This document is heavily based on a previous draft [MIGRATE] written by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply reuses the MIGRATE mechanism defined in the expired document, removes a companion extension (SADB_X_EXT_PACKET) based on implementation feedback (complexity, limitations, ...) and fills the gap by very simple changes to MIGRATE mechanism. This results in a more simple and consistent mechanism, which also proved to be easier to implement. This document is expected to serve as a continuation of [MIGRATE] work. For that reason, the name of the extension has been kept. PF_KEY MIGRATE message serves as a carrier for updated address information for both the in-kernel IPsec structures (SP/SA) and those maintained by the key managers. This includes in-kernel SP/SA endpoints, key manager maintained equivalents and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ebalard-mext-pfkey-enhanced-migrate-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --===-=-= Content-Type: message/external-body; name=draft-ebalard-mext-pfkey-enhanced-migrate-00.txt; access-type=anon-ftp Content-Type: text/plain Content-ID: <2008-08-18011902.I-D@ietf.org> --===-=-= Content-Disposition: inline --===-=-=-- --=-=-= If you have comments/questions, do not hesitate. As posted previously, if you are interested by implementation/test details, there is more on the topic here: http://natisbad.org/MIPv6/ Cheers, a+ --=-=-=-- --===-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkipQ8cACgkQAlWVfAR6UCYBMwCeM31qG0k81HTNoLWyhtDQir1C M2oAoIQrDunmxoYTPibyumFqjHDPJoaz =XUeQ -----END PGP SIGNATURE----- --===-=-=-- --===============0303492647== 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 --===============0303492647==-- --=-=-= If you have comments/questions, do not hesitate. As posted previously, if you are interested by implementation/test details, there is more on the topic here: http://natisbad.org/MIPv6/ Cheers, a+ --=-=-=-- --===-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkipQ8cACgkQAlWVfAR6UCYBMwCeM31qG0k81HTNoLWyhtDQir1C M2oAoIQrDunmxoYTPibyumFqjHDPJoaz =XUeQ -----END PGP SIGNATURE----- --===-=-=-- From mext-bounces@ietf.org Mon Aug 18 03:45:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEF73A6BAC; Mon, 18 Aug 2008 03:45: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 129DA3A6C5E for ; Mon, 18 Aug 2008 03:45: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 qIQuKYLIMlcZ for ; Mon, 18 Aug 2008 03:45:24 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id C650E3A6912 for ; Mon, 18 Aug 2008 03:45:22 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KV2EK-0000PG-Qh; Mon, 18 Aug 2008 12:44:57 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG References: <87myjay81r.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080818:shinta.sugimoto@ericsson.com::ib/H5fSLMSNDLPKw:00000000000000000000000000000000039+7 X-Hashcash: 1:20:080818:mext@ietf.org::qMvXWEC836FEwImD:00006tKm Date: Mon, 18 Aug 2008 12:43:42 +0200 Message-ID: <871w0my55t.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: Re: [MEXT] [gmane.ietf.announce] I-D Action:draft-ebalard-mext-pfkey-enhanced-migrate-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, [Replying to the first *broken* mail] for those interested by the topic ... > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : PF_KEY Extension as an Interface between > Mobile IPv6 and IPsec/IKE > Author(s) : A. Ebalard, S. Decugis > Filename : draft-ebalard-mext-pfkey-enhanced-migrate-00.txt > Pages : 21 > Date : 2008-08-18 > > This document describes the need for an interface between Mobile IPv6 > and IPsec/IKE and show how the two protocols can interwork. An > extension of the PF_KEY framework is proposed which allows smooth and > solid operation of IKE in a Mobile IPv6 environment. > > This document is heavily based on a previous draft [MIGRATE] written > by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply > reuses the MIGRATE mechanism defined in the expired document, removes > a companion extension (SADB_X_EXT_PACKET) based on implementation > feedback (complexity, limitations, ...) and fills the gap by very > simple changes to MIGRATE mechanism. This results in a more simple > and consistent mechanism, which also proved to be easier to > implement. This document is expected to serve as a continuation of > [MIGRATE] work. For that reason, the name of the extension has been > kept. > > PF_KEY MIGRATE message serves as a carrier for updated address > information for both the in-kernel IPsec structures (SP/SA) and those > maintained by the key managers. This includes in-kernel SP/SA > endpoints, key manager maintained equivalents and addresses used by > IKE_SA (current and to be negotiated). The extension is helpful for > assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for > the bootstrapping of mobile nodes and their movements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ebalard-mext-pfkey-enhanced-migrate-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. If you have comments/questions, do not hesitate. As posted previously, if you are interested by implementation/test details, there is more on the topic here: http://natisbad.org/MIPv6/ Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 18 22:59:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A373F3A69EC; Mon, 18 Aug 2008 22:59: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 ED1A23A698C for ; Mon, 18 Aug 2008 22:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 Qssji2c7IVKU for ; Mon, 18 Aug 2008 22:59:33 -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 68BE23A6948 for ; Mon, 18 Aug 2008 22:59:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,233,1217808000"; d="scan'208";a="67097212" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Aug 2008 05:59:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7J5x95G029656; Mon, 18 Aug 2008 22:59:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7J5x9Ke002387; Tue, 19 Aug 2008 05:59:09 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, 18 Aug 2008 22:59:09 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 22:59:08 -0700 From: "Sri Gundavelli" To: "'Arnaud Ebalard'" , "'IETF MEXT WG'" References: <87myjay81r.fsf@natisbad.org> <871w0my55t.fsf@natisbad.org> Date: Mon, 18 Aug 2008 22:59:09 -0700 Message-ID: <000001c901c0$b2791c80$1220fea9@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckBH5ttKi8uVKHSSpGXoAMGi4ap7wAn4Thw In-Reply-To: <871w0my55t.fsf@natisbad.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 19 Aug 2008 05:59:08.0872 (UTC) FILETIME=[B203EC80:01C901C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3532; t=1219125549; x=1219989549; 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]=20[gmane.ietf.announce]=20I-DAct ion=3Adraft-ebalard-mext-pfkey-enhanced-migrate-00.txt |Sender:=20; bh=kLV8gFkcSx60/CiIdOpvJN4PtspSSzgGpMx5jR0CDAc=; b=SBFoLKOqK/1yxz8/dasBDQOk4YSOtpTJSvV2CCMSRfnSTILfHnwtn9JOAV rWlruVhjqoQ1gXBR3mYHOLkW7m2RDqeuxln8zIIVlBjKg2WxtL6YQI1x4o39 NqJo3/8lgf; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [MEXT] [gmane.ietf.announce] I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, A quick review of the draft, its well written. Good work !!! this is needed. Just one basic question. Does this or existing PF_KEY interface allow the MIP process to learn Dead Peer Detection events from the IKE process ? Does this already exist in PF_KEY or its extensions ? I guess, I'm looking at the way for MIP process to leverage peer termination events that are learnt from the IKE layer. Any pointer ? Regards Sri > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Arnaud Ebalard > Sent: Monday, August 18, 2008 3:44 AM > To: IETF MEXT WG > Subject: Re: [MEXT] [gmane.ietf.announce] > I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt > > Hi, [Replying to the first *broken* mail] > > for those interested by the topic ... > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : PF_KEY Extension as an Interface between > > Mobile IPv6 and IPsec/IKE > > Author(s) : A. Ebalard, S. Decugis > > Filename : > draft-ebalard-mext-pfkey-enhanced-migrate-00.txt > > Pages : 21 > > Date : 2008-08-18 > > > > This document describes the need for an interface between > Mobile IPv6 > > and IPsec/IKE and show how the two protocols can interwork. An > > extension of the PF_KEY framework is proposed which allows > smooth and > > solid operation of IKE in a Mobile IPv6 environment. > > > > This document is heavily based on a previous draft [MIGRATE] written > > by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply > > reuses the MIGRATE mechanism defined in the expired > document, removes > > a companion extension (SADB_X_EXT_PACKET) based on implementation > > feedback (complexity, limitations, ...) and fills the gap by very > > simple changes to MIGRATE mechanism. This results in a more simple > > and consistent mechanism, which also proved to be easier to > > implement. This document is expected to serve as a continuation of > > [MIGRATE] work. For that reason, the name of the extension has been > > kept. > > > > PF_KEY MIGRATE message serves as a carrier for updated address > > information for both the in-kernel IPsec structures (SP/SA) > and those > > maintained by the key managers. This includes in-kernel SP/SA > > endpoints, key manager maintained equivalents and addresses used by > > IKE_SA (current and to be negotiated). The extension is helpful for > > assuring smooth internetworking between Mobile IPv6 and > IPsec/IKE for > > the bootstrapping of mobile nodes and their movements. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ebalard-mext-pfkey-e > nhanced-migrate-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. > > If you have comments/questions, do not hesitate. > > As posted previously, if you are interested by implementation/test > details, there is more on the topic here: http://natisbad.org/MIPv6/ > > Cheers, > > a+ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Aug 19 00:35:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4819D3A6A0E; Tue, 19 Aug 2008 00:35: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 EDF853A6A0E for ; Tue, 19 Aug 2008 00:35: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 NTWVR8g+TOs4 for ; Tue, 19 Aug 2008 00:35:29 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 138B83A69D1 for ; Tue, 19 Aug 2008 00:35:29 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KVLjd-0000TM-13; Tue, 19 Aug 2008 09:34:33 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Sri Gundavelli" References: <87myjay81r.fsf@natisbad.org> <871w0my55t.fsf@natisbad.org> <000001c901c0$b2791c80$1220fea9@amer.cisco.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080819:sgundave@cisco.com::Yz6RIkBOPKz5Rcbr:00000000000000000000000000000000000000000000LjH X-Hashcash: 1:20:080819:mext@ietf.org::I2GKPk7OcGKurIMF:00006PG2 Date: Tue, 19 Aug 2008 09:33:21 +0200 In-Reply-To: <000001c901c0$b2791c80$1220fea9@amer.cisco.com> (Sri Gundavelli's message of "Mon, 18 Aug 2008 22:59:09 -0700") Message-ID: <87bpzp8nni.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: 'IETF MEXT WG' Subject: Re: [MEXT] [gmane.ietf.announce] I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-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, "Sri Gundavelli" writes: > A quick review of the draft, its well written. Good work !!! > this is needed. Thanks for reading it! > Just one basic question. Does this MIGRATE does not. It flows in the reverse direction (from MIPv6 module to kernel to IKE daemon) > or existing PF_KEY interface allow the MIP process to learn Dead Peer > Detection events from the IKE process ? AFAIK, nope. > Does this already exist in PF_KEY or its extensions ? AFAIK, it does not. > I guess, I'm looking at the way for MIP process to leverage peer > termination events that are learnt from the IKE layer. Any pointer ? Sorry but I have no pointer to provide on that topic. You may have more luck by asking on IETF ipsec or pfkey ML. There may be other people, apps or protocols that already had such a need and a draft may have been written at some point. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Aug 19 07:47:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50303A68BD; Tue, 19 Aug 2008 07:47: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 A9F853A68BD for ; Tue, 19 Aug 2008 07:46: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 Yl-rZwQW6sID for ; Tue, 19 Aug 2008 07:46:58 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id A97943A6885 for ; Tue, 19 Aug 2008 07:46:58 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id v27so71924ele.13 for ; Tue, 19 Aug 2008 07:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+ueNF+1xwFh+MW7cXSM+ikSlipljYev6MVjJPkn/sn8=; b=V3zdsqvx3qQQ3k7X78P4GIViCHeaJ8ipuEXjhU9JhS9v6FcGdKlGTBAyuCrCsg6z9j tuPRSNs7YgoSphrpQu3UtpsOnTiVyqRT0i9sRpDt+X0MQftqbumfPMeUTjqKpDLrig8a rW2ylSzAwOqMmAqNJdfHeTlE9athmiq01yTuU= 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=aAPfJ+HfXZS2h8gAcXvt6vi+1puiimtLEwVItINc5N/pBPixsknfcv/JXRnnPp0bGX QEhwXFxvbjvedI9I9XED/Ghaa19MaNdXMzfQZncP2dSVss/2MxzucOIzTyhufij5avHX x64bodBsjXcdjBFpKVPYd9P1MrGRG9CmGh1tU= Received: by 10.142.217.17 with SMTP id p17mr2541019wfg.105.1219157224292; Tue, 19 Aug 2008 07:47:04 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Tue, 19 Aug 2008 07:47:04 -0700 (PDT) Message-ID: Date: Tue, 19 Aug 2008 07:47:04 -0700 From: "Vijay Devarapalli" To: "mext@ietf.org" In-Reply-To: <48A86ED2.7070009@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <48A86ED2.7070009@gmx.net> Cc: Hannes Tschofenig Subject: [MEXT] Fwd: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FYI. Please respond on the DIME mailing list or directly to Hannes. We discussed the RADIUS MIP6 draft in the MEXT meeting in Dublin. Vijay ---------- Forwarded message ---------- From: Hannes Tschofenig Date: Sun, Aug 17, 2008 at 11:32 AM Subject: [Dime] MIP6 RADIUS and Diameter MIPv6 Split Draft To: dime@ietf.org Hi all, Avi gave a presentation about the MIP6 RADIUS draft http://www3.ietf.org/proceedings/08jul/slides/mext-9.ppt and the MIP6 RADIUS draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.txt is the RADIUS counterpart of our Diameter Mobility documents: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt and http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-09.txt Now, here is the important part. As part of the work on the draft, the feedback Avi got during the presentation and offlist comments from Pasi and Jari there are some concerns about the security properties provided by the following two mechanisms: * IKEv2 with PSKs * IKEv2 with CERTs To briefly summarize the problems (also described in the slide set) there are the following issues: * Having the AAA deliver a PSK key to the HA without the AAA performing authentication introduces security vulnerabilities. The discussed possible solutions where the AAA could authenticate the PSK are somewhat "clunky" since IKEv2 was never meant to be used in such a way. * Similar problems arise with IKEv2 and Certificates where the AAA server is used to just authorize without getting involved in the authentication procedure itself. In an offline discussion between Jari, Pasi, Avi, and Jouni the idea came up to drop these two mechanisms from the MIP6 RADIUS document and consequently also from the Diameter MIPv6 Split draft. Is this a bad thing? I don't think so. Currently, we don't know anyone who would be using them. Hence, there are somewhat "theoretical" at the moment. We could specify them once deployments would be asking for them. Who has objections against dropping the above-described mechanisms from the Diameter MIPv6 Split draft? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Aug 19 17:25:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A983A6BF6; Tue, 19 Aug 2008 17:25: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 4001E3A6BF6 for ; Tue, 19 Aug 2008 17:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 lbLSZ-5MP32N for ; Tue, 19 Aug 2008 17:25:27 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6A59D3A6A27 for ; Tue, 19 Aug 2008 17:25:27 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7K0PQPn013795 for ; Tue, 19 Aug 2008 19:25:30 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 03:25:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 03:25:28 +0300 Received: from [10.121.6.244] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 03:25:27 +0300 Message-Id: From: Lars Eggert To: "ext Christian.Kaas-Petersen@tietoenator.com" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 19 Aug 2008 17:25:24 -0700 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 20 Aug 2008 00:25:27.0708 (UTC) FILETIME=[3EE27DC0:01C9025B] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] UDP checksum in DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 2008-8-15, at 7:33, ext Christian.Kaas-Petersen@tietoenator.com wrote: > It is not stated explicitly in DSMIP draft, but I assume > UDP headers are standard RFC 768 headers, > and so the UDP checksum is calculated and verified as normal. > Only exception is for the UDP headers going with ESP protection > of payload packets, which follows RFC 3948 mandating a > checksum of zero. Am I right? RFC3948 says: o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and Note the "IPv4". That is, because RFC2460 says: o Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header (...) i.e. an IPsec-in-UDP-in-IPv6 tunnel would need to set the UDP checksum Lars _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Aug 19 17:30:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A903A6B4D; Tue, 19 Aug 2008 17:30: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 36CC028C22A for ; Tue, 19 Aug 2008 17:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+1W-brR7HIi for ; Tue, 19 Aug 2008 17:30: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 58C5C3A6901 for ; Tue, 19 Aug 2008 17:30: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 1KVbaX-0001Oa-I6; Wed, 20 Aug 2008 10:30:14 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 20 Aug 2008 10:30:08 +1000 From: Hesham Soliman To: Lars Eggert , "ext Christian.Kaas-Petersen@tietoenator.com" Message-ID: Thread-Topic: [MEXT] UDP checksum in DSMIPv6 Thread-Index: AckCW+XzDzka79MBJUG7XUU3Xb0huw== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] UDP checksum in DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 20/08/08 10:25 AM, "Lars Eggert" wrote: > On 2008-8-15, at 7:33, ext Christian.Kaas-Petersen@tietoenator.com > wrote: >> It is not stated explicitly in DSMIP draft, but I assume >> UDP headers are standard RFC 768 headers, >> and so the UDP checksum is calculated and verified as normal. >> Only exception is for the UDP headers going with ESP protection >> of payload packets, which follows RFC 3948 mandating a >> checksum of zero. Am I right? > > RFC3948 says: > > o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and > > Note the "IPv4". That is, because RFC2460 says: > > o Unlike IPv4, when UDP packets are originated by an IPv6 node, > the UDP checksum is not optional. That is, whenever > originating a UDP packet, an IPv6 node must compute a UDP > checksum over the packet and the pseudo-header (...) > > i.e. an IPsec-in-UDP-in-IPv6 tunnel would need to set the UDP checksum > => That's right, I think Christian was asking about the IPv4 (outer header) case, which would comply with 3948. Hesham > Lars > _______________________________________________ > MEXT mailing 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 Aug 19 23:20:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C853A69B7; Tue, 19 Aug 2008 23:20:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A713A69B7 for ; Tue, 19 Aug 2008 23:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TAKE=2.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 oSXrXZfxJyCZ for ; Tue, 19 Aug 2008 23:20:25 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 66F343A69A3 for ; Tue, 19 Aug 2008 23:20:25 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so111482yxg.49 for ; Tue, 19 Aug 2008 23:20: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:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=ccDQp+sC3Fa1+J973jmfh/7zlqElUeXI6ZhhHDGoSvw=; b=Ykl0MUJmEBSPyD1dmoIgYxcetrUJiA9PZ7f1QoXbmum+/LWo/j1EuD+jP11ICGHdn6 VAh9UbLHfUvTLdRN8Ql1W8rHmQULchWCUL9ROPedAkNDFRZLCJudOwelV3ye2rOD3QLX 6dPn6M6/ECNP5mzVoonSqk4SfBXmGxRDHlqeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=mcbONvqp0B7oK00q072+DtItqU2UvsKj0p+KK8LaNoSMHHtD7zpVSqeFDN2kUmmxVV IbTLjq4kk6Miq/RcBvW1OqDt+llh4lMVwyPm8t6l65uif8x1fAVE7YTijVAr9i5ci+LJ TahwJ7lpGf8GNVpaBqXDwPtl2SJ9C+IrgCNDI= Received: by 10.150.136.6 with SMTP id j6mr10921241ybd.194.1219213200102; Tue, 19 Aug 2008 23:20:00 -0700 (PDT) Received: from KD119107086126.au-net.ne.jp ( [119.107.86.126]) by mx.google.com with ESMTPS id 5sm2619829ywl.4.2008.08.19.23.19.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Aug 2008 23:19:59 -0700 (PDT) Message-Id: <4BDEAA9B-830F-402D-98D6-74C005FD0C06@gmail.com> From: Ryuji Wakikawa To: mext , "netlmm@ietf.org List Mailing" , autoconf@ietf.org, manemo@mobileip.jp Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 20 Aug 2008 15:19:31 +0900 X-Mailer: Apple Mail (2.928.1) Subject: [MEXT] ACM MobiCom'08 Final Program + Hotel Deadline 8/23! X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGVsbG8gYWxsLAoKIyBBcG9sb2dpemUgaWYgeW91IHJlY2VpdmUgbXVsdGlwbGUgY29waWVzLiBT b3JyeSBmb3IgdXNpbmcgTUxzIHRvICAKZGlzdHJpYnV0ZSB0aGlzLgoKV2UgYXJlIHBsZWFzZWQg dG8gYW5ub3VuY2UgdGhlIEZpbmFsIFByb2dyYW0gZm9yIEFDTSBNb2JpQ29t4oCZMDguIFlvdSAg CmNhbiBjaGVjayBpdCBvdXQgaGVyZToKaHR0cDovL3d3dy5jcy5jbXUuZWR1L35wcnMvUHJlbC1Q cm9ncmFtLU1vYmlDb20wOC5odG0gLgpJdCBpcyBhbHNvIGN1dCBhbmQgcGFzdGVkIGJlbG93LgoK QWxzbywgd2Ugd291bGQgbGlrZSB0byByZW1pbmQgeW91IHRoYXQgdGhlIGhvdGVsIGJsb2NrIGZv ciB0aGUgIApjb25mZXJlbmNlIHdpbGwgYmUgcmVsZWFzZWQgb24gQXVndXN0IDIzcmQsb25seSBh IGZldyBkYXlzIGF3YXkhCkNoZWNrIHRoZSBzZXNzaW9ucyB5b3Ugd291bGQgbGlrZSB0byBhdHRl bmQgaW4gdGhlIHByb2dyYW0sIGFuZCBtYWtlICAKeW91ciBob3RlbCByZXNlcnZhdGlvbiBhdCB5 b3VyIGVhcmxpZXN0IGNvbnZlbmllbmNlIHRvIHQKYWtlIGFkdmFudGFnZSBvZiB0aGUgaGVhdmls eSBkaXNjb3VudGVkIHJlZ2lzdHJhdGlvbiByYXRlICgkMTY5L25pZ2h0KS4KCkh1cnJ5IHVwIHdp dGggeW91ciBob3RlbCByZXNlcnZhdGlvbjogdGhlcmUgYXJlIHJvb21zIHN0aWxsIGF2YWlsYWJs ZSAgCm9uIG1vc3QgbmlnaHRzIGF0IHRoZSBkaXNjb3VudGVkIHJhdGUsIGJ1dCB0aGUgaG90ZWwg aGFzIHNvbGQgb3V0IG9mCmFsbCB0aGUgcm9vbXMgcmVzZXJ2ZWQgYnkgdGhlIGNvbmZlcmVuY2Ug Zm9yIHRoZSBuaWdodHMgb2YgU3VuZGF5IFNlcHQgIAoxNHRoIGFuZCBGcmlkYXkgU2VwdCAxOXRo IGFscmVhZHkhCgpZb3UgY2FuIGZpbmQgYWxsIHRoZSBjb25mZXJlbmNlIGluZm8gaGVyZTogaHR0 cDovL3d3dy5zaWdtb2JpbGUub3JnL21vYmljb20vMjAwOC9pbmRleC5odG1sCgpMb29raW5nIGZv cndhcmQgdG8gc2VlaW5nIHlvdSBmb3IgYW4gZXhjaXRpbmcgY29uZmVyZW5jZSBpbiB0aGUgIApi ZWF1dGlmdWwgU2FuIEZyYW5jaXNjbyBCYXkgQXJlYSBuZXh0IG1vbnRoIQoKQ2VkcmljIFdlc3Rw aGFsLCBSeXVqaSBXYWtpa2F3YSwgTWlzY2hhIERvaGxlcgpBQ00gTW9iaUNvbeKAmTA4IFB1Ymxp Y2l0eSBDaGFpcnMuCgoKLS0tLS0tQUNNIE1vYmlDb23igJkwOCBGaW5hbCBQcm9ncmFtLS0tLS0t LS0KClN1bmRheSwgU2VwdGVtYmVyIDE0Cgo4OjAwYW0tNTowMHBtICAgICAgICAgIFJlZ2lzdHJh dGlvbiBPcGVuCgo4OjMwYW0tNTozMHBtICAgICAgICAgIFR1dG9yaWFscyAoU2Fsb24gQSB0byBF KQrigKIgICAgICAgIFNlZSB0dXRvcmlhbCBwYWdlCgpNb25kYXksIFNlcHRlbWJlciAxNQoKODow MGFtLTU6MDBwbSAgICAgICAgICBSZWdpc3RyYXRpb24gT3BlbgoKODozMGFtLTU6MzBwbSAgICAg ICAgICBDb25jdXJyZW50IFdvcmtzaG9wcyAoU2Fsb24gQSB0byBFKQrigKIgICAgICAgIFdVV05F VArigKIgICAgICAgIFZBTkVUCuKAoiAgICAgICAgQ0hBTlRTCuKAoiAgICAgICAgU2VlIHdvcmtz aG9wIHBhZ2VzIGZvciBkZXRhaWxzCgpFdmVuaW5nICAgICAgICAgICAgICAgICAgICAgICBXZWxj b21lIFJlY2VwdGlvbiAoU2Fsb24gRiB0byBKKQoKVHVlc2RheSwgU2VwdGVtYmVyIDE2Cgo4OjAw YW0tNTowMHBtICAgICAgICAgIFJlZ2lzdHJhdGlvbiBPcGVuCgo3OjMwYW0tODozMGFtICAgICAg ICAgIENvbnRpbmVudGFsIEJyZWFrZmFzdAoKODozMGFtLTlhbSAgICAgICAgICAgICAgICBDb25m ZXJlbmNlIE9wZW5pbmcgU2Vzc2lvbiAoU2Fsb24gQSB0byBFKQoKOWFtLTEwYW0gICAgICAgICAg ICAgICAgICAgS2V5bm90ZTogTXVsdGktaG9wIE1vYmlsZSBXaXJlbGVzcyBOZXR3b3JrICAKRGVz aWduOiBJbXBsaWNpdCBDcm9zcy1MYXllciBMb3NzIE1vZGVscyBhbmQgUGVyZm9ybWFuY2UgU2Vu c2l0aXZpdGllcwrigKIgICAgICAgIFByb2Zlc3NvciBKb2huIEJhcmFzLCBVbml2ZXJzaXR5IG9m IE1hcnlsYW5kCgoxMGFtLTEwOjMwYW0gICAgICAgICAgICBCcmVhawoKMTA6MzBhbS0xMjoxNXBt ICAgICAgRXhwZXJpbWVudGFsIG5ldHdvcmtzIChTZXNzaW9uIGNoYWlyOiBQZXRlciAgClN0ZWVu a2lzdGUpCuKAoiAgICAgICAgQXNzZXNzbWVudCBvZiBVcmJhbi1TY2FsZSBXaXJlbGVzcyBOZXR3 b3JrcyB3aXRoIGEgU21hbGwgIApOdW1iZXIgb2YgTWVhc3VyZW1lbnRzCkpvc2h1YSBSb2JpbnNv biAoUmljZSBVbml2ZXJzaXR5LCBVUyksIFJhbSBTd2FtaW5hdGhhbiAoSFAgTGFicywgVVMpLCAg CkVkd2FyZCBLbmlnaHRseSAoUmljZSBVbml2ZXJzaXR5LCBVUykK4oCiICAgICAgICBDYWJlcm5l dDogVmVoaWN1bGFyIENvbnRlbnQgRGVsaXZlcnkgVXNpbmcgV2lGaQpKYWtvYiBFcmlrc3NvbiAo TUlULCBVUyksIEhhcmkgQmFsYWtyaXNobmFuIChNYXNzYWNodXNldHRzIEluc3RpdHV0ZSAgCm9m IFRlY2hub2xvZ3ksIFVTKSwgU2FtdWVsIE1hZGRlbiAoTUlULCBVUykK4oCiICAgICAgICBFeHBl cmllbmNlcyBpbiBhIDNHIE5ldHdvcms6IEludGVycGxheSBiZXR3ZWVuIHRoZSBXaXJlbGVzcyAg CkNoYW5uZWwgYW5kIEFwcGxpY2F0aW9ucwpYaW4gTGl1IChOb3J0aGVhc3Rlcm4gVW5pdmVyc2l0 eSwgVVMpLCBTcmlkaGFyIE1hY2hpcmFqdSAoU3ByaW50LCBVUyksICAKTXVrdW5kIFNlc2hhZHJp IChTcHJpbnQgQXBwbGllZCBSZXNlYXJjaCwgVVMpLCBBc2h3aW4gU3JpZGhhcmFuICAKKFNwcmlu dCBBVEwsVVMpLCBIdWkgWmFuZyAoU3ByaW50LCBVUykK4oCiICAgICAgICBBbiBFbXBpcmljYWwg U3R1ZHkgb2YgVUhGIFJGSUQgUGVyZm9ybWFuY2UKTWljaGFlbCBCdWV0dG5lciAoVW5pdmVyc2l0 eSBvZiBXYXNoaW5ndG9uLCBVUyksIERhdmlkIFdldGhlcmFsbCAgCihVbml2ZXJzaXR5IG9mIFdh c2hpbmd0b24sIFVTKQoKMTI6MTVwbS0yOjAwcG0gICAgICAgIEx1bmNoIGFuZCBLZXlub3RlIFBy ZXNlbnRhdGlvbiAoU2Fsb24gRiB0byBKKQrigKIgICAgICAgIOKAnEZyb20gU2VsZi1Gb3JtaW5n IE1vYmlsZSBOZXR3b3JrcyB0byBTZWxmLUZvcm1pbmcgTW9iaWxlICAKQ29udGVudCBTZXJ2aWNl c+KAnSwgUHJlc3RvbiBNYXJzaGFsbCwgcHJvZ3JhbSBtYW5hZ2VyLCBEQVJQQQoKMjowMHBtLTM6 NDVwbSAgICAgICAgICBNb2JpbGUgQ29tcHV0aW5nIChTZXNzaW9uIGNoYWlyOiBSYWdodXBhdGh5 ICAKU2l2YWt1bWFyKQrigKIgICAgICAgIFJlbGF5cywgQmFzZSBTdGF0aW9ucywgYW5kIE1lc2hl czogRW5oYW5jaW5nIE1vYmlsZSBOZXR3b3JrcyAgCndpdGggSW5mcmFzdHJ1Y3R1cmUKTmlsYW5q YW4gQmFuZXJqZWUgKFVNYXNzLUFtaGVyc3QsIFVTKSwgTWFyayBDb3JuZXIgKFVuaXZlcnNpdHkg b2YgIApNYXNzYWNodXNldHRzLCBVUykgLCBEb24gVG93c2xleSAoVW5pdmVyc2l0eSBvZiBNYXNz YWNodXNldHRzIGF0ICAKQW1oZXJzdCwgVVMpICwgQnJpYW4gTGV2aW5lIChVbml2LiBvZiBNYXNz YWNodXNldHRzIEFtaGVyc3QsIFVTKQrigKIgICAgICAgIEVuaGFuY2luZyBJbnRlcmFjdGl2ZSBX ZWIgQXBwbGljYXRpb25zIGluIEh5YnJpZCBOZXR3b3JrcwpBcnVuYSBCYWxhc3VicmFtYW5pYW4g KFVuaXZlcnNpdHkgb2YgTWFzc2FjaHVzZXR0cywgQW1oZXJzdCwgVVMpLCAgCkJyaWFuIExldmlu ZSAoVW5pdi4gb2YgTWFzc2FjaHVzZXR0cyBBbWhlcnN0LCBVUykgLCBBcnVuIFZlbmthdGFyYW1h bmkgIAooVU1hc3MgQW1oZXJzdCwgVVMpCuKAoiAgICAgICAgTWVkaWEgU2hhcmluZyBiYXNlZCBv biBDb2xvY2F0aW9uIFByZWRpY3Rpb24gaW4gVXJiYW4gIApUcmFuc3BvcnQKTGlhbSBNY05hbWFy YSAoVW5pdmVyc2l0eSBDb2xsZWdlIExvbmRvbiwgVUspLCBDZWNpbGlhIE1hc2NvbG8gIAooVW5p dmVyc2l0eSBvZiBDYW1icmlkZ2UsIFVLKSwgTGljaWEgQ2FwcmEgKFVuaXZlcnNpdHkgQ29sbGVn ZSBMb25kb24sICAKVUspCuKAoiAgICAgICAgQnJlYWRDcnVtYnM6IEZvcmVjYXN0aW5nIE1vYmls ZSBDb25uZWN0aXZpdHkKQW50aG9ueSBOaWNob2xzb24gKFVuaXZlcnNpdHkgb2YgTWljaGlnYW4s IFVTKSwgQnJpYW4gTm9ibGUgIAooVW5pdmVyc2l0eSBvZiBNaWNoaWdhbiwgVVMpCgozOjQ1cG0t NDowMHBtICAgICAgICAgIEJyZWFrCgo0OjAwcG0tNjowMHBtICAgICAgICAgIFN0dWRlbnQgUG9z dGVycyBhbmQgRGVtb3MgKFNhbG9uIEYgdG8gSikKCjY6MDBwbS03OjE1cG0gICAgICAgICAgT3Bl biBTSUdNT0JJTEUgQnVzaW5lc3MgTWVldGluZwoKCldlZG5lc2RheSwgU2VwdGVtYmVyIDE3Cgo4 OjAwYW0tNTowMHBtICAgICAgICAgIFJlZ2lzdHJhdGlvbiBPcGVuCgo3OjMwYW0tODozMGFtICAg ICAgICAgIENvbnRpbmVudGFsIEJyZWFrZmFzdAoKODozMGFtLTEwOjE1YW0gICAgICAgIFNlY3Vy aXR5IChTZXNzaW9uIGNoYWlyOiBLYW5nIFNoaW4pCuKAoiAgICAgICAgR0FuR1M6IEdhdGhlciwg QXV0aGVudGljYXRlIOKAmG4gR3JvdXAgU2VjdXJlbHkKQ2hpYS1Ic2luIENoZW4gKEFjYWRlbWlh IFNpbmljYSwgVFcpLCBDaHVuZy1XZWkgQ2hlbiAoTmF0aW9uYWwgVHNpbmcgIApIdWEgVW5pdmVy c2l0eSwgVFcpLCBDeW50aGlhIEt1byAoQ2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHksIFVTKSAs ICAKWWFuIEhhbyBMYWkgKE5hdGlvbmFsIENodW5nIEhzaW5nIFVuaXZlcnNpdHksIFRXKSwgSm9u YXRoYW4gTWNDdW5lICAKKENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5LCBVUyksIEFocmVuIFN0 dWRlciAoQ2FybmVnaWUgTWVsbG9uICAKVW5pdmVyc2l0eSwgVVMpLCBBZHJpYW4gUGVycmlnIChD YXJuZWdpZSBNZWxsb24gVW5pdmVyc2l0eSwgVVMpLCBCby0gCllpbiBZYW5nIChBY2FkZW1pYSBT aW5pY2EsIFRXKSwgVHpvbmctQ2hlbiBXVSAoTmF0aW9uYWwgVGFpd2FuICAKVW5pdmVyc2l0eSBv ZiBTY2llbmNlICYgVGVjaG5vbG9neSwgVFcpCuKAoiAgICAgICAgT24gRmFzdCBhbmQgQWNjdXJh dGUgRGV0ZWN0aW9uIG9mIFVuYXV0aG9yaXplZCBXaXJlbGVzcyAgCkFjY2VzcyBQb2ludHMgVXNp bmcgQ2xvY2sgU2tld3MKICAgIFN1bWFuIEphbmEgKFVuaXZlcnNpdHkgb2YgVXRhaCwgVVMpLCBT bmVoYSBLYXNlcmEgKFVuaXZlcnNpdHkgb2YgIApVdGFoLCBVUykK4oCiICAgICAgICBXaXJlbGVz cyBEZXZpY2UgSWRlbnRpZmljYXRpb24gd2l0aCBSYWRpb21ldHJpYyBTaWduYXR1cmVzClZsYWRp bWlyIEJyaWsgKFVuaXZlcnNpdHkgb2YgV2lzY29uc2luIGF0IE1hZGlzb24sIFVTKSwgU3VtYW4g QmFuZXJqZWUgIAooVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4sIFVTKSAsIE1hcmNvIEdydXRlc2Vy IChXSU5MQUIgLyBSdXRnZXJzICAKVW5pdmVyc2l0eSxVUyksIFNhbmdobyBPaCAoV0lOTEFCLCBS dXRnZXJzIFVuaXZlcnNpdHksIFVTKQrigKIgICAgICAgIFJhZGlvLXRlbGVwYXRoeTogRXh0cmFj dGluZyBhIFNlY3JldCBLZXkgZnJvbSBhbiAgClVuYXV0aGVudGljYXRlZCBXaXJlbGVzcyBDaGFu bmVsClN1aGFzIE1hdGh1ciAoV0lOTEFCLCBSdXRnZXJzIFVuaXZlcnNpdHksIFVTKSwgV2FkZSBU cmFwcGUgKFdJTkxBQiwgIApSdXRnZXJzIFVuaXZlcnNpdHksIFVTKSAsIE5hcmF5YW4gTWFuZGF5 YW0gKFdJTkxBQiwgUnV0Z2VycyAgClVuaXZlcnNpdHksIFVTKSAsIENodW54dWFuIFllIChJbnRl ckRpZ2l0YWwgQ29tbXVuaWNhdGlvbnMgIApDb3Jwb3JhdGlvbiwgVVMpICwgQWxleCBSZXpuaWsg KEludGVyRGlnaXRhbCBDb21tdW5pY2F0aW9ucyAgCkNvcnBvcmF0aW9uLCBVUykKCjEwOjE1YW0t MTA6NDVhbSAgICAgIEJyZWFrCgoxMDo0NWFtLTEyOjE1cG0gICAgICBTcGVjdHJ1bSBzZW5zaW5n IGFuZCBtYW5hZ2VtZW50IChTZXNzaW9uIGNoYWlyOiAgClZpY3RvciBCYWhsKQrigKIgICAgICAg IGVCYXkgaW4gdGhlIFNreTogU3RyYXRlZ3ktUHJvb2YgV2lyZWxlc3MgU3BlY3RydW0gQXVjdGlv bnMKWGlhIFpob3UgKFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSwgU2FudGEgQmFyYmFyYSwgVVMp LCBTb3JhYmggR2FuZGhpICAKKFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSwgU2FudGEgQmFyYmFy YSwgVVMpLCBTdWJoYXNoIFN1cmkgIAooVW5pdmVyc2l0eSBvZkNhbGlmb3JuaWEgYXQgU2FudGEg QmFyYmFyYSwgVVMpLCBIYWl0YW8gWmhlbmcgKFVuaXYuIG9mICAKQ2FsaWZvcm5pYSwgU2FudGEg QmFyYmFyYSwgVVMpCuKAoiAgICAgICAgSW4tYmFuZCBTcGVjdHJ1bSBTZW5zaW5nIGluIENvZ25p dGl2ZSBSYWRpbyBOZXR3b3JrczogRW5lcmd5ICAKRGV0ZWN0aW9uIG9yIEZlYXR1cmUgRGV0ZWN0 aW9uPwogICAgSHlvaWwgS2ltIChVbml2ZXJzaXR5IG9mIE1pY2hpZ2FuLCBVUyksIEthbmcgRy4g U2hpbiAoVW5pdmVyc2l0eSAgCm9mIE1pY2hpZ2FuLCBVUykK4oCiICAgICAgICBBZHZhbmNpbmcg V2lyZWxlc3MgTGluayBTaWduYXR1cmVzIGZvciBMb2NhdGlvbiBEaXN0aW5jdGlvbgpKdW54aW5n IFpoYW5nIChVbml2ZXJzaXR5IG9mIFV0YWgsIFVTKSwgTW9oYW1tYWQgRmlyb296IChVbml2ZXJz aXR5IG9mICAKVXRhaCwgVVMpLCBOZWFsIFBhdHdhcmkgKFVuaXZlcnNpdHkgb2YgVXRhaCwgVVMp LCBTbmVoYSBLYXNlcmEgIAooVW5pdmVyc2l0eSBvZiBVdGFoLCBVUykK4oCiICAgICAgICBDaGFs bGVuZ2VzOiBXaWRlLUFyZWEgd2lyZWxlc3NzIE5FVHdvcmtzIChXQU5FVHMpCiAgICBTdXJlc2gg U2luZ2ggKFBvcnRsYW5kIFN0YXRlIFVuaXZlcnNpdHksIFVTKQoKMTI6MTVwbS0xOjQ1cG0gICAg ICAgIEx1bmNoIChTYWxvbiBGIHRvIEopIGFuZCBOMiBXb21lbiBMdW5jaCAocm9vbSBUQkQpCgox OjQ1cG0tMzowMHBtICAgICAgICAgIEFsZ29yaXRobXMgYW5kIE1vZGVsaW5nIChTZXNzaW9uIGNo YWlyOiBSYW0gIApSYW1hbmF0aGFuKQrigKIgICAgICAgIEFDRVM6IEFkYXB0aXZlIENsb2NrIEVz dGltYXRpb24gYW5kIFN5bmNocm9uaXphdGlvbiBVc2luZyAgCkthbG1hbiBGaWx0ZXJpbmcKQmVu amFtaW4gSGFtaWx0b24gKEdlb3JnaWEgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3ksIFVTKSwgWGlh b2xpIE1hICAKKEdlb3JnaWEgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3ksIFVTKSwgUWkgWmhhbyAo QVQmVCBMYWJz4oCUUmVzZWFyY2gsICAKVVMpLCBKdW4gWHUgKEdlb3JnaWEgVGVjaCwgVVMpCuKA oiAgICAgICAgV2lNQVggUmVsYXkgTmV0d29ya3M6IE9wcG9ydHVuaXN0aWMgU2NoZWR1bGluZyB0 byBFeHBsb2l0ICAKTXVsdGl1c2VyIERpdmVyc2l0eSBhbmQgRnJlcXVlbmN5IFNlbGVjdGl2aXR5 ClN1cHJhdGltIERlYiAoQmVsbCBMYWJzIFJlc2VhcmNoIEluZGlhLCBJTiksIFZpdmVrIE1oYXRy ZSAoTW90b3JvbGEsICAKVVMpLCBWZW5rYXRlc2ggUmFtYWl5YW4gKEluZGlhbiBJbnN0aXR1dGUg b2YgU2NpZW5jZSwgSU4pCuKAoiAgICAgICAgQ2FwYWNpdHkgb2YgTGFyZ2UgU2NhbGUgV2lyZWxl c3MgTmV0d29ya3MgdW5kZXIgR2F1c3NpYW4gIApDaGFubmVsIE1vZGVsClNoaSBMaSAoVHNpbmdo dWEgVW5pdmVyc2l0eSwgQ04pLCBTaGkgTGkgKFRzaW5naHVhIFVuaXZlcnNpdHksIENOKTsgIApZ dW5oYW8gTGl1IChIb25nIEtvbmcgVW5pdmVyc2l0eSBvZiBTY2llbmNlIGFuZCBUZWNobm9sb2d5 LCBISyk7IFhpYW5nLSAKWWFuZyBMaSAoSWxsaW5vaXMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3ks IFVTKQoKMzowMHBtLTM6MzBwbSAgICAgICAgICBCcmVhawoKMzozMHBtLTU6MDBwbSAgICAgICAg ICBXaXJlbGVzcyBQcm90b2NvbHMgKFNlc3Npb24gY2hhaXI6IExpbGkgUWl1KQrigKIgICAgICAg IENhbiBDU01BL0NBIE5ldHdvcmtzIEJlIE1hZGUgRmFpcj8KICAgIFlpbmcgSmlhbiAoVW5pdmVy c2l0eSBvZiBGbG9yaWRhLCBVUyksIFNoaWdhbmcgQ2hlbiAoVW5pdmVyc2l0eSBvZiAgCkZsb3Jp ZGEsIFVTKQrigKIgICAgICAgIEhvcml6b246IEJhbGFuY2luZyBUQ1Agb3ZlciBNdWx0aXBsZSBQ YXRocyBpbiBXaXJlbGVzcyBNZXNoICAKTmV0d29yawpCb3ppZGFyIFJhZHVub3ZpYyAoTWljcm9z b2Z0IFJlc2VhcmNoIENhbWJyaWRnZSwgVUspLCBDaHJpc3RvcyAgCkdrYW50c2lkaXMgKE1pY3Jv c29mdCBSZXNlYXJjaCwgVUspLCBEaW5hbiBHdW5hd2FyZGVuYSAoTWljcm9zb2Z0ICAKUmVzZWFy Y2gsIFVLKSwgUGV0ZXIgS2V5IChNaWNyb3NvZnQgUmVzZWFyY2gsIFVLKQrigKIgICAgICAgIEFu IEFkYXB0aXZlLCBIaWdoIFBlcmZvcm1hbmNlIE1BQyBmb3IgTG9uZy1EaXN0YW5jZSBNdWx0aWhv cCAgCldpcmVsZXNzIE5ldHdvcmtzClNlcmdpdSBOZWRldnNjaGkgKFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYSwgQmVya2VsZXksIFVTKSwgUmFiaW4gUGF0cmEgIAooVUMgQmVya2VsZXksIFVTKSAs IFNvbmVzaCBTdXJhbmEgKFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSBhdCAgCkJlcmtlbGV5LCBV UykgLCBTeWx2aWEgUmF0bmFzYW15IChJbnRlbCBSZXNlYXJjaCBCZXJrZWxleSwgVVMpICwgIApM YWtzaG1pbmFyYXlhbmFuIFN1YnJhbWFuaWFuIChOZXcgWW9yayBVbml2ZXJzaXR5LCBVUykgLCBF cmljIEJyZXdlciAgCihVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEgYXQgQmVya2VsZXksIFVTKQri gKIgICAgICAgIENoYWxsZW5nZXM6IEF1dG9tYXRlZCBEZXNpZ24gb2YgTmV0d29ya2luZyBQcm90 b2NvbHMKVm9sa2FuIFJvZG9wbHUgKFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSwgU2FudGEgQmFy YmFyYSwgVVMpLCBBbWlyICAKQW1pbnphZGVoIEdvaGFyaSAoVW5pdmVyc2l0eSBvZiBDYWxpZm9y bmlhLCBTYW50YSBCYXJiYXJhLCBVUykKCjU6MDBwbS02OjMwcG0gICAgICAgICAgU3R1ZGVudCBQ b3N0ZXIgQ29tcGV0aXRpb24gVGFsa3MKCkV2ZW5pbmcgICAgICAgICAgICAgICAgICAgICAgIENv bmZlcmVuY2UgQmFucXVldAoKClRodXJzZGF5LCBTZXB0ZW1iZXIgMTgKCjg6MDBhbS01OjAwcG0g ICAgICAgICAgUmVnaXN0cmF0aW9uIE9wZW4KCjc6MzBhbS04OjMwYW0gICAgICAgICAgQ29udGlu ZW50YWwgQnJlYWtmYXN0Cgo4OjMwYW0tMTA6MTVhbSAgICAgICAgQ3Jvc3MtbGF5ZXIgcHJvdG9j b2xzIChTZXNzaW9uIGNoYWlyOiBDZWNpbGlhICAKTWFzY29sbykK4oCiICAgICAgICBNb2R1bGF0 aW9uIFJhdGUgQWRhcHRhdGlvbiBpbiBVcmJhbiBhbmQgVmVoaWN1bGFyICAKRW52aXJvbm1lbnRz OiBDcm9zcy1sYXllciBJbXBsZW1lbnRhdGlvbiBhbmQgRXhwZXJpbWVudGFsIEV2YWx1YXRpb24K ICAgIEpvc2VwaCBDYW1wIChSaWNlIFVuaXZlcnNpdHksIFVTKSwgRWR3YXJkIEtuaWdodGx5IChS aWNlICAKVW5pdmVyc2l0eSwgVVMpCuKAoiAgICAgICAgT24gTGluay1MYXllciBSZWxpYWJpbGl0 eSBhbmQgU3RhYmlsaXR5IGZvciBXaXJlbGVzcyAgCkNvbW11bmljYXRpb24KU29ocmFhYiBTb2x0 YW5pIChNaWNoaWdhbiBTdGF0ZSBVbml2ZXJzaXR5LCBVUyksIEtpcmFuIE1pc3JhIChNaWNoaWdh biAgClN0YXRlIFVuaXZlcnNpdHksIFVTKSwgSGF5ZGVyIFJhZGhhIChNaWNoaWdhbiBTdGF0ZSBV bml2ZXJzaXR5LCBVUykK4oCiICAgICAgICBUYWtpbmcgdGhlIFN0aW5nIG91dCBvZiBDYXJyaWVy IFNlbnNlOiBJbnRlcmZlcmVuY2UgIApDYW5jZWxsYXRpb24gZm9yIFdpcmVsZXNzIExBTnMKRGFu aWVsIEhhbHBlcmluIChVbml2ZXJzaXR5IG9mIFdhc2hpbmd0b24sIFVTKSwgVGhvbWFzIEFuZGVy c29uICAKKFVuaXZlcnNpdHkgb2YgV2FzaGluZ3RvbiwgVVMpLCBEYXZpZCBXZXRoZXJhbGwgKFVu aXZlcnNpdHkgb2YgIApXYXNoaW5ndG9uLCBVUykK4oCiICAgICAgICBaaXBUeDogRXhwbG9pdGlu ZyB0aGUgR2FwIGJldHdlZW4gQml0IEVycm9ycyBhbmQgUGFja2V0IExvc3MKTmF0ZSBLdXNobWFu IChNSVQsIFVTKSwgQ2hpbmctSnUgTGluIChOYXRpb25hbCBUYWl3YW4gVW5pdmVyc2l0eSwgVFcp LCAgCkRpbmEgS2F0YWJpIChNSVQsIFVTKQoKMTA6MTVhbS0xMDo0NWFtICAgICAgQnJlYWsKCjEw OjQ1YW0tMTI6MTVwbSAgICAgIFBhbmVsOiBDcm9zcy1kb21haW4gUmVzZWFyY2g6IFRoZSBGdXR1 cmUgb2YgIApNb2JpbGUgQ29tcHV0aW5nIGFuZCBOZXR3b3JrcwrigKIgICAgICAgIE1vZGVyYXRv cjogUHJvZmVzc29yIENoaWFyYSBQZXRyaW9saSwgVW5pdmVyc2l0eSBvZiBSb21lICdMYSAgClNh cGllbnphJwrigKIgICAgICAgIFBhcnRpY2lwYW50czogVEJECgoxMjoxNXBtLTE6NDVwbSAgICAg ICAgTHVuY2ggKFNhbG9uIEYgdG8gSikKCjE6NDVwbS0zOjMwcG0gICAgICAgICAgTXVsdGktaG9w IHdpcmVsZXNzIG5ldHdvcmtzIChTZXNzaW9uIGNoYWlyOiAgCkFzaHV0b3NoIFNhYmhhcndhbCkK 4oCiICAgICAgICBEaXR0bzogQSBTeXN0ZW0gZm9yIE9wcG9ydHVuaXN0aWMgQ2FjaGluZyBpbiBN dWx0aS1ob3AgIApXaXJlbGVzcyBOZXR3b3JrcwpGYWhhZCBEb2dhciAoQ2FybmVnaWUgTWVsbG9u IFVuaXZlcnNpdHksIFVTKSwgRGF2aWQgQW5kZXJzZW4gKENNVSwgIApVUykgLCBIaW1hYmluZHUg UHVjaGEgKENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5LCBVUykgLCBBbWFyICAKUGhhbmlzaGF5 ZWUgKENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5LCBVUykgLCBPbGF0dW5qaSBSdXdhc2UgIAoo Q2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHksIFVTKQrigKIgICAgICAgIE9uIHRoZSBDcml0aWNh bCBQaGFzZSBUcmFuc2l0aW9uIFRpbWUgb2YgV2lyZWxlc3MgTXVsdGktaG9wICAKTmV0d29ya3Mg d2l0aCBSYW5kb20gRmFpbHVyZXMKRmVpIFhpbmcgKE5vcnRoIENhcm9saW5hIFN0YXRlIFVuaXZl cnNpdHksIFVTKSwgV2VueWUgV2FuZyAoTkMgU3RhdGUgIApVbml2ZXJzaXR5LCBVUykK4oCiICAg ICAgICBVbmRlcnN0YW5kaW5nIENvbmdlc3Rpb24gQ29udHJvbCBpbiBNdWx0aS1ob3AgV2lyZWxl c3MgTWVzaCAgCk5ldHdvcmtzClN1bWl0IFJhbmd3YWxhIChVbml2ZXJzaXR5IG9mIFNvdXRoZXJu IENhbGlmb3JuaWEsIFVTKSwgQXBvb3J2YSBKaW5kYWwgIAooVW5pdmVyc2l0eSBvZiBTb3V0aGVy biBDYWxpZm9ybmlhLCBVUykgLCBLaS1Zb3VuZyBKYW5nIChVbml2ZXJzaXR5IG9mICAKU291dGhl cm4gQ2FsaWZvcm5pYSwgVVMpLCBLb25zdGFudGlub3MgUHNvdW5pcyAoVW5pdmVyc2l0eSBvZiBT b3V0aGVybiAgCkNhbGlmb3JuaWEsIFVTKSwgUmFtZXNoIEdvdmluZGFuIChVbml2ZXJzaXR5IG9m IFNvdXRoZXJuIENhbGlmb3JuaWEsIFVTKQrigKIgICAgICAgIEluY2VudGl2ZS1Db21wYXRpYmxl IE9wcG9ydHVuaXN0aWMgUm91dGluZyBmb3IgV2lyZWxlc3MgIApOZXR3b3JrcwpGYW4gV3UgKFNV TlkgQnVmZmFsbywgVVMpLCBUaW5ndGluZyBDaGVuIChTVU5ZIGF0IEJ1ZmZhbG8sIFVTKSwgU2hl bmcgIApaaG9uZyAoU1VOWSBCdWZmYWxvLCBVUykgLCBMaSAoRXJyYW4pIExpIChCZWxsIExhYnMs IEx1Y2VudCAgClRlY2hub2xvZ2llcywgVVMpICwgWS4gUmljaGFyZCBZYW5nIChZYWxlIFVuaXZl cnNpdHksIFVTKQoKMzozMHBtICAgICAgICAgICAgICAgICAgICAgICAgQ29uZmVyZW5jZSBBZGpv dXJucwoKRnJpZGF5LCBTZXB0ZW1iZXIgMTkKCjg6MDBhbS01OjAwcG0gICAgICAgICAgUmVnaXN0 cmF0aW9uIE9wZW4KCjg6MzBhbS01OjMwcG0gICAgICAgICAgQ29uY3VycmVudCBXb3Jrc2hvcHMg KFNhbG9uIEEgdG8gRSkK4oCiICAgICAgICBXSU5URUNICuKAoiAgICAgICAgTUVMVArigKIgICAg ICAgIFdpTlMtRFIK4oCiICAgICAgICBTZWUgd29ya3Nob3AgcGFnZXMgZm9yIGRldGFpbHMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQgbWFpbGlu ZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tZXh0Cg== From mext-bounces@ietf.org Wed Aug 20 02:29:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C9E3A6B3D; Wed, 20 Aug 2008 02:29: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 C40603A69E4 for ; Wed, 20 Aug 2008 02:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW1qKD2-vXKg for ; Wed, 20 Aug 2008 02:29:45 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 421433A67ED for ; Wed, 20 Aug 2008 02:29:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7K9Taed015568; Wed, 20 Aug 2008 12:29:42 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 12:29:30 +0300 Received: from vaebe103.NOE.Nokia.com ([10.160.244.58]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 12:29:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Aug 2008 12:29:24 +0300 Message-ID: <701586182114824C876BD526F939600A664CA5@vaebe103.NOE.Nokia.com> In-Reply-To: <000001c901c0$b2791c80$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [gmane.ietf.announce]I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt Thread-Index: AckBH5ttKi8uVKHSSpGXoAMGi4ap7wAn4ThwADmOWhA= References: <87myjay81r.fsf@natisbad.org> <871w0my55t.fsf@natisbad.org> <000001c901c0$b2791c80$1220fea9@amer.cisco.com> From: To: , , X-OriginalArrivalTime: 20 Aug 2008 09:29:27.0184 (UTC) FILETIME=[3D874900:01C902A7] X-Nokia-AV: Clean Subject: Re: [MEXT] [gmane.ietf.announce]I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-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: Really interesting draft. #Sri Although this is not within the scope subjected draft but this will make BU/BAck to be carried within IKE exchange isn't it? If so then it may need some additional - configuration types for BU/Back. I think DPD very much resembles the view of binding revocation and Ack in MIP. Isn' it? Is there any other signalling (except BU/BAck) of MIP can leverage DPE? Regds Preeti >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of ext Sri Gundavelli >Sent: 19 August, 2008 08:59 >To: 'Arnaud Ebalard'; 'IETF MEXT WG' >Subject: Re: [MEXT] >[gmane.ietf.announce]I-DAction:draft-ebalard-mext-pfkey-enhance d-migrate-00.txt > >Hi Arnaud, > >A quick review of the draft, its well written. Good work !!! >this is needed. Just one basic question. Does this or existing >PF_KEY interface allow the MIP process to learn Dead Peer >Detection events from the IKE process ? Does this already >exist in PF_KEY or its extensions ? I guess, I'm looking at >the way for MIP process to leverage peer termination events >that are learnt from the IKE layer. Any pointer ? > >Regards >Sri > > > > > > > > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >> Of Arnaud Ebalard >> Sent: Monday, August 18, 2008 3:44 AM >> To: IETF MEXT WG >> Subject: Re: [MEXT] [gmane.ietf.announce] >> I-DAction:draft-ebalard-mext-pfkey-enhanced-migrate-00.txt >> >> Hi, [Replying to the first >*broken* mail] >> >> for those interested by the topic ... >> >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > Title : PF_KEY Extension as an Interface between >> > Mobile IPv6 and IPsec/IKE >> > Author(s) : A. Ebalard, S. Decugis >> > Filename : >> draft-ebalard-mext-pfkey-enhanced-migrate-00.txt >> > Pages : 21 >> > Date : 2008-08-18 >> > >> > This document describes the need for an interface between >> Mobile IPv6 >> > and IPsec/IKE and show how the two protocols can interwork. An >> > extension of the PF_KEY framework is proposed which allows >> smooth and >> > solid operation of IKE in a Mobile IPv6 environment. >> > >> > This document is heavily based on a previous draft >[MIGRATE] written >> > by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. >It simply >> > reuses the MIGRATE mechanism defined in the expired >> document, removes >> > a companion extension (SADB_X_EXT_PACKET) based on implementation >> > feedback (complexity, limitations, ...) and fills the gap by very >> > simple changes to MIGRATE mechanism. This results in a >more simple >> > and consistent mechanism, which also proved to be easier to >> > implement. This document is expected to serve as a >continuation of >> > [MIGRATE] work. For that reason, the name of the >extension has been >> > kept. >> > >> > PF_KEY MIGRATE message serves as a carrier for updated address >> > information for both the in-kernel IPsec structures (SP/SA) >> and those >> > maintained by the key managers. This includes in-kernel SP/SA >> > endpoints, key manager maintained equivalents and >addresses used by >> > IKE_SA (current and to be negotiated). The extension is >helpful for >> > assuring smooth internetworking between Mobile IPv6 and >> IPsec/IKE for >> > the bootstrapping of mobile nodes and their movements. >> > >> > A URL for this Internet-Draft is: >> > >> http://www.ietf.org/internet-drafts/draft-ebalard-mext-pfkey-e >> nhanced-migrate-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. >> >> If you have comments/questions, do not hesitate. >> >> As posted previously, if you are interested by implementation/test >> details, there is more on the topic here: http://natisbad.org/MIPv6/ >> >> Cheers, >> >> a+ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 22 07:37:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199CE3A6984; Fri, 22 Aug 2008 07:37: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 055BC3A67E3 for ; Fri, 22 Aug 2008 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 2otvPLgVPrXv for ; Fri, 22 Aug 2008 07:21:42 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 063BC3A67E2 for ; Fri, 22 Aug 2008 07:21:42 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B6E35198739; Fri, 22 Aug 2008 17:21:50 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 6D7B319872C; Fri, 22 Aug 2008 17:21:50 +0300 (EEST) Message-ID: <48AECBCB.6010605@piuha.net> Date: Fri, 22 Aug 2008 17:23:07 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: "mext@ietf.org" , draft-ietf-mext-nemo-v4traversal@tools.ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Cc: Pasi Eronen Subject: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have reviewed this specification. I did not find any showstoppers, but there were a number of issues that need to be addressed. I am expecting a revised draft and some discussion about question marks below. Please find my detailed comments below. First the technical ones: > Scenario 3: Home Agent behind a NAT I think you are making your life unnecessarily hard. Is there a true demand for this? > 2) > configure one public address and make the home agents share the > public address. How would this work if the NAT happens to forward one BU to one home agent and the next BU the a second one? Please explain better or remove. > Another possible solution is to designate one home agent > on the home link for IPv4 traversal. The NAT device should associate > that home agent with the public IPv4 address configured on it for v4 > traversal. In all cases above, both the 'AAAA' and 'A' records > returned for a particular name MUST correspond to the same physical > home agent The first and third sentences seem to be in conflict. If one HA is used for IPv4, then presumably the other ones are used for IPv6. If so, when a mobile node moves from IPv6 care-of address to an IPv4 care-of address, it has to switch the home agent. > When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at > the foreign network, it SHOULD prioritize the IPv6 care-of address > for MIP6 its binding registration. The mobile node MUST NOT register > both IPv4 and IPv6 care-of addresses to its home agent. This is the priority, but its also likely to have the same problems as we have with dual stack hosts getting long timeouts due to trying out broken IPv6 connectivity. Look at the Stuart Cheshire's technical plenary presentation, for instance. I would suggest that you have an explicit specification of the recovery mechanism: trying out both in parallel, trying one first and then falling back -- I do not have the details but you have to have a recovery mechanism. Similarly, it would be very useful if the document contained better instruction about when a mobile node sets the F flag. If there is no NAT but a firewall, the mobile node may wish to use UDP encapsulation. Would it be possible to have the mobile node revert back UDP encapsulation if the direct encapsulation does not appear to be working? > Refresh Time > > A suggested time (in seconds) for the mobile node to refresh the > NAT binding. If set to zero, it is ignored. If this field is set > to all 1s it means that keepalives are not needed, i.e., no NAT > was detected. > How would a home agent know what behaviour to expect from a NAT in a visited network (e.g., user's home DSL box)? Please provide additional discussion on how to set this field, what the manageability considerations are, etc. > T > > This flag indicates, when set, that the sender of the binding > acknowledgement supports the TLV- tunnel format. > Does this really signal support or that the use of the requested TLV format will be granted? Why this matter is what happens when the BU has T=0. If the home agent supports TLV, does it set T=1 or T=0? (I later found an explanation about this in Section 5.1. Maybe it should be clarified earlier.) > The Type field MUST NOT be > assigned the values 4 or 6 to make sure that the receiver can tell > the difference between the Type field and the IP version field in a > packet that contains an IP header after UDP. See RFC 4928 and http://www.iana.org/assignments/version-numbers/version-numbers.xhtml In short, other protocols have done in the past, and restricted themselves to values 0 and 1, in order to allow for the (admittedly unlikely) allocation of a new IP version number. Please consider the same approach here. (And why do we have to distinguish between the TLV and IP -- I thought you negotiated the use of TLV?) > However, UDP MUST NOT be used to encapsulate > the binding update message when the mobile node is located in an > IPv6-enabled network. MUST NOT is quite strong here. I do not think the reasons for using MUST apply here. And indeed, there might be future needs to employ UDP over IPv6 as well, if there was a (bad) firewall that only support UDP and TCP passthrough. > The IANA should allocate and permanently register new TLV-header > types and Status field values from IETF RFC publication. This is > for all RFC types including standards track, informational, and > experimental status that originate from the IETF and have been > approved by the IESG for publication. > Please use RFC 5226 terminology instead. I think you mean: New TLV-header types and Status field values are allocated via IETF Review [RFC5226]. Missing things: - Is it really the case that this document does not need to reference RFC 4877, even if both talk about the encapsulation formats? - What about IKEv2, RFC 4306? - There is no discussion of the interaction between NAT detection & traversal in IPsec vs. in DSMIP. - There is no discussion about procedures for IPv4 addresses "returning home". You could rule that not supported, but even in that case it should at least be mentioned. Editorial: > In this specification, extensions are defined for the binding update > and binding acknowledgement. It should be noted that all these > extensions apply to cases where the mobile node communicates with a > Mobility Anchor Point (MAP) as defined in [RFC4140 ]. The > requirements on the MAP are identical to those stated for the home > agent, although it is unlikely that NAT traversal would be needed > with a MAP as it is expected to be in the same address domain. > First, 4140 should be 4140bis. But I am curious that you mention HMIP and not any of the other things that might apply equally well, such as PMIP. > NAT box s/NAT box/NAT/ > The security implications of this > mechanism are discussed in the security considerations section. > This appears in Section 3.3.1. This does not seem like a very useful statement. Everything in this document is hopefully discussed in the security considerations section! Consider removing the statement. > When a mobile node acquires both IPv4 and IPv6 care-of addresses at > the foreign network, it SHOULD prioritize the IPv6 care-of address > for MIP6 its binding registration. ... for its MIP6 binding ... ? > If no NAT > is detected between the mobile node and the home agent, the mobile > node assumes that it is in a foreign network that supports IPv4 > public addresses. Otherwise, the mobile node assumes that private > addresses are used in the foreign network. Note that this assumption > is only valid for the purposes of the signaling presented in this > specification. A mobile node SHOULD NOT assume that its IPv4 address > is globally unique if a NAT device was not detected. This was very hard to parse. What is "supports IPv4 public addresses"? How is that different from "MN's IPv4 is globally unique"? Isn't the only thing that you need to know here: can the mobile node be reached from the home agent by sending an IPv4 packet to its address? > 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) I was surprised that this section says nothing about keeping the port numbers in the binding cache entry. Section 5.2 talks about this, but that is much later. > Additionally, this option can include an IPv4 home address in the > case of Dynamic IPv4 home address configuration (i.e., if the > unspecified IPv4 address was included in the binding update). Can? It always will, right? s/can include/includes/ Or are you considering some error case. Please be more specific here. > To > avoid confusion in the correspondent node, the mobile node SHOULD > deregister its binding with each correspondent node by sending a > deregistration binding update. This text (and surrounding paragraph) in Section 6.1 feels like it is in the wrong place. This has nothing to do with IPsec and IKE, its part of the basic behaviour of the mobile node. > .. requires > an option type. This option is included in the Mobility header > described in [RFC3775]. This was hard to read. Maybe: ... requires a new option type allocation for a mobility option [RFC 3775]. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 22 17:22:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AD128C110; Fri, 22 Aug 2008 17:22: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 7CD0028C110 for ; Fri, 22 Aug 2008 17:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 K+J0f7FPEHqd for ; Fri, 22 Aug 2008 17:22:45 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 7C5813A69B4 for ; Fri, 22 Aug 2008 17:22:43 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KWgs5-0003BV-9g; Sat, 23 Aug 2008 10:22:50 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Sat, 23 Aug 2008 10:20:40 +1000 From: Hesham Soliman To: Jari Arkko , "mext@ietf.org" , Message-ID: Thread-Topic: AD review of mext-nemo-v4traversal Thread-Index: AckEthKipNnB+/gyc0eqS7jbQ19yIg== In-Reply-To: <48AECBCB.6010605@piuha.net> Mime-version: 1.0 Cc: Pasi Eronen Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 23/08/08 12:23 AM, "Jari Arkko" wrote: > I have reviewed this specification. I did not find any showstoppers, but > there were a number of issues that need to be addressed. I am expecting > a revised draft and some discussion about question marks below. > > Please find my detailed comments below. First the technical ones: > >> Scenario 3: Home Agent behind a NAT > I think you are making your life unnecessarily hard. Is there a true > demand for this? => Not in my opinion, but we discussed this for a long time on the list and some people thought it was needed. This paragraph you quote doesn't do anything though, it simply mentions the scenario and says that the spec assumes a public IPv4 address. The offending text is below. > >> 2) >> configure one public address and make the home agents share the >> public address. > > How would this work if the NAT happens to forward one BU to one home > agent and the next BU the a second one? > > Please explain better or remove. => This is not right of course, not sure how it slipped into the text. > >> Another possible solution is to designate one home agent >> on the home link for IPv4 traversal. The NAT device should associate >> that home agent with the public IPv4 address configured on it for v4 >> traversal. In all cases above, both the 'AAAA' and 'A' records >> returned for a particular name MUST correspond to the same physical >> home agent > The first and third sentences seem to be in conflict. If one HA is used > for IPv4, then presumably the other ones are used for IPv6. If so, when > a mobile node moves from IPv6 care-of address to an IPv4 care-of > address, it has to switch the home agent. => Correct. Although that scenario is not seen as important, I would prefer to remove those three sentences from the spec. > >> When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at >> the foreign network, it SHOULD prioritize the IPv6 care-of address >> for MIP6 its binding registration. The mobile node MUST NOT register >> both IPv4 and IPv6 care-of addresses to its home agent. > > This is the priority, but its also likely to have the same problems as > we have with dual stack hosts getting long timeouts due to trying out > broken IPv6 connectivity. Look at the Stuart Cheshire's technical > plenary presentation, for instance. => Oh, I'm aware of the problems with IPv6 connectivity *today*. However, I really don't think we should design the spec around what can be seen as a transient problem. I mean, how many people outside IETF know about those problems? The decision about CoA selection has profound implications that will stay in the spec for a long time. IPv6's connectivity issues are, IMO, clearly tied to the fact that it's not used today. Once it's used enough for this spec to be deployed, I doubt very much we will be discussing how slow it is compared to IPv4. So, I'm reluctant to add further complication to CoA selection based on this issue. The recommendation to use IPv6 first follows RFc 2893 (now 4213). I would suggest that you have an > explicit specification of the recovery mechanism: trying out both in > parallel, trying one first and then falling back -- I do not have the > details but you have to have a recovery mechanism. => You mean ICE? :) seriously, how complicated do you want it to be? We could do a "try v6 and if BU is rejected/timed out three times then try v4" is that ok? > > Similarly, it would be very useful if the document contained better > instruction about when a mobile node sets the F flag. If there is no NAT > but a firewall, the mobile node may wish to use UDP encapsulation. Would > it be possible to have the mobile node revert back UDP encapsulation if > the direct encapsulation does not appear to be working? => Sure, section 5.1 says: The mobile node can request to always use UDP encapsulation by setting the F flag in the binding update. If the home agent does not agree to the request, it MUST reject the binding update with the new Status code: 144 Cannot force UDP encapsulation Alternatively, the home agent can force UDP encapsulation by setting the F flag in the NAT detection option included in the binding acknowledgement. > >> Refresh Time >> >> A suggested time (in seconds) for the mobile node to refresh the >> NAT binding. If set to zero, it is ignored. If this field is set >> to all 1s it means that keepalives are not needed, i.e., no NAT >> was detected. >> > How would a home agent know what behaviour to expect from a NAT in a > visited network (e.g., user's home DSL box)? => It doesn't, and that's why the default is the least common denominator. > > Please provide additional discussion on how to set this field, what the > manageability considerations are, etc. => There is no clever solution for this, but what we can say is if the HA doesn't know better, it should use the default value in the spec. Is this ok with you? >> The Type field MUST NOT be >> assigned the values 4 or 6 to make sure that the receiver can tell >> the difference between the Type field and the IP version field in a >> packet that contains an IP header after UDP. > > See RFC 4928 and > http://www.iana.org/assignments/version-numbers/version-numbers.xhtml > > In short, other protocols have done in the past, and restricted > themselves to values 0 and 1, in order to allow for the (admittedly > unlikely) allocation of a new IP version number. > > Please consider the same approach here. => Sure, we only use 1 anyway. > > (And why do we have to distinguish between the TLV and IP -- I thought > you negotiated the use of TLV?) => The BU is sent in IP only, so you need to tell the difference between a BU and a traffic packet. > >> However, UDP MUST NOT be used to encapsulate >> the binding update message when the mobile node is located in an >> IPv6-enabled network. > > MUST NOT is quite strong here. I do not think the reasons for using MUST > apply here. And indeed, there might be future needs to employ UDP over > IPv6 as well, if there was a (bad) firewall that only support UDP and > TCP passthrough. => But there are many scenarios where we can do things to cheat a firewall, is this really a good idea? What if the FW only allows port 80? If the firewall is "bad" in our eyes, may be there is a reason for that in someone else's eyes. One of the reasons for the MUST NOT was to simplify the security scenarios by eliminating the two scenarios of IPv6/UDP/IPvx. But I agree that it might not, strictly speaking, comply to the definition of a MUST. > >> The IANA should allocate and permanently register new TLV-header >> types and Status field values from IETF RFC publication. This is >> for all RFC types including standards track, informational, and >> experimental status that originate from the IETF and have been >> approved by the IESG for publication. >> > > Please use RFC 5226 terminology instead. I think you mean: New > TLV-header types and Status field values are allocated via IETF Review > [RFC5226]. => Ok. > > Missing things: > > - Is it really the case that this document does not need to reference > RFC 4877, even if both talk about the encapsulation formats? > > - What about IKEv2, RFC 4306? => Ok > > - There is no discussion of the interaction between NAT detection & > traversal in IPsec vs. in DSMIP. => Could you elaborate? What needs to be discussed? > > - There is no discussion about procedures for IPv4 addresses "returning > home". You could rule that not supported, but even in that case it > should at least be mentioned. => ok. > > Editorial: > >> In this specification, extensions are defined for the binding update >> and binding acknowledgement. It should be noted that all these >> extensions apply to cases where the mobile node communicates with a >> Mobility Anchor Point (MAP) as defined in [RFC4140 >> ]. The >> requirements on the MAP are identical to those stated for the home >> agent, although it is unlikely that NAT traversal would be needed >> with a MAP as it is expected to be in the same address domain. >> > First, 4140 should be 4140bis. => ok. But I am curious that you mention HMIP > and not any of the other things that might apply equally well, such as PMIP. => Well, this line was written before PMIP, but anyway PMIP has its own accompanying spec for DSMIP, which refers to this spec. Of course a number of things in this spec don't apply to PMIP so it's best to not confuse people. Also, while on the topic, FMIP use with DSMIP would be a bad idea of course unless one writes a separate spec detailing how they could be used in very specific scenarios. > >> NAT box > s/NAT box/NAT/ > >> The security implications of this >> mechanism are discussed in the security considerations section. >> > This appears in Section 3.3.1. This does not seem like a very useful > statement. Everything in this document is hopefully discussed in the > security considerations section! > > Consider removing the statement. > >> When a mobile node acquires both IPv4 and IPv6 care-of addresses at >> the foreign network, it SHOULD prioritize the IPv6 care-of address >> for MIP6 its binding registration. > ... for its MIP6 binding ... ? => ok. > >> If no NAT >> is detected between the mobile node and the home agent, the mobile >> node assumes that it is in a foreign network that supports IPv4 >> public addresses. Otherwise, the mobile node assumes that private >> addresses are used in the foreign network. Note that this assumption >> is only valid for the purposes of the signaling presented in this >> specification. A mobile node SHOULD NOT assume that its IPv4 address >> is globally unique if a NAT device was not detected. > > This was very hard to parse. What is "supports IPv4 public addresses"? > How is that different from "MN's IPv4 is globally unique"? Isn't the > only thing that you need to know here: can the mobile node be reached > from the home agent by sending an IPv4 packet to its address? => yes. > >> 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) > > I was surprised that this section says nothing about keeping the port > numbers in the binding cache entry. Section 5.2 talks about this, but > that is much later. => The scenarios sections are supposed to just list the scenarios, if anything I think we should remove the solutions from those sections. > >> Additionally, this option can include an IPv4 home address in the >> case of Dynamic IPv4 home address configuration (i.e., if the >> unspecified IPv4 address was included in the binding update). > Can? It always will, right? s/can include/includes/ Or are you > considering some error case. Please be more specific here. => ok. > >> To >> avoid confusion in the correspondent node, the mobile node SHOULD >> deregister its binding with each correspondent node by sending a >> deregistration binding update. > This text (and surrounding paragraph) in Section 6.1 feels like it is in > the wrong place. This has nothing to do with IPsec and IKE, its part of > the basic behaviour of the mobile node. => ok > >> .. requires >> an option type. This option is included in the Mobility header >> described in [RFC3775]. > This was hard to read. Maybe: ... requires a new option type allocation > for a mobility option [RFC 3775]. => ok. > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 22 22:52:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817533A6B96; Fri, 22 Aug 2008 22:52: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 635383A6B93 for ; Fri, 22 Aug 2008 22:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 WPxzwWp6A3W3 for ; Fri, 22 Aug 2008 22:52:39 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 665BE3A6B98 for ; Fri, 22 Aug 2008 22:52:38 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 32711198723; Sat, 23 Aug 2008 08:52:46 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5831B19867B; Sat, 23 Aug 2008 08:52:46 +0300 (EEST) Message-ID: <48AFA5FB.4070207@piuha.net> Date: Sat, 23 Aug 2008 08:54:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for your prompt response. Inline for the things that need further discussion: Hesham Soliman wrote: >>> Scenario 3: Home Agent behind a NAT >>> >> I think you are making your life unnecessarily hard. Is there a true >> demand for this? >> > > => Not in my opinion, but we discussed this for a long time on the list and > some people thought it was needed. This paragraph you quote doesn't do > anything though, it simply mentions the scenario and says that the spec > assumes a public IPv4 address. The offending text is below. > OK >>> When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at >>> the foreign network, it SHOULD prioritize the IPv6 care-of address >>> for MIP6 its binding registration. The mobile node MUST NOT register >>> both IPv4 and IPv6 care-of addresses to its home agent. >>> >> This is the priority, but its also likely to have the same problems as >> we have with dual stack hosts getting long timeouts due to trying out >> broken IPv6 connectivity. Look at the Stuart Cheshire's technical >> plenary presentation, for instance. >> > > => Oh, I'm aware of the problems with IPv6 connectivity *today*. However, I > really don't think we should design the spec around what can be seen as a > transient problem. I mean, how many people outside IETF know about those > problems? The decision about CoA selection has profound implications that > will stay in the spec for a long time. > IPv6's connectivity issues are, IMO, clearly tied to the fact that it's not > used today. Once it's used enough for this spec to be deployed, I doubt very > much we will be discussing how slow it is compared to IPv4. So, I'm > I am less concerned about it being slow than about it being broken. Look, the problems of bad IPv6 connectivity from a random visited network are going to be with us for a long time. It is in your best interests to make your protocol resilient against these problems. > reluctant to add further complication to CoA selection based on this issue. > > The recommendation to use IPv6 first follows RFc 2893 (now 4213). > > I would suggest that you have an > >> explicit specification of the recovery mechanism: trying out both in >> parallel, trying one first and then falling back -- I do not have the >> details but you have to have a recovery mechanism. >> > > => You mean ICE? :) seriously, how complicated do you want it to be? > We could do a "try v6 and if BU is rejected/timed out three times then try > v4" is that ok? > I think it is a start. But I would not approach this from the point of view of complexity. You need to make this work. From my perspective the requirement is: Upon arrival to a new visited network, choose between UDP encap/plain v4/plain v6 so that you take into account: - NATs - Firewalls - Possibility of broken v6 connectivity, i.e., routers claim global connectivity but you cannot reach your HA And you should be able to make the choice within seconds or sooner. >> Similarly, it would be very useful if the document contained better >> instruction about when a mobile node sets the F flag. If there is no NAT >> but a firewall, the mobile node may wish to use UDP encapsulation. Would >> it be possible to have the mobile node revert back UDP encapsulation if >> the direct encapsulation does not appear to be working? >> > > => Sure, section 5.1 says: > The mobile node can request to always use > UDP encapsulation by setting the F flag in the binding update. If > the home agent does not agree to the request, it MUST reject the > binding update with the new Status code: > > 144 Cannot force UDP encapsulation > > Alternatively, the home agent can force UDP encapsulation by setting > the F flag in the NAT detection option included in the binding > acknowledgement. > Yes, the document currently allows this behavior. What I am saying is that the document should specify what logic the mobile node uses in making this happen. For instance, if you have tried without UDP and you are not getting anything back. >>> Refresh Time >>> >>> A suggested time (in seconds) for the mobile node to refresh the >>> NAT binding. If set to zero, it is ignored. If this field is set >>> to all 1s it means that keepalives are not needed, i.e., no NAT >>> was detected. >>> >>> >> How would a home agent know what behaviour to expect from a NAT in a >> visited network (e.g., user's home DSL box)? >> > > => It doesn't, and that's why the default is the least common denominator. > Ok, but please explain this. >> Please provide additional discussion on how to set this field, what the >> manageability considerations are, etc. >> > > => There is no clever solution for this, but what we can say is if the HA > doesn't know better, it should use the default value in the spec. Is this ok > with you? > As I recall the text, you had a value for saying "unknown", right? If that is the default then you can say that the HA can include a value when it knows what network the visited network is. E.g., I assume in some 3GPP environments you might have enough information to put in a value. >>> The Type field MUST NOT be >>> assigned the values 4 or 6 to make sure that the receiver can tell >>> the difference between the Type field and the IP version field in a >>> packet that contains an IP header after UDP. >>> >> See RFC 4928 and >> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml >> >> In short, other protocols have done in the past, and restricted >> themselves to values 0 and 1, in order to allow for the (admittedly >> unlikely) allocation of a new IP version number. >> >> Please consider the same approach here. >> > > => Sure, we only use 1 anyway. > Yes, but this will affect the IANA considerations. You will have just one value left, also. >> (And why do we have to distinguish between the TLV and IP -- I thought >> you negotiated the use of TLV?) >> > > => The BU is sent in IP only, so you need to tell the difference between a > BU and a traffic packet. > Ok. Please explain this in the spec, if it is not there already. >>> However, UDP MUST NOT be used to encapsulate >>> the binding update message when the mobile node is located in an >>> IPv6-enabled network. >>> >> MUST NOT is quite strong here. I do not think the reasons for using MUST >> apply here. And indeed, there might be future needs to employ UDP over >> IPv6 as well, if there was a (bad) firewall that only support UDP and >> TCP passthrough. >> > > => But there are many scenarios where we can do things to cheat a firewall, > is this really a good idea? What if the FW only allows port 80? If the > firewall is "bad" in our eyes, may be there is a reason for that in someone > else's eyes. > One of the reasons for the MUST NOT was to simplify the security scenarios > by eliminating the two scenarios of IPv6/UDP/IPvx. But I agree that it might > not, strictly speaking, comply to the definition of a MUST. > Right. We don't need to specify the UDP-over-IPv6 case now. Just change the keyword to a SHOULD. >> - There is no discussion of the interaction between NAT detection & >> traversal in IPsec vs. in DSMIP. >> > > => Could you elaborate? What needs to be discussed? > IPsec and IKE have a NAT detection and traversal mechanism. From having read your spec I do not understand how or whether it works with the mechanisms of this spec. For instance, if you run IKE(v2), are you expecting it to detect NATs on its own or not. > But I am curious that you mention HMIP > >> and not any of the other things that might apply equally well, such as PMIP. >> > > => Well, this line was written before PMIP, but anyway PMIP has its own > accompanying spec for DSMIP, which refers to this spec. Of course a number > of things in this spec don't apply to PMIP so it's best to not confuse > people. Also, while on the topic, FMIP use with DSMIP would be a bad idea of > course unless one writes a separate spec detailing how they could be used in > very specific scenarios. > OK Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Aug 23 00:03:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BC03A69CF; Sat, 23 Aug 2008 00:03: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 84E8E3A69A0 for ; Sat, 23 Aug 2008 00:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 e1n4Alk--hrI for ; Sat, 23 Aug 2008 00:03:23 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id D20BB3A68E4 for ; Sat, 23 Aug 2008 00:03:21 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KWn9W-0000Mh-97; Sat, 23 Aug 2008 17:03:14 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Sat, 23 Aug 2008 17:03:05 +1000 From: Hesham Soliman To: Jari Arkko Message-ID: Thread-Topic: AD review of mext-nemo-v4traversal Thread-Index: AckE7kot2eWVQns6o0+N8G+U7YfYNg== In-Reply-To: <48AFA5FB.4070207@piuha.net> Mime-version: 1.0 Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Jari, I'll address your comments. The big one that we need to think about carefully is the order of selection for the transmission of the BU. I.e. v4 Vs v6 and UDP encap in the absense of NAT. I'll work on text and send it it out for the list to review. Of course I'll do te same for the rest, but this one is the most significant. Hesham On 23/08/08 3:54 PM, "Jari Arkko" wrote: > Thanks for your prompt response. Inline for the things that need further > discussion: > > Hesham Soliman wrote: > >>>> Scenario 3: Home Agent behind a NAT >>>> >>> I think you are making your life unnecessarily hard. Is there a true >>> demand for this? >>> >> >> => Not in my opinion, but we discussed this for a long time on the list and >> some people thought it was needed. This paragraph you quote doesn't do >> anything though, it simply mentions the scenario and says that the spec >> assumes a public IPv4 address. The offending text is below. >> > > OK > >>>> When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at >>>> the foreign network, it SHOULD prioritize the IPv6 care-of address >>>> for MIP6 its binding registration. The mobile node MUST NOT register >>>> both IPv4 and IPv6 care-of addresses to its home agent. >>>> >>> This is the priority, but its also likely to have the same problems as >>> we have with dual stack hosts getting long timeouts due to trying out >>> broken IPv6 connectivity. Look at the Stuart Cheshire's technical >>> plenary presentation, for instance. >>> >> >> => Oh, I'm aware of the problems with IPv6 connectivity *today*. However, I >> really don't think we should design the spec around what can be seen as a >> transient problem. I mean, how many people outside IETF know about those >> problems? The decision about CoA selection has profound implications that >> will stay in the spec for a long time. >> IPv6's connectivity issues are, IMO, clearly tied to the fact that it's not >> used today. Once it's used enough for this spec to be deployed, I doubt very >> much we will be discussing how slow it is compared to IPv4. So, I'm >> > > I am less concerned about it being slow than about it being broken. > Look, the problems of bad IPv6 connectivity from a random visited > network are going to be with us for a long time. It is in your best > interests to make your protocol resilient against these problems. > >> reluctant to add further complication to CoA selection based on this issue. >> >> The recommendation to use IPv6 first follows RFc 2893 (now 4213). >> >> I would suggest that you have an >> >>> explicit specification of the recovery mechanism: trying out both in >>> parallel, trying one first and then falling back -- I do not have the >>> details but you have to have a recovery mechanism. >>> >> >> => You mean ICE? :) seriously, how complicated do you want it to be? >> We could do a "try v6 and if BU is rejected/timed out three times then try >> v4" is that ok? >> > > I think it is a start. But I would not approach this from the point of > view of complexity. You need to make this work. > > From my perspective the requirement is: > > Upon arrival to a new visited network, choose between UDP encap/plain > v4/plain v6 so that you take into account: > - NATs > - Firewalls > - Possibility of broken v6 connectivity, i.e., routers claim global > connectivity but you cannot reach your HA > > And you should be able to make the choice within seconds or sooner. > >>> Similarly, it would be very useful if the document contained better >>> instruction about when a mobile node sets the F flag. If there is no NAT >>> but a firewall, the mobile node may wish to use UDP encapsulation. Would >>> it be possible to have the mobile node revert back UDP encapsulation if >>> the direct encapsulation does not appear to be working? >>> >> >> => Sure, section 5.1 says: >> The mobile node can request to always use >> UDP encapsulation by setting the F flag in the binding update. If >> the home agent does not agree to the request, it MUST reject the >> binding update with the new Status code: >> >> 144 Cannot force UDP encapsulation >> >> Alternatively, the home agent can force UDP encapsulation by setting >> the F flag in the NAT detection option included in the binding >> acknowledgement. >> > > Yes, the document currently allows this behavior. What I am saying is > that the document should specify what logic the mobile node uses in > making this happen. For instance, if you have tried without UDP and you > are not getting anything back. > > >>>> Refresh Time >>>> >>>> A suggested time (in seconds) for the mobile node to refresh the >>>> NAT binding. If set to zero, it is ignored. If this field is set >>>> to all 1s it means that keepalives are not needed, i.e., no NAT >>>> was detected. >>>> >>>> >>> How would a home agent know what behaviour to expect from a NAT in a >>> visited network (e.g., user's home DSL box)? >>> >> >> => It doesn't, and that's why the default is the least common denominator. >> > > Ok, but please explain this. > >>> Please provide additional discussion on how to set this field, what the >>> manageability considerations are, etc. >>> >> >> => There is no clever solution for this, but what we can say is if the HA >> doesn't know better, it should use the default value in the spec. Is this ok >> with you? >> > > As I recall the text, you had a value for saying "unknown", right? If > that is the default then you can say that the HA can include a value > when it knows what network the visited network is. E.g., I assume in > some 3GPP environments you might have enough information to put in a value. > >>>> The Type field MUST NOT be >>>> assigned the values 4 or 6 to make sure that the receiver can tell >>>> the difference between the Type field and the IP version field in a >>>> packet that contains an IP header after UDP. >>>> >>> See RFC 4928 and >>> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml >>> >>> In short, other protocols have done in the past, and restricted >>> themselves to values 0 and 1, in order to allow for the (admittedly >>> unlikely) allocation of a new IP version number. >>> >>> Please consider the same approach here. >>> >> >> => Sure, we only use 1 anyway. >> > > Yes, but this will affect the IANA considerations. You will have just > one value left, also. > >>> (And why do we have to distinguish between the TLV and IP -- I thought >>> you negotiated the use of TLV?) >>> >> >> => The BU is sent in IP only, so you need to tell the difference between a >> BU and a traffic packet. >> > > Ok. Please explain this in the spec, if it is not there already. > >>>> However, UDP MUST NOT be used to encapsulate >>>> the binding update message when the mobile node is located in an >>>> IPv6-enabled network. >>>> >>> MUST NOT is quite strong here. I do not think the reasons for using MUST >>> apply here. And indeed, there might be future needs to employ UDP over >>> IPv6 as well, if there was a (bad) firewall that only support UDP and >>> TCP passthrough. >>> >> >> => But there are many scenarios where we can do things to cheat a firewall, >> is this really a good idea? What if the FW only allows port 80? If the >> firewall is "bad" in our eyes, may be there is a reason for that in someone >> else's eyes. >> One of the reasons for the MUST NOT was to simplify the security scenarios >> by eliminating the two scenarios of IPv6/UDP/IPvx. But I agree that it might >> not, strictly speaking, comply to the definition of a MUST. >> > > Right. We don't need to specify the UDP-over-IPv6 case now. Just change > the keyword to a SHOULD. > >>> - There is no discussion of the interaction between NAT detection & >>> traversal in IPsec vs. in DSMIP. >>> >> >> => Could you elaborate? What needs to be discussed? >> > > IPsec and IKE have a NAT detection and traversal mechanism. From having > read your spec I do not understand how or whether it works with the > mechanisms of this spec. For instance, if you run IKE(v2), are you > expecting it to detect NATs on its own or not. > > >> But I am curious that you mention HMIP >> >>> and not any of the other things that might apply equally well, such as PMIP. >>> >> >> => Well, this line was written before PMIP, but anyway PMIP has its own >> accompanying spec for DSMIP, which refers to this spec. Of course a number >> of things in this spec don't apply to PMIP so it's best to not confuse >> people. Also, while on the topic, FMIP use with DSMIP would be a bad idea of >> course unless one writes a separate spec detailing how they could be used in >> very specific scenarios. >> > > OK > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Aug 23 00:23:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78A73A6B32; Sat, 23 Aug 2008 00:23: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 CD56E3A68D9 for ; Sat, 23 Aug 2008 00:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 NZHI7ZJuM9DB for ; Sat, 23 Aug 2008 00:23:07 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D1FD13A6B26 for ; Sat, 23 Aug 2008 00:23:06 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4FB68198739; Sat, 23 Aug 2008 10:23:16 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D43B819867B; Sat, 23 Aug 2008 10:23:15 +0300 (EEST) Message-ID: <48AFBB31.1040300@piuha.net> Date: Sat, 23 Aug 2008 10:24:33 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks. Just one clarification about the UDP vs. v4 vs. v6 issue. I think your *order* is already correct. I'm not asking you to change the order. What I am asking, however, is that you a specified recovery mechanism in case one does not work. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Aug 23 01:20:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9393A6B85; Sat, 23 Aug 2008 01:20: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 5914C3A6B85 for ; Sat, 23 Aug 2008 01:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UGlKPGhLxzSy for ; Sat, 23 Aug 2008 01:20:37 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 738DA3A6B78 for ; Sat, 23 Aug 2008 01:20:36 -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 1KWoMJ-0003Gg-On; Sat, 23 Aug 2008 18:20:32 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Sat, 23 Aug 2008 18:20:20 +1000 From: Hesham Soliman To: Jari Arkko Message-ID: Thread-Topic: AD review of mext-nemo-v4traversal Thread-Index: AckE+RTa5cDa65aWtEGkX54mf0QFtg== In-Reply-To: <48AFBB31.1040300@piuha.net> Mime-version: 1.0 Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 23/08/08 5:24 PM, "Jari Arkko" wrote: > Thanks. Just one clarification about the UDP vs. v4 vs. v6 issue. I > think your *order* is already correct. I'm not asking you to change the > order. What I am asking, however, is that you a specified recovery > mechanism in case one does not work. => Understood. I just think the tricky things are going to be related to movement detection. There is little distinction in MIPv6 between the "initial" BU and the following ones, and of course the tricky question is how the MN knows that it should not do the trial and error everytime it moves. Meaning, imagine scenario where a MN gets 2001::1, 2002::1 and 63.1.1.1. Lets say the MN decided both v6 addresses and neither worked, then it moved to a new link, if it has to do this whole procedure again then it's a disaster for movement detection. It's really difficult to know how and when to blacklist an address family because you really never know why the BU failed. You can try the various scenarios with the 3 address example I gave but I think you get the idea of why I think this is complex. Hesham > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Aug 24 21:41:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93143A6A0C; Sun, 24 Aug 2008 21:41:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7929A3A6A23 for ; Sun, 24 Aug 2008 21:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.884 X-Spam-Level: X-Spam-Status: No, score=0.884 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOng492Lxd29 for ; Sun, 24 Aug 2008 21:41:17 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F7B73A6A0C for ; Sun, 24 Aug 2008 21:41:17 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A11E619874A; Mon, 25 Aug 2008 07:41:15 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id F087C19873B; Mon, 25 Aug 2008 07:41:07 +0300 (EEST) Message-ID: <48B1A7FD.5030606@piuha.net> Date: Sun, 24 Aug 2008 21:27:09 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 realize it is complex, but is also necessary in order to give a good user experience. I do not think you should blacklist address families. Everything should happen on a per-visited network basis (you may want to specify remembering what the situation was in the last few networks, if you want). Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Aug 24 22:29:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425A13A6A44; Sun, 24 Aug 2008 22:29: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 2FB573A6A39 for ; Sun, 24 Aug 2008 22:29:40 -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 mVbe9PrDVc4f for ; Sun, 24 Aug 2008 22:29:39 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 63F7B3A6A24 for ; Sun, 24 Aug 2008 22:29:38 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.26]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KXUdt-0002qi-KO; Mon, 25 Aug 2008 15:29:30 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 25 Aug 2008 15:29:11 +1000 From: Hesham Soliman To: Jari Arkko Message-ID: Thread-Topic: AD review of mext-nemo-v4traversal Thread-Index: AckGc4DgkX8V7xme1EqQ64kykYf6GQ== In-Reply-To: <48B1A7FD.5030606@piuha.net> Mime-version: 1.0 Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 realize it is complex, but is also necessary in order to give a > good user experience. => Me too. > > I do not think you should blacklist address families. Everything should > happen on a per-visited network basis (you may want to specify > remembering what the situation was in the last few networks, if you want). => I think you MUST remember what happened otherwise you can end up with a few seconds for movement detection. But of course, the other side of that is that what happened in the last visited network does not necessarily have any bearing on this new network.... It just gets extremely complex if you want a proper solution. I don't even know if it's doable properly. The easy way (and of course not really correct) is to try v6, then v4 and stick to it, while trying v6 again in parallel periodically (say once an hour). I'll write something up as a starting point. Hesham > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 25 03:24:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26283A6BB6; Mon, 25 Aug 2008 03:24: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 36DCE3A6940 for ; Mon, 25 Aug 2008 03:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 T0pguA+TfXNn for ; Mon, 25 Aug 2008 03:12:40 -0700 (PDT) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by core3.amsl.com (Postfix) with ESMTP id E50AA3A68FD for ; Mon, 25 Aug 2008 03:12:39 -0700 (PDT) X-UniDo-MailScanner-Watermark: 1220263898.2365@OqVSuanfXchaWr2hfE4+oQ Received: from unidoknmobile5 ([129.217.186.117]) by unimail.uni-dortmund.de (8.14.3/8.14.3) with ESMTP id m7PABV3b002981 for ; Mon, 25 Aug 2008 12:11:36 +0200 (CEST) From: "Zarrar Yousaf" To: References: Date: Mon, 25 Aug 2008 12:11:31 +0200 Message-ID: <000901c9069a$f5a63310$75bad981@kn.etechnik.unidortmund.de> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckEie2YlvGiy8lQSV+zuGbSE76EFwCECe0g In-Reply-To: X-MailScanner-Information: UniDo-UniMail X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (nicht zwischen gespeichert, Wertung=-2.311, benoetigt 5, AWL, BAYES_00, RDNS_NONE) X-MailScanner-From: faqir.yousaf@uni-dortmund.de X-Mailman-Approved-At: Mon, 25 Aug 2008 03:24:38 -0700 Subject: [MEXT] NERON: A New RO Solution for Nested NEMO X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Members, I have submitted a new draft titled "Nest Route Optimization for NEMO (NERON)" and can be accessed at http://tools.ietf.org/html/draft-yousaf-ietf-nemo-neron-01 It is a light weight RO solution that incurs zero tunneling overhead and its performance is independent of the nest depth. It warrants minimalistic changes to the MR and CN only. The simulation results have shown exceptional performance results both in terms of reduction in RTT and Packet overhead, especially for VoIP packets. I would appreciate critique and comments on the said draft. Looking forward. Regards Faqir Zarrar Yousaf Communication Networks Institute, TU Dortmund. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 25 15:29:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C19B3A6858; Mon, 25 Aug 2008 15:29: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 939A23A6858 for ; Mon, 25 Aug 2008 15:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxnsPRv6bYV1 for ; Mon, 25 Aug 2008 15:29:36 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B345F3A6806 for ; Mon, 25 Aug 2008 15:29:36 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 207ED198661; Tue, 26 Aug 2008 01:29:37 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A51FF1985F0; Tue, 26 Aug 2008 01:29:29 +0300 (EEST) Message-ID: <48B3329A.7090003@piuha.net> Date: Mon, 25 Aug 2008 15:30:50 -0700 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, >> I do not think you should blacklist address families. Everything should >> happen on a per-visited network basis (you may want to specify >> remembering what the situation was in the last few networks, if you want). >> > > => I think you MUST remember what happened otherwise you can end up with a > few seconds for movement detection. Yes. > But of course, the other side of that is > that what happened in the last visited network does not necessarily have any > bearing on this new network.... > Right. > It just gets extremely complex if you want a proper solution. I don't even > know if it's doable properly. The easy way (and of course not really > correct) is to try v6, then v4 and stick to it, while trying v6 again in > parallel periodically (say once an hour). I'll write something up as a > starting point. I do not see evidence of this being an unsolvable problem. You apply either parallel or sequential trying of the different alternatives on each previously unknown network, and then keep state about the networks for some specified amount of time. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 25 17:27:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE67E3A6A6F; Mon, 25 Aug 2008 17:27: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 078EC3A6A6F for ; Mon, 25 Aug 2008 17:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zByJ80loPzzd for ; Mon, 25 Aug 2008 17:27:44 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 14A1A3A696F for ; Mon, 25 Aug 2008 17:27:42 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KXmPJ-0008MO-7T; Tue, 26 Aug 2008 10:27:37 +1000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 26 Aug 2008 10:27:29 +1000 From: Hesham Soliman To: Jari Arkko Message-ID: Thread-Topic: AD review of mext-nemo-v4traversal Thread-Index: AckHEoWop1CQQCdUTkSwJlC7q6NLYQ== In-Reply-To: <48B3329A.7090003@piuha.net> Mime-version: 1.0 Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > >> It just gets extremely complex if you want a proper solution. I don't even >> know if it's doable properly. The easy way (and of course not really >> correct) is to try v6, then v4 and stick to it, while trying v6 again in >> parallel periodically (say once an hour). I'll write something up as a >> starting point. > > I do not see evidence of this being an unsolvable problem. You apply > either parallel or sequential trying of the different alternatives on > each previously unknown network, and then keep state about the networks > for some specified amount of time. => My point is that keeping historical state is actually not really correct. It's a guess (that has no strong basis) that since IPv6 didn't work in the last network, it probably won't work again! It's meaningless. But we need to do that in order to avoid the potential movement detection delay. So the ultimate result is sub-optimal whichever way you look at it (i.e. Selecting a v4 address when a v6 one should've been selected, especially if that v4 address is private, or breaking movement detection). What I was trying to say is that I don't see a solution that provides the optimal choice with a high degreee of certainty (of course with the exception of the initial BU). Hesham > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Aug 25 18:45:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0F63A6A98; Mon, 25 Aug 2008 18:45: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 519C93A6A9B for ; Mon, 25 Aug 2008 18:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, J_CHICKENPOX_35=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 8tk6MLEztVH0 for ; Mon, 25 Aug 2008 18:45:33 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4C3FF3A6A9F for ; Mon, 25 Aug 2008 18:45:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 21:45:32 -0400 Message-ID: In-Reply-To: <48AECBCB.6010605@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of mext-nemo-v4traversal Thread-Index: AckEZKIvghxrpubXSG2kCnx9jTIKjQCtss2w References: <48AECBCB.6010605@piuha.net> From: "Vijay Devarapalli" To: "Jari Arkko" , , Cc: Pasi Eronen Subject: Re: [MEXT] AD review of mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Hesham, >From what I remember, there were a few people who insisted on supporting the scenario where the home agent is behind a NAT. There were extensive discussions both in the mip6trans design team and on the MIP6 mailing list. See http://people.nokia.net/vijayd/mip6trans/mip6trans_scenarios.txt for a description of the scenarios that the design team concluded on. The solutions were explicitly added to avoid having to standardize more complicated solutions. There, I would like to keep the existing text related to this scenario. > > 2) > > configure one public address and make the home agents share the > > public address. > > How would this work if the NAT happens to forward one BU to one home > agent and the next BU the a second one? > > Please explain better or remove. Well, the NAT should be capable of looking into the binding update message, and then based on either the IPv4 care-of address or something in the binding update itself, decides which of the internal home agents gets the message. This would be similar to a load balancer function. The information in the binding update should be sufficient for the NAT to consistently forward the binding updates from a particular mobile node to the same home agent. I remember we had discussions on this. The text we have currently is supposed to reflect this, without going into too much detail. > Another possible solution is to designate one home agent > > on the home link for IPv4 traversal. The NAT device should > associate > > that home agent with the public IPv4 address configured on it for v4 > > traversal. In all cases above, both the 'AAAA' and 'A' records > > returned for a particular name MUST correspond to the same physical > > home agent > The first and third sentences seem to be in conflict. If one > HA is used > for IPv4, then presumably the other ones are used for IPv6. No. The above sentence says one of the home agents can be designated for v4 traversal. That means it supports DS-MIPv6, which again means that the home agent can support both IPv4 and IPv6 home addresses and care-of addresses. > If so, when > a mobile node moves from IPv6 care-of address to an IPv4 care-of > address, it has to switch the home agent. The mobile node shouldn't have to. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 03:07:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8E33A6A46; Wed, 27 Aug 2008 03:07: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 CA8353A6A46 for ; Wed, 27 Aug 2008 03:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_40=-0.185, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78O82L6xJNdv for ; Wed, 27 Aug 2008 03:07:52 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by core3.amsl.com (Postfix) with ESMTP id 579763A6977 for ; Wed, 27 Aug 2008 03:07:52 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so2124087mue.9 for ; Wed, 27 Aug 2008 03:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:content-disposition :subject:date:cc:mime-version:content-type:content-transfer-encoding :message-id:from; bh=jQC6vlKqoqQZbWqNnzloBb/luc3rehkXmmykuldB2F4=; b=Pjs0+Z/g8RrEeL3unTvxmCyZ1qZhVE2WHXqakvqebA5FDLJXFfpovNPTjkB9b+eER7 PVuwoW8HUJuQH6IAAF5Nk/pOCr0aKasY7wXkU4o7Cu4UUgJIhUMpIogzdYtUCdv/wk47 EbFQ9GViidboIFMsKHrOpNDScPRnQafx4hiUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:content-disposition:subject:date:cc:mime-version:content-type :content-transfer-encoding:message-id:from; b=UvRh/PgeDybJjyxQW8xS8eA9aTViBc8ZDw81I9PZ9WAGqp3mRWd4sbNKffqirdegTx vlDK+s5VnH+9ZMnIsVKUsjfFBgnzZ0sKe5hBPsbJYxI+p0WVYdFrQUMviqHr5655SApt Y/30RqfG2laMU8w9NjT7Mc2fYUZSODstMyQu4= Received: by 10.103.224.17 with SMTP id b17mr4548483mur.16.1219831673468; Wed, 27 Aug 2008 03:07:53 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u26sm10290018mug.5.2008.08.27.03.07.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Aug 2008 03:07:52 -0700 (PDT) To: mext@ietf.org Content-Disposition: inline Date: Wed, 27 Aug 2008 12:07:56 +0200 MIME-Version: 1.0 Message-Id: <200808271207.57412.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] ETSI TC ITS Liaison X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, The European Telecommunications Standards Institute (ETSI) has created a new Technical Committee TC ITS whose task is to develop standards, specifications and other deliverables to support development and implementation of ITS Service provision across the network, for transport networks, vehicles and transport users. We have received a Liaison Letter from ETSI TC ITS: They have designated Andreas Festag (Chairman of the TC ITS WG3 - Transport and Networks) as a Liaison to the IETF MEXT WG. It is good that we have someone that can speak on the behalf of ETSI TC ITS. >From our side, given the current workload involved with work on NEMO route optimization for the automotive usecases, we do not foresee a need to have a designated Liaison since the WG can communicate with ETSI TC ITS in a simple way, i.e. reach WG consensus on what is our input to them, and get that input approved by our Area Director, Jari. If the workload involved with with work on NEMO route optimization for the automotive usecases increases as to justify designating a Liaison to ETSI TC ITS, we can of course reconsider that decision. Please feel free to express your thoughts on the above, if any, on the MEXT mailing list. --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 03:10:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50EF28C136; Wed, 27 Aug 2008 03:10: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 0607428C136 for ; Wed, 27 Aug 2008 03:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=1.502, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJwuPNgEt267 for ; Wed, 27 Aug 2008 03:10:31 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by core3.amsl.com (Postfix) with ESMTP id ACBA03A6C57 for ; Wed, 27 Aug 2008 03:10:30 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so2124636mue.9 for ; Wed, 27 Aug 2008 03:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:content-disposition :subject:cc:date:mime-version:content-type:content-transfer-encoding :message-id:from; bh=J2ih6kAdLBdiwiAJVDgbHO6W4YFKrEv3MvYePfosM3c=; b=O1275iyeyZmK8kzK7d4nK+D3U1UGIkeBAOF3WBqbhIrQK6DfAuTdiZG/tEpRWh7uyL YRpIzoLxYC+Wo6LARZ2Wu3ocGQiBdyUD9ACmkNkjcWJ6XgHlUd+uQeFy5ZBJNoh3YzbE /OMOkCyEhAJ/F+zgixDIzC3eYC47lDCTaPQ40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:content-disposition:subject:cc:date:mime-version:content-type :content-transfer-encoding:message-id:from; b=DW4RZwV0YKXUpuXgoWPEg+EWUhsLVQgmgRW4i7U1Cv/wunb6tE7XH+B59Wf99hP7sI gTjG+i4ZjOSf0Hrky5duQLgMvjO3iRicOdJjmm62e8LF/QUl+NUqaa/NPVb9s24t7ibg yX2yRUCLo27ebwoLW91gc40Tkm9uo/MfFuWyU= Received: by 10.103.49.12 with SMTP id b12mr4530429muk.72.1219831809622; Wed, 27 Aug 2008 03:10:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id w5sm39664131mue.10.2008.08.27.03.10.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Aug 2008 03:10:08 -0700 (PDT) To: mext@ietf.org Content-Disposition: inline Date: Wed, 27 Aug 2008 12:10:13 +0200 MIME-Version: 1.0 Message-Id: <200808271210.13692.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Andreas Festag Subject: [MEXT] ETSI TC ITS Liaison X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, [Resent since I forgot to CC Andreas Festag] The European Telecommunications Standards Institute (ETSI) has created a new Technical Committee TC ITS whose task is to develop standards, specifications and other deliverables to support development and implementation of ITS Service provision across the network, for transport networks, vehicles and transport users. We have received a Liaison Letter from ETSI TC ITS: They have designated Andreas Festag (Chairman of the TC ITS WG3 - Transport and Networks) as a Liaison to the IETF MEXT WG. It is good that we have someone that can speak on the behalf of ETSI TC ITS. >From our side, given the current workload involved with work on NEMO route optimization for the automotive usecases, we do not foresee a need to have a designated Liaison since the WG can communicate with ETSI TC ITS in a simple way, i.e. reach WG consensus on what is our input to them, and get that input approved by our Area Director, Jari. If the workload involved with with work on NEMO route optimization for the automotive usecases increases as to justify designating a Liaison to ETSI TC ITS, we can of course reconsider that decision. Please feel free to express your thoughts on the above, if any, on the MEXT mailing list. --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 04:46:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0F03A687E; Wed, 27 Aug 2008 04:46: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 B1CAA3A687E for ; Wed, 27 Aug 2008 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 HqevtjjkSnX5 for ; Wed, 27 Aug 2008 04:46:29 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id B06BC3A69E5 for ; Wed, 27 Aug 2008 04:46:28 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 108AEA8052; Wed, 27 Aug 2008 06:43:11 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m7RBkHxo005614; Wed, 27 Aug 2008 06:46:17 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 06:46:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 06:46:15 -0500 Message-ID: In-Reply-To: <200808271210.13692.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] ETSI TC ITS Liaison Thread-Index: AckILTjTME5iw8p2Tke7Q/vKNLK8sgADNIcg References: <200808271210.13692.julien.laganier.IETF@googlemail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Julien Laganier" , X-OriginalArrivalTime: 27 Aug 2008 11:46:17.0441 (UTC) FILETIME=[841D5510:01C9083A] Cc: Andreas Festag Subject: Re: [MEXT] ETSI TC ITS Liaison X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of Julien Laganier >Sent: Wednesday, August 27, 2008 6:10 AM >Subject: [MEXT] ETSI TC ITS Liaison > >Folks, > >[Resent since I forgot to CC Andreas Festag] > >The European Telecommunications Standards Institute (ETSI) has >created a >new Technical Committee TC ITS whose task is to develop standards, >specifications and other deliverables to support development and >implementation of ITS Service provision across the network, for >transport networks, vehicles and transport users. > >We have received a Liaison Letter from ETSI TC ITS: > > > >They have designated Andreas Festag (Chairman of the TC ITS WG3 - >Transport and Networks) as a Liaison to the IETF MEXT WG. It is good >that we have someone that can speak on the behalf of ETSI TC ITS. > >From our side, given the current workload involved with work on NEMO >route optimization for the automotive usecases, we do not foresee a >need to have a designated Liaison since the WG can communicate with >ETSI TC ITS in a simple way, i.e. reach WG consensus on what is our >input to them, and get that input approved by our Area Director, Jari. > >If the workload involved with with work on NEMO route optimization for >the automotive usecases increases as to justify designating a Liaison >to ETSI TC ITS, we can of course reconsider that decision. > >Please feel free to express your thoughts on the above, if any, on the >MEXT mailing list. It seems like a good decision to me. Does the ETSI TC ITS have a schedule it's trying to meet? It would make sense if any MEXT milestones that they depend on are in sync with that. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 05:36:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E243A6A18; Wed, 27 Aug 2008 05:36:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2394D3A6A18 for ; Wed, 27 Aug 2008 05:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[AWL=-1.080, 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 Y1bQKJV2SlDB for ; Wed, 27 Aug 2008 05:36:19 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by core3.amsl.com (Postfix) with ESMTP id 2EAAE3A6843 for ; Wed, 27 Aug 2008 05:36:18 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so921397uge.15 for ; Wed, 27 Aug 2008 05:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=netFzHsJyl6olaTJ2PJ1+l5BU2xxctsOCaQL5YRDH20=; b=cvYJjCjjwYZGYUU2bVPcBN21oEx1Pq/mdHQfjoEflKFSA3cSKbfv4/5ZvBe0dnVLnv n4zz7axEr7Wl70R/Cl5YQdMuHrVmB/nG5Lmwnrwq2a7aWL9IL93/muzFQKnOaOA96DEr 7ZuDCM1HRvwAMXVaxLqpYOA1CxQl9Xyf42Xfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=YMBL2NbJBZKmwkgVJNLFMarL2rrRjptwTsRzX1LqVU67Xl4cVXH2pG69Ot3UpShJE2 bDbPKNOEw2mKRcNE14fcZmtn6KWkegxuc1g0WQ588tXxXRW9qPh2TQ9mbItp17IJ4M2W 58YwMfRQJGhRmdg+d9/aBxJP93/riGolzBQSQ= Received: by 10.103.131.18 with SMTP id i18mr4618951mun.116.1219840579780; Wed, 27 Aug 2008 05:36:19 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id w5sm40423973mue.10.2008.08.27.05.36.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Aug 2008 05:36:19 -0700 (PDT) To: mext@ietf.org Date: Wed, 27 Aug 2008 14:36:23 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808271436.23924.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] on-flight Internet service back on some North American flights X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Thought some of you might be interested, given that we are chartered to work on NEMO route optimization for aviation: American Airlines is rolling out high speed on-flight Internet service on its 767-200 transcontinental flights b/w east and west coasts. Cheers, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 08:49:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9857928C1D2; Wed, 27 Aug 2008 08:49: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 4F11828C146 for ; Wed, 27 Aug 2008 08:49:49 -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 hD6Y5qnid0iX for ; Wed, 27 Aug 2008 08:49:48 -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 0F2CB28C23D for ; Wed, 27 Aug 2008 08:49:48 -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 m7RFnWkf023295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Aug 2008 08:49:32 -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 m7RFnWdl015842; Wed, 27 Aug 2008 10:49:32 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7RFnVrI015823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 27 Aug 2008 10:49:31 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 27 Aug 2008 08:49:31 -0700 From: "Davis, Terry L" To: Julien Laganier , "mext@ietf.org" Date: Wed, 27 Aug 2008 08:49:29 -0700 Thread-Topic: [MEXT] on-flight Internet service back on some North Americanflights Thread-Index: AckIQYXIknG/Ig5YT4WqKOcvJZIUogAFj85g Message-ID: <2557049CDBC35B4EBD79CFACFEC045840736EDB8@XCH-NW-CCR1V.nw.nos.boeing.com> References: <200808271436.23924.julien.laganier.IETF@googlemail.com> In-Reply-To: <200808271436.23924.julien.laganier.IETF@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1285-5.500.1027-16120.004 x-tm-as-result: No--54.323900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 Subject: Re: [MEXT] on-flight Internet service back on some North Americanflights X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Although important for ground based link communications Aircell, it becomes most critical (and noticeable) for performance when using geostationary Satcom communication links where changing links means changing satellites and ground connection points (ground stations) which are located on different continents within seconds. Take care Terry > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Wednesday, August 27, 2008 5:36 AM > To: mext@ietf.org > Subject: [MEXT] on-flight Internet service back on some North > Americanflights > > Folks, > > Thought some of you might be interested, given that we are chartered to > work on NEMO route optimization for aviation: American Airlines is > rolling out high speed on-flight Internet service on its 767-200 > transcontinental flights b/w east and west coasts. > > forums/general_aviation/read.main/4119652/> > > Cheers, > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Aug 27 09:15:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302CB28C2C3; Wed, 27 Aug 2008 09:15:02 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C61728C2BC; Wed, 27 Aug 2008 09:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080827161501.2C61728C2BC@core3.amsl.com> Date: Wed, 27 Aug 2008 09:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-09.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-09.txt Pages : 44 Date : 2008-08-27 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-27090124.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 Thu Aug 28 14:30:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2202228C153; Thu, 28 Aug 2008 14:30:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AC66F28C153; Thu, 28 Aug 2008 14:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080828213002.AC66F28C153@core3.amsl.com> Date: Thu, 28 Aug 2008 14:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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: , 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 : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-01.txt Pages : 34 Date : 2008-08-28 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-ietf-mext-binding-revocation-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-28142618.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 Thu Aug 28 14:33:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6B13A68A3; Thu, 28 Aug 2008 14: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 054C13A68A3 for ; Thu, 28 Aug 2008 14:33:42 -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 afjMTEndNiEk for ; Thu, 28 Aug 2008 14:33:40 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 6DD4F3A683B for ; Thu, 28 Aug 2008 14:33:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7SLX6J24234; Thu, 28 Aug 2008 21:33:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 16:32:32 -0500 Message-ID: In-Reply-To: <20080828213002.AC66F28C153@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-01.txt Thread-Index: AckJVUOW+0QpyBYdRrmjozUyaS0IdwAABIwg References: <20080828213002.AC66F28C153@core3.amsl.com> From: "Ahmad Muhanna" To: Cc: Julien Laganier , Basavaraj Patil Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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 Hello Folks, A new revision of the Binding Revocation for IPv6 Mobility draft have been published addressing the following: 1. Using one MH type for Binding Revocation Message. 2. Using a Binding Revocation Field to further identify the Binding Revocation Message type, BRI or BRA, this way we only have one MH type to worry about. 3. In case of DS IP addresses, allow the LMA to revoke the IPv4 binding to the current pCoA while the binding of the IPv6 Address/HNP is still active by defining a new Revocation Trigger. 4. Adding a section to address how BRI and BRA messages is exchanged in case of MAG being behind a NAT. Basically referencing PMIPv6 Support IPv4 Transport draft. Thanks to Vijay for sharing similar text related to path management draft. Please take a look and let me know if you have any comments or questions. Thanks in advance for your review. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, August 28, 2008 4:30 PM > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-01.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 : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-ietf-mext-binding-revocation-01.txt > Pages : 34 > Date : 2008-08-28 > > 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-ietf-mext-binding-revocation-0 1.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Aug 28 15:24:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AED3A6A24; Thu, 28 Aug 2008 15:24: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 1EDE83A6A24 for ; Thu, 28 Aug 2008 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=2.974, 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 NlgHR1Of9Gro for ; Thu, 28 Aug 2008 15:24:38 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 2EC2B3A694A for ; Thu, 28 Aug 2008 15:24:38 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7SMOSiB000773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Aug 2008 17:24:30 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7SMORVg027972; Thu, 28 Aug 2008 17:24:27 -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 m7SMOFXn027694; Thu, 28 Aug 2008 17:24:27 -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.3959); Thu, 28 Aug 2008 15:24:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 15:24:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E93728@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045840736EDB8@XCH-NW-CCR1V.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] on-flight Internet service back on some NorthAmericanflights Thread-Index: AckIQYXIknG/Ig5YT4WqKOcvJZIUogAFj85gAED20zA= References: <200808271436.23924.julien.laganier.IETF@googlemail.com> <2557049CDBC35B4EBD79CFACFEC045840736EDB8@XCH-NW-CCR1V.nw.nos.boeing.com> From: "Templin, Fred L" To: "Davis, Terry L" , "Julien Laganier" , X-OriginalArrivalTime: 28 Aug 2008 22:24:17.0103 (UTC) FILETIME=[CEFBF5F0:01C9095C] Subject: Re: [MEXT] on-flight Internet service back on some NorthAmericanflights X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: Davis, Terry L >Sent: Wednesday, August 27, 2008 8:49 AM >To: Julien Laganier; mext@ietf.org >Subject: Re: [MEXT] on-flight Internet service back on some >NorthAmericanflights > >Julien > >Although important for ground based link communications >Aircell, it becomes most critical (and noticeable) for >performance when using geostationary Satcom communication >links where changing links means changing satellites and >ground connection points (ground stations) which are located >on different continents within seconds. I think Terry is right. One other observation on the AirCell announcement is that the service seems to be going over to passenger-domain use but the channel access nature of the link (CDMA) might make for a nice fit for the ATS/AOC needs too. Does anyone know whether ATS/AOC use is being considered for AirCell (IMHO I think it should be)? Thanks - Fred fred.l.templin@boeing.com > >Take care >Terry > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >On Behalf Of >> Julien Laganier >> Sent: Wednesday, August 27, 2008 5:36 AM >> To: mext@ietf.org >> Subject: [MEXT] on-flight Internet service back on some North >> Americanflights >> >> Folks, >> >> Thought some of you might be interested, given that we are >chartered to >> work on NEMO route optimization for aviation: American Airlines is >> rolling out high speed on-flight Internet service on its 767-200 >> transcontinental flights b/w east and west coasts. >> >> > forums/general_aviation/read.main/4119652/> >> >> Cheers, >> >> --julien >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Aug 29 05:48:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3523A695E; Fri, 29 Aug 2008 05:48: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 E67903A6967 for ; Fri, 29 Aug 2008 05:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4TJ2reMZyZr for ; Fri, 29 Aug 2008 05:48:48 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 617B53A69BE for ; Fri, 29 Aug 2008 05:48:47 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so552511fkq.5 for ; Fri, 29 Aug 2008 05:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=x9OUu0OxW6vZmf7RvkXj09IgJDx7HwvQ13vc8iANj3s=; b=KTxah3BlDgMmB9HvM7UOoOAlLDC3+mIMiosUbpPNkH/6KkON1Tj4sc3i2h12/d1r9K LjgANytniEUEZQ4gnla9iBhjPX9Ulg9l+WM/RlHEGIzOtCmVLn+w1ds0OASdbZmkEiV3 q2mIv7jZlHtydNCT07HssdnokmkNGw03RMX28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=Q+1ordmhyWMrvo4Cial1PlKqrK4/ajq+evmLuuT54Q2IPtJF6UItfxWhPl1cLPLgG+ HL8fKKRZMXap6Sht7TpwPsJX899GJwd5UZiWGhw1fgkAqHZenyytrTlcmFiLuQ58GknX 8Bv3hoW/zRNNFAJRkWdFhtV3KxhbKZ76rM8XM= Received: by 10.180.254.18 with SMTP id b18mr3234264bki.43.1220014121709; Fri, 29 Aug 2008 05:48:41 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 13sm2170797fks.6.2008.08.29.05.48.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Aug 2008 05:48:41 -0700 (PDT) To: mext@ietf.org, btns@ietf.org Date: Fri, 29 Aug 2008 14:48:39 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808291448.39689.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] New co-chair email address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Due to the impossibility to resolve issues (such as nearly random bouncing of emails) with my email provider I'm switching my IETF "business" to a new email account. Please use to contact me from now on. (I'll of course still be checking mail sent to my old address julien.IETF@laposte.net) --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From asamblea30082008@gmail.com Sat Aug 30 19:29:19 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 A92463A6B53; Sat, 30 Aug 2008 19:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.545 X-Spam-Level: ** X-Spam-Status: No, score=2.545 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-H60D2rL7aV; Sat, 30 Aug 2008 19:29:19 -0700 (PDT) Received: from avas-mr17.fibertel.com.ar (avas-mr17.fibertel.com.ar [24.232.0.249]) by core3.amsl.com (Postfix) with ESMTP id A3FE63A6B3D; Sat, 30 Aug 2008 19:29:18 -0700 (PDT) Received: from 133-9-245-190.fibertel.com.ar ([190.245.9.133]:1602 "EHLO f3t" smtp-auth: "asamblea30082008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr17.fibertel.com.ar with ESMTPA id S1469104AbYHaC3M convert rfc822-to-8bit; Sat, 30 Aug 2008 23:29:12 -0300 Message-ID: <3821-22008863021291562@f3t> To: "core2duo" From: "asamblea30082008@gmail.com" Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samasung LCD 19" Date: Sat, 30 Aug 2008 23:29:01 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 6fc761a01cd449ef87b08e1d97c182b4 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea30082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIOR. CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: asamblea30082008@gmail.com -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2.53 3MB cache 775 BOX 3 años de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco rígido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y utilidades -Monitor: LCD 19" Samsung 943NWX 3 años de garantia -PRECIO $2499 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mucho mas From Huanjun-deddorok@MISSIONFCU.ORG Sun Aug 31 23:31:06 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 769993A68E7 for ; Sun, 31 Aug 2008 23:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.57 X-Spam-Level: X-Spam-Status: No, score=-65.57 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, RAZOR2_CF_RANGE_51_100=0.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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_JP_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 Wjqeu3qVQ3Ox for ; Sun, 31 Aug 2008 23:31:05 -0700 (PDT) Received: from pool-68-238-143-34.sea.dsl-w.verizon.net (pool-68-238-143-34.sea.dsl-w.verizon.net [68.238.143.34]) by core3.amsl.com (Postfix) with ESMTP id 5B80F3A692F for ; Sun, 31 Aug 2008 23:31:05 -0700 (PDT) Message-ID: <3F08B9AE.A58AEEF2@MISSIONFCU.ORG> Date: Sun, 31 Aug 2008 23:31:11 -0700 From: Salsbury User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: nemo-archive@ietf.org Subject: Re: Miley Cyrus home video Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Give her non-stop action every night with your new weapon http://www.saidwhy.com/