From tsirtsis@googlemail.com Tue Nov 3 05:15:46 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F9C3A6A0A for ; Tue, 3 Nov 2009 05:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2ebCsJo-5xI for ; Tue, 3 Nov 2009 05:15:45 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id 08F563A68B4 for ; Tue, 3 Nov 2009 05:15:44 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so703385gvc.15 for ; Tue, 03 Nov 2009 05:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eM7IDKExIwTRhVS9n9k8Ag+o/T+DV61nSIMLTwOybEo=; b=dV3rY+RT2L6ESu9FG1Nfq0iWBlxe7nE9u+29o2+evNrdg8jMz2wIa1gBDwnJS/XXXR aLBMG8EOxeVig1LUNqdR9BJpo2GDyxr2IEjp7ptj6YEmyPIhedES20XDC8YM1uW/taJe J8mYQyavSVfhAXIXJxCeGPVyCxPriK2PNVBko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mOJOx1LA/gn7FRK+IYUULKieeRPOkWy4AWEkN1OGhoBV/Z+W1Y3mrTw7+43dLoZqsc NMtO4hXUIrU0whBy1A+TrX6ohUWCWZ+Hc/lrCr8cCO4pYVp2gLhj9mnUgqylmD4aZ2Ng yQLdInbLl3vPYyYFG6xCSe8GKlyNzlIYRk9WQ= MIME-Version: 1.0 Received: by 10.239.143.219 with SMTP id l27mr785684hba.162.1257254162018; Tue, 03 Nov 2009 05:16:02 -0800 (PST) In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05C58104@de01exm70.ds.mot.com> References: <274D46DDEB9F2244B2F1EA66B3FF54BC05C58104@de01exm70.ds.mot.com> Date: Tue, 3 Nov 2009 13:16:01 +0000 Message-ID: From: George Tsirtsis To: McCann Peter-A001034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Agenda posted X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:15:46 -0000 Pete et.al., I see that you still plan to do something with draft-ietf-mip4-nemov4-dynamic so I am going to republish, pretty much as is, the draft early next week, since I think it has expires. I put up an early version at http://www.tsirtsis.com/draft-ietf-mip4-nemov4-dynamic-pre_03.txt George On Thu, Oct 29, 2009 at 5:12 PM, McCann Peter-A001034 wrote: > Proposed agenda is now available here: > > http://www.ietf.org/proceedings/09nov/agenda/mip4.txt > > As far as I know all requests were acommodated. =C2=A0Please send e-mail > if you would like to add items to the agenda. > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > =C2=A0 =C2=A0Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =C2=A0 =C2=A0 Charter page: http://www.ietf.org/html.charters/mip4-charte= r.html > Supplemental site: http://www.mip4.org/ > From root@core3.amsl.com Sun Nov 8 22:00:01 2009 Return-Path: X-Original-To: mip4@ietf.org Delivered-To: mip4@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9D12E3A69EA; Sun, 8 Nov 2009 22:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109060001.9D12E3A69EA@core3.amsl.com> Date: Sun, 8 Nov 2009 22:00:01 -0800 (PST) Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-nemov4-dynamic-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Dynamic Prefix Allocation for NEMOv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-nemov4-dynamic-03.txt Pages : 10 Date : 2009-11-08 The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-nemov4-dynamic-03.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-mip4-nemov4-dynamic-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08215405.I-D@ietf.org> --NextPart-- From peng.yang.chn@gmail.com Mon Nov 9 20:42:17 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B483A69CF for ; Mon, 9 Nov 2009 20:42:17 -0800 (PST) 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 uLOc-cWjWsjx for ; Mon, 9 Nov 2009 20:42:16 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id E263F3A680F for ; Mon, 9 Nov 2009 20:42:16 -0800 (PST) Received: by pxi42 with SMTP id 42so2595328pxi.5 for ; Mon, 09 Nov 2009 20:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=UqmfISbA3/I8fC3RNJMukZih5GqtcD5kDrb6vBZWy2w=; b=bfHUiORw9a7RfJvrGajQgiNwppBGH+17REFs16ZTWX27KkE+7/FIE0Dnkna/E/VuNR loP18Jsmh2VnURKII4vkcyRh/nYr+cAfWO2SHJiXxIHE0YtLHGX0Z3bOWixdb12Ybv/E dwWd32ZvSbHQW0xI23KlVdWzZTIvFjgbGn6G0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DIFzzxKV7EXIbwigLtXmhNFx1CeVU3D8LhIidqThB5nprv3C34MhpdpKJ6mVoO4FCe hQGodZbycRLZHpEIJryj6x4JDoB3icsHpscXX+dFu58YWqP4ReRRKZpbc5T/zL1YLTA7 d3tzCazfR8Za4es/Pw9m80f/vN+mYUs1ItEGc= MIME-Version: 1.0 Received: by 10.140.128.12 with SMTP id a12mr469787rvd.283.1257828160977; Mon, 09 Nov 2009 20:42:40 -0800 (PST) Date: Tue, 10 Nov 2009 12:42:40 +0800 Message-ID: <4c5c7a6d0911092042h12e6a98epb9572ccc865d1416@mail.gmail.com> From: Peny Yang To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] Usage of Generic Notification in 3GPP2 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:42:17 -0000 Dear all: Please check the reference below as a use case of generic notification solution. http://www.3gpp2.org/Public_html/Specs/X.S0054-100-0_v2.0_080909.pdf BRG Peny From kleung@cisco.com Mon Nov 9 23:17:42 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397783A6A47 for ; Mon, 9 Nov 2009 23:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9j0maM7Oo8t for ; Mon, 9 Nov 2009 23:17:39 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D9B033A6824 for ; Mon, 9 Nov 2009 23:17:39 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAO6i+EqrR7Ht/2dsb2JhbACCJivBa5d+hD4EgWg X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208,217";a="428849127" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2009 07:18:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA7I2Lq000074 for ; Tue, 10 Nov 2009 07:18:02 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:18:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA61D5.F05619C2" Date: Mon, 9 Nov 2009 23:18:01 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520A5A974B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-mip4-gre-key-extension-00.txt Thread-Index: Acph1e+rxRb43PqCRruIrlI8at51WA== From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 10 Nov 2009 07:18:02.0723 (UTC) FILETIME=[F0AC4330:01CA61D5] Subject: [Mip4] draft-mip4-gre-key-extension-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:17:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA61D5.F05619C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is not backwards compatible with RFC 3344 which supports GRE tunneling, which is established by setting the G bit w/o GRE Key Extension. =20 "If the HA receives a Registration Request with the 'G' bit set but without the GRE Key Extension, it SHALL send an RRP with code 'Poorly Formed Request (0xY2)'." =20 Kent ------_=_NextPart_001_01CA61D5.F05619C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is not backwards compatible with RFC 3344 which supports GRE tunneling, = which is established by setting the G bit w/o GRE Key = Extension.

 

   “If the HA receives a Registration Request with =
the 'G' bit set but
   without the GRE =
Key Extension, it SHALL send an RRP with code =
'Poorly
   Formed Request =
(0xY2)'.”

 

Kent

------_=_NextPart_001_01CA61D5.F05619C2-- From kleung@cisco.com Mon Nov 9 23:55:22 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849763A69A5 for ; Mon, 9 Nov 2009 23:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5T6655OHHLm for ; Mon, 9 Nov 2009 23:55:15 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 79CD43A6837 for ; Mon, 9 Nov 2009 23:55:15 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEANqr+EqrR7Hu/2dsb2JhbACCJC3CEJgDgkeBdwSBaA X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208,217";a="48740929" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 07:55:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAA7tUwS020648 for ; Tue, 10 Nov 2009 07:55:30 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:55:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA61DB.2C283702" Date: Mon, 9 Nov 2009 23:55:28 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520A5A9756@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-makela-mip4-nemo-haaro-05.txt Thread-Index: Acph2ysmDh9lkav4QHSOjKkepjC3og== From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 10 Nov 2009 07:55:30.0428 (UTC) FILETIME=[2C68D3C0:01CA61DB] Subject: [Mip4] draft-makela-mip4-nemo-haaro-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:55:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA61DB.2C283702 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few comments on the draft: =20 1) Support for other realms. Does different realms imply different IP address space? This introduces the problem with overlapped IP address for prefix and also MR HoA. =20 Each network prefix can be associated to a realm, usually in the form 'organization.example.com'. Besides the routers in customer's own organization, the prefix list may also include other Mobile Routers, e.g. Default prefix (0.0.0.0/0) pointing towards Internet gateway for Internet connectivity, and possible extranets. The realm information can be used to make policy decisions on the Mobile Router, such as preferring optimization within specific realm only. =20 2) For the different realm case (CRs served by different HAs), how does CR's HA know? This is just another issue with different HAs support. Currently, the draft does say this is out of scope. =20 In a registration request, the Mobile Router claims to represent an arbitrary IPv4 network. If the CR has not yet received this information (HoA <-> Network prefix), it SHOULD perform a re-registration to Home Agent to verify the claim. =20 3) When there are many MRs, the size of the RRP can be huge. The RO cache has to have all the MRs' prefixes to work properly (i.e. the last registered MR has the full table). I would propose a more scalable method. Since the HA is aware of the RO-support mode of the MRs for traffic between their networks, HA should notify the MR(s) to trigger Return Routability. In the case of NAT traversal on one MR, HA would tell the right MR to initiate the signaling. It's also possible that HA facilitate the keying. =20 4) Clarify the NAT case. A diagram with more details would be helpful. How does RR work with CR's private IPv4 HoA? The CoTI message cannot be routed directed from MR (using its CoA). It does matter which MR initiates the RR with the different cases of one side of the MR is behind NAT, or both MRs are behind the same NAT. =20 5) Unfortunately this is likely a common scenario. Just a comment. When HA detects this case, it may not trigger RO if the new method #3 is used. =20 If both the Mobile Router and the Correspondent Router are behind separate NATs, route optimization cannot be performed between them. Possibilities to set up mutual tunneling when both routers are behind NAT, are outside the scope of this draft.=20 =20 6) Different realms may have overlapped HoA's. =20 Due to the fact that the route optimization procedures may occur concurrently at two Mobile Routers, each working as each other's Correspondent Router, there may be a situation where two routers are attempting to establish separate tunnels between them at the same time. If a router with a smaller Home Address (meaning a normal 32- bit integer comparison treating IPv4 addresses as 32-bit unsigned integers) receives a registration request (in CR role) while its own registration request (sent in MR role) is still pending, the reply must be deferred until the tunnel initiated by its registration request is up. This avoids the problem of two separate tunnels forming concurrently between two Mobile Routers. =20 7) What happens when both MR and CR moves at the same time? Maybe some text to cover this? =20 8) CR cannot initiate RR in this case. =20 =20 In the case where Mobile Router is behind NAT (or firewall) and Correspondent Router is not, the Mobile Router will, when tunnel has been established, send keepalive messages (ICMP echo requests) through the tunnel. Until a reply has been received, the tunnel SHOULD NOT be considered active. Once reply has been received, NAT mapping is in place and traffic can be sent. =20 9) HA does not know the same NAT unless the same CoA address (use explicit language). Different IP address does not mean it's not the same NAT. =20 If Mobile Router and Correspondent Router are behind same NAT from HA's point of view, it is possible to establish tunnel between them. =20 10)Generic notification message could be used by HA to inform the MRs of new MRs/prefixes. Just a thought. =20 Kent =20 =20 ------_=_NextPart_001_01CA61DB.2C283702 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few comments on the draft:

 

1)  Support for other realms.  =
Does different realms imply different IP address space?  This =
introduces the problem with overlapped IP address for prefix and also MR =
HoA.
 
   Each =
network prefix can be associated to a realm, usually in the =
form
   'organization.example.com'.  =
Besides the routers in customer's own
   =
organization, the prefix list may also include other Mobile =
Routers,
   e.g.  Default prefix =
(0.0.0.0/0) pointing towards Internet =
gateway
   for Internet connectivity, and =
possible extranets.  The realm
   =
information can be used to make policy decisions on the =
Mobile
   Router, such as preferring =
optimization within specific realm =
only.
 
2)  For the different realm case (CRs =
served by different HAs), how does CR’s HA know?  This is =
just another issue with different HAs support.  Currently, the =
draft does say this is out of =
scope.
 
   In =
a registration
   request, the Mobile =
Router claims to represent an arbitrary =
IPv4
   network.  If the CR has not =
yet received this information (HoA =
<->
   Network prefix), it SHOULD =
perform a re-registration to Home Agent =
to
   verify the =
claim.
 
3)  When there are many MRs, the size =
of the RRP can be huge.  The RO cache has to have all the =
MRs’ prefixes to work properly (i.e. the last registered MR has =
the full table).  I would propose a more scalable method.  =
Since the HA is aware of the RO-support mode of the MRs for traffic =
between their networks, HA should notify the MR(s) to trigger Return =
Routability.  In the case of NAT traversal on one MR, HA would tell =
the right MR to initiate the signaling.  It’s also possible =
that HA facilitate the keying.

 

4)  = Clarify the NAT = case.  A diagram with more details would be helpful.  How does RR work = with CR’s private IPv4 HoA?  The CoTI message cannot be routed = directed from MR (using its CoA).  It does matter which MR initiates the RR = with the different cases of one side of the MR is behind NAT, or both MRs are = behind the same NAT.

 

5)  = Unfortunately this = is likely a common scenario.  Just a comment.  When HA detects this = case, it may not trigger RO if the new method #3 is used.

 

   If both the Mobile Router and the Correspondent Router =
are behind
   separate NATs, route =
optimization cannot be performed between =
them.
   Possibilities to set up mutual =
tunneling when both routers are behind
   =
NAT, are outside the scope of this draft.

 

6)  = Different realms = may have overlapped HoA’s.

 

   Due to the fact that the route optimization procedures =
may occur
   concurrently at two Mobile =
Routers, each working as each other's
   =
Correspondent Router, there may be a situation where two routers =
are
   attempting to establish separate =
tunnels between them at the same
   =
time.  If a router with a smaller Home Address (meaning a normal =
32-
   bit integer comparison treating =
IPv4 addresses as 32-bit unsigned
   =
integers) receives a registration request (in CR role) while its =
own
   registration request (sent in MR =
role) is still pending, the reply
   must =
be deferred until the tunnel initiated by its =
registration
   request is up.  This =
avoids the problem of two separate =
tunnels
   forming concurrently between =
two Mobile Routers.

 

7)  = What happens when = both MR and CR moves at the same time?  Maybe some text to cover = this?

 

8)  =  CR cannot = initiate RR in this case. 

 

   In the case where Mobile Router is behind NAT (or =
firewall) and
   Correspondent Router is =
not, the Mobile Router will, when tunnel =
has
   been established, send keepalive =
messages (ICMP echo requests)
   through =
the tunnel.  Until a reply has been received, the =
tunnel
   SHOULD NOT be considered =
active.  Once reply has been received, =
NAT
   mapping is in place and traffic =
can be sent.

 

9)  = HA does not know = the same NAT unless the same CoA address (use explicit language).  Different = IP address does not mean it’s not the same NAT.

 

   If Mobile Router and Correspondent Router are behind =
same NAT from
   HA's point of view, it =
is possible to establish tunnel between them.

 

10)Generic = notification message could be used by HA to inform the MRs of new MRs/prefixes.  Just a thought.

 

Kent

 

 

------_=_NextPart_001_01CA61DB.2C283702-- From jeedward@yahoo.com Tue Nov 10 01:48:57 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0983A6810 for ; Tue, 10 Nov 2009 01:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJEtfv7saLLB for ; Tue, 10 Nov 2009 01:48:56 -0800 (PST) Received: from web45914.mail.sp1.yahoo.com (web45914.mail.sp1.yahoo.com [68.180.199.83]) by core3.amsl.com (Postfix) with SMTP id 44E4D3A6A86 for ; Tue, 10 Nov 2009 01:48:56 -0800 (PST) Received: (qmail 98221 invoked by uid 60001); 10 Nov 2009 09:49:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1257846562; bh=2803LzH/mU9zr4zMh2oDBQQEpTPBU7KOhfnaR1KUdaE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=YrLmq6xEVJqPc/R/pPMv1lTAaFPd4L54rbnlIyl2WNAi6LrKUcc+MDgnk1ZhzP/rlsd+R8LxYwoUs0i8JU6tfWNNyqm4jAU9Ogk9pOm7La2zXYQaeSkDwo/MK7KmWSQBejuvHyWM6rEUYu21f7SxPN5wDaByEiS30EtdwQY8nR8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=l9Xcuwbmb4we/mpA/JqfPoBc9EW26X4oIbwtOgOoERfiBc8B/JbDEGLNyUPXNTxlzq2luqhycb5cKAfUZAyYjpS/wJqJm+Z7xJZJ5o4bMFDYxEYGmtZSZcgJO3hDgVazoXLRJqK0jMtWtjMGYWvpxFxGf+DgAxjwu8mTBFMsisE=; Message-ID: <39390.94528.qm@web45914.mail.sp1.yahoo.com> X-YMail-OSG: 2ZOIZXEVM1nPWQAzQEhFlRbjZrF3wvbcZ2NZntAcIp1N7ZF6VDna.kiVP.0m3eQO0BkLk8YPLPo3fRh.1JPigp3Le_.vUlAcgEQJqibNtO6IcOCFuT2JF72S7PrEmrG7a.ZTOJdAXD1mCHjcVFBz34lySgtlAN3Y4WjE8hoxCklI8rJU5SYLkvkgXrKh5nq79XAR_jC_KF7Coy8Mto5U2SOeKAP6B3KtfCTp34eZQaa_IOQcoDQxfEdQA_my_PABcfiJgC_5wXOsJa0pBjSrCEY_2hEG6.L_zYyGjl4OadFb8mElpMmfF86PRqrxiUXhg57Pfml4079ild1YvWQgSECmOfkPyc3aSYqFXFXlLs8IC72xbvrCQNFklrDNHyLsjE1XzXfv4WmXbE3yg3sADDFalonG6u0VrPaad30- Received: from [67.235.252.244] by web45914.mail.sp1.yahoo.com via HTTP; Tue, 10 Nov 2009 01:49:21 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4 Date: Tue, 10 Nov 2009 01:49:21 -0800 (PST) From: John Edward To: mip4@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-55118724-1257846561=:94528" Subject: [Mip4] CN-10 Call for papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:48:57 -0000 --0-55118724-1257846561=:94528 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable CN-10 Call for papers =A0 The 2010 International Conference on Computer Networks (CN-10) (website: ht= tp://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orl= ando, FL, USA. =A0CN is an important event in the area of computer networks= , communications and applications. =A0 The conference will be held at the same time and location where several oth= er major international conferences will be taking place. The conference wil= l be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 wil= l be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goa= l of MULTICONF is to promote research and developmental activities in compu= ter science, information technology, control engineering, and related field= s. Another goal is to promote the dissemination of research to a multidisci= plinary audience and to facilitate communication among researchers, develop= ers, practitioners in different fields. The following conferences are plann= ed to be organized as part of MULTICONF-10. =A0 International Conference on Artificial Intelligence and Pattern Recognition= (AIPR-10) =A0International Conference on Automation, Robotics and Control Systems (AR= CS-10) International Conference on Bioinformatics, Computational Biology, Genomics= and Chemoinformatics (BCBGC-10) International Conference on Computer Networks (CN-10) International Conference on Enterprise Information Systems and Web Technolo= gies (EISWT-10) International Conference on High Performance Computing Systems (HPCS-10) International Conference on Information Security and Privacy (ISP-10)=20 International Conference on Image and Video Processing and Computer Vision = (IVPCV-10) International Conference on Software Engineering Theory and Practice (SETP-= 10)=20 International Conference on Theoretical and Mathematical Foundations of Com= puter Science (TMFCS-10)=20 =A0 We invite draft paper submissions. Please see the website http://www.Promot= eResearch.org for more details. =A0 Sincerely John Edward Publicity committee=0A=0A=0A --0-55118724-1257846561=:94528 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

CN-10 Call for papers

&= nbsp;

The 2010 International Confere= nce on Computer Networks (CN-10) (website: http://www.Promo= teResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA.  CN is an important even= t in the area of computer networks, communications and applications.=
 
The conference will be held at= the same time and location where several other major international confere= nces will be taking place. The conference will be held as part of 2010 mult= i-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2= 010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote r= esearch and developmental activities in computer science, information techn= ology, control engineering, and related fields. Another goal is to promote = the dissemination of research to a multidisciplinary audience and to facili= tate communication among researchers, developers, practitioners in differen= t fields. The following conferences are planned= to be organized as part of MULTICONF-10.

&= nbsp;

  • International Conference on Artificial Intelligence an= d Pattern Recognition (AIPR-10)
  •  Interna= tional Conference on Automation, Robotics and Control Systems (ARCS-10)<= /o:p>
  • International Conference on Bioinformatics, Computatio= nal Biology, Genomics and Chemoinformatics (BCBGC-10)
  • International Conference on Computer Networks (CN-10)<= A href=3D"http://www.promoteresearch.org/2009/eiswt/index.html">
  • International Conference on Enterprise Information Sys= tems and Web Technologies (EISWT-10)
  • International Conference on High Performance Computing= Systems (HPCS-10)
  • International Conference on Information Security and P= rivacy (ISP-10)
  • International Conference on Image and Video Processing= and Computer Vision (IVPCV-10)
  • International Conference on Software Engineering Theor= y and Practice (SETP-10)
  • International Conference on Theoretical and Mathematic= al Foundations of Computer Science (TMFCS-10)

&= nbsp;

We inv= ite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details.

&= nbsp;

Sincer= ely

John E= dward

Public= ity committee


=0A=0A=0A=0A = --0-55118724-1257846561=:94528-- From kleung@cisco.com Tue Nov 10 16:21:43 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27A128C188 for ; Tue, 10 Nov 2009 16:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MrbyM-sPVvt for ; Tue, 10 Nov 2009 16:21:39 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B20AB28C0EF for ; Tue, 10 Nov 2009 16:21:39 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAAyT+UqrRN+J/2dsb2JhbACCJivDUJhHhD4EgWg X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208,217";a="269188627" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 00:21:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAB0LtYX000341 for ; Wed, 11 Nov 2009 00:21:55 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 16:21:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6264.F9456400" Date: Tue, 10 Nov 2009 16:21:51 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520A5A9B88@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-mip4-gre-key-extension-00.txt Thread-Index: Acph1e+rxRb43PqCRruIrlI8at51WAAiQ2XA From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 11 Nov 2009 00:21:55.0237 (UTC) FILETIME=[F94DFD50:01CA6264] Subject: Re: [Mip4] draft-mip4-gre-key-extension-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:21:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6264.F9456400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For folks who did not attend the WG session, my last email did not have any context. I was raising the backwards compatibility issue with the G bit and referring to the text in the current draft which needs to be updated. =20 Another item that came up was the use of short format. George mentioned that the preferred method is using the long extension format instead of the TLV format. =20 =20 A few other items not mentioned during the session: =20 1) Clarify the FA/HA operation when T bit (reverse tunnel) is set or not set in RRQ. This also means the behavior for the combination and permutation of settings for G bit, T bit, and extension presence/absence. =20 2) What's the impact on Registration Revocation (RFC 3543)? If Home Address can overlap, then the GRE extension should be included in Registration Revocation message. =20 Kent =20 =20 =20 From: Kent Leung (kleung)=20 Sent: Monday, November 09, 2009 11:18 PM To: mip4@ietf.org Subject: draft-mip4-gre-key-extension-00.txt =20 This is not backwards compatible with RFC 3344 which supports GRE tunneling, which is established by setting the G bit w/o GRE Key Extension. =20 "If the HA receives a Registration Request with the 'G' bit set but without the GRE Key Extension, it SHALL send an RRP with code 'Poorly Formed Request (0xY2)'." =20 Kent ------_=_NextPart_001_01CA6264.F9456400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For folks who did not = attend the WG session, my last email did not have any context.  I was raising = the backwards compatibility issue with the G bit and referring to the text = in the current draft which needs to be updated.

 

Another item that = came up was the use of short format.  George mentioned that the preferred = method is using the long extension format instead of the TLV  format.  =

 

A few other items not = mentioned during the session:

 

1)      Clarify the = FA/HA operation when T bit (reverse tunnel) is set or not set in RRQ.  This also = means the behavior for the combination and permutation of settings for G bit, T = bit, and extension presence/absence. 

2)      What’s the impact on Registration Revocation (RFC 3543)?  If Home Address can overlap, then the GRE extension should be included in Registration = Revocation message.

 

Kent

 

 

 

From:= Kent Leung = (kleung)
Sent: Monday, November 09, 2009 11:18 PM
To: mip4@ietf.org
Subject: = draft-mip4-gre-key-extension-00.txt

 

This is not backwards compatible with RFC 3344 which supports GRE tunneling, = which is established by setting the G bit w/o GRE Key = Extension.

 

   “If the HA receives a Registration Request with =
the 'G' bit set but
   without the GRE =
Key Extension, it SHALL send an RRP with code =
'Poorly
   Formed Request =
(0xY2)'.”

 

Kent

------_=_NextPart_001_01CA6264.F9456400-- From jouni.nospam@gmail.com Wed Nov 11 05:39:11 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D880128C292 for ; Wed, 11 Nov 2009 05:39:11 -0800 (PST) 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 OQXlBT1U3kTu for ; Wed, 11 Nov 2009 05:39:10 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 3C39F28C1A9 for ; Wed, 11 Nov 2009 05:39:10 -0800 (PST) Received: by fxm7 with SMTP id 7so1020795fxm.29 for ; Wed, 11 Nov 2009 05:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=s/Jxu8PxrgGAQl94XFXdUonlYf53id/zzAXIUpm/a7A=; b=lsNv/CI8rY9OtKpTGouoYffOC1F8F77YvIt25wlrzVaPBuVPg9EASHNB6spYghMA05 KQgC2EUVj9WrHC+oQ8FaNuU+zEfHfivGZyPPGAAZFxzwDoUaQkF/DFd63m1ywYCnDYih TuvcU4vTT9YWQEkmxU5H8ousAxFqk0zyg9i5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=diyxdzk8yOpK9+XRkeWtyTNTrzjFzh1hVMbfWDE845dpmnliehq9NaOY/UnS6y7ZQ7 qXN8hDSlVJoFjdxudQ6FN/ip4fe7Lr/THIvr8e01JCQVcqWP/wWmx2z9W7haIv8zR1GM Dc6JWZ2iePnxBlVMloxdWyEi+3bfz11Dn7vB8= Received: by 10.216.88.136 with SMTP id a8mr443417wef.77.1257946774579; Wed, 11 Nov 2009 05:39:34 -0800 (PST) Received: from host-160-45.meeting.ietf.org (host-160-45.meeting.ietf.org [133.93.160.45]) by mx.google.com with ESMTPS id p10sm5100966gvf.29.2009.11.11.05.39.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 05:39:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: jouni korhonen In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520A5A9756@xmb-sjc-235.amer.cisco.com> Date: Wed, 11 Nov 2009 15:39:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75C445C6-1A41-4208-AEBF-13DA9E8EB456@gmail.com> References: <2979E38DD6FC6544B789C8DAD7BAFC520A5A9756@xmb-sjc-235.amer.cisco.com> To: Kent Leung (kleung) X-Mailer: Apple Mail (2.1076) Cc: mip4@ietf.org Subject: Re: [Mip4] draft-makela-mip4-nemo-haaro-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:39:11 -0000 Hi Kent, Thanks a lot for the comments. We tried to get some answers and =20 further questions below. > From: "Kent Leung (kleung)" > Date: November 10, 2009 9:55:28 AM GMT+02:00 > To: > Subject: [Mip4] draft-makela-mip4-nemo-haaro-05.txt > > A few comments on the draft: > > 1) Support for other realms. Does different realms imply different =20= > IP address space? This introduces the problem with overlapped IP =20 > address for prefix and also MR HoA. Multiple, separate (logical) HA's are not supported - otherwise a HA =20 could not really be even assisting MRs during the RO process as the =20 draft describes. Single HA serving multiple realms are supported. I'm =20= not seeing the issue with overlapping IP address spaces. As stated in =20= the draft, the realm information is optional and meant to assist in =20 making policy decisions. In default case, realm info is not even =20 included in replies, and HA would only distribute information on MRs =20 belonging to same realm. However, if two realms wish to communicate =20 directly, they can contact HA's administrator and ask the admin to =20 enable this "extranet" functionality. In that case, you have all the =20 normal issues with making address spaces non-overlapping of course, =20 but that's not exactly problem with RO solution proposed in the draft. > > Each network prefix can be associated to a realm, usually in the =20 > form > 'organization.example.com'. Besides the routers in customer's own > organization, the prefix list may also include other Mobile Routers, > e.g. Default prefix (0.0.0.0/0) pointing towards Internet gateway > for Internet connectivity, and possible extranets. The realm > information can be used to make policy decisions on the Mobile > Router, such as preferring optimization within specific realm only. > > 2) For the different realm case (CRs served by different HAs), how =20= > does CR=92s HA know? This is just another issue with different HAs =20= > support. Currently, the draft does say this is out of scope. The RO described in the draft works reliably only for MRs served by a =20= pool of HAs under the same administration. That is a restriction in =20 the current solution as it was never targeted to work in an =20 environment where a MR would initiate a RO with another MR that is =20 under different administration (e.g. different operator running its =20 HA). Such deployment does not really fit to any existing deployment/=20 business model we wanted to apply MRs & RO in the first place. One HA =20= can serve multiple realms, though. We probably need to think a bit more of a generalized form of RO, =20 where MRs do not need to belong to the same administration, at least =20 when the I-D is worked as a WG I-D. The RO signaling and data =20 structures already in the draft support RO with any MR regardless of =20 under which HA they are anchored as discussed to some extent in =20 Sections 6.3 and 6.5. However, in that case the information of other =20 MRs and subnets served by them has to be learned by some other means =20 (..which are not described in the current draft obviously). > > In a registration > request, the Mobile Router claims to represent an arbitrary IPv4 > network. If the CR has not yet received this information (HoA <-> > Network prefix), it SHOULD perform a re-registration to Home Agent =20= > to > verify the claim. > > 3) When there are many MRs, the size of the RRP can be huge. The =20 > RO cache has to have all the MRs=92 prefixes to work properly (i.e. =20= > the last registered MR has the full table). I would propose a more =20= > scalable method. Since the HA is aware of the RO-support mode of =20 > the MRs for traffic between their networks, HA should notify the MR=20 > (s) to trigger Return Routability. In the case of NAT traversal on =20= > one MR, HA would tell the right MR to initiate the signaling. It=92s =20= > also possible that HA facilitate the keying. That is a possible approach. However, that requires the HA to keep =20 track of traffic exchanged between different MRs for a dynamically =20 varying number of subnets, which probably becomes a burden to the HA =20 at some point. Current approach makes the HA role in the RO rather =20 lightweight, which was one of the goals of the original proposal. I would be interested in learning what size of MR networks you have in =20= mind and based on which deployment scenarios? > > 4) Clarify the NAT case. A diagram with more details would be =20 > helpful. How does RR work with CR=92s private IPv4 HoA? The CoTI =20 > message cannot be routed directed from MR (using its CoA). It does =20= > matter which MR initiates the RR with the different cases of one =20 > side of the MR is behind NAT, or both MRs are behind the same NAT. We can clarify the NAT case for sure.. at least when the I-D is worked =20= as a WG I-D. I don't really see a real reason why the MR HoA should be private =20 (unless the HA address is also private) other than "it can be done" =20 with IPv4? > > 5) Unfortunately this is likely a common scenario. Just a =20 > comment. When HA detects this case, it may not trigger RO if the =20 > new method #3 is used. What do you refer with method #3 to? Anyway, cases where both MRs are =20= behind a NAT are possible, agree. How likely they are is questionable. =20= There is a limit where a protocol complexity to does not justify =20 adding a feature anymore. In case of two MRs behind NATs talking =20 directly to each other falls into that category. It could be possible =20= to do hole punching and such but that again works only if there are no =20= nested NATs. Besides, when this situation happens e.g. due a MR =20 movement, the operation falls back to normal HA routed case, so no =20 harm was done. > > If both the Mobile Router and the Correspondent Router are behind > separate NATs, route optimization cannot be performed between them. > Possibilities to set up mutual tunneling when both routers are =20 > behind > NAT, are outside the scope of this draft. > > 6) Different realms may have overlapped HoA=92s. This is similar case as in 1) MRs under the administration of a same =20 HA cannot have overlapping HoAs. > > Due to the fact that the route optimization procedures may occur > concurrently at two Mobile Routers, each working as each other's > Correspondent Router, there may be a situation where two routers are > attempting to establish separate tunnels between them at the same > time. If a router with a smaller Home Address (meaning a normal 32- > bit integer comparison treating IPv4 addresses as 32-bit unsigned > integers) receives a registration request (in CR role) while its own > registration request (sent in MR role) is still pending, the reply > must be deferred until the tunnel initiated by its registration > request is up. This avoids the problem of two separate tunnels > forming concurrently between two Mobile Routers. > > 7) What happens when both MR and CR moves at the same time? Maybe =20= > some text to cover this? This can be clarified.. at least when the I-D is worked as a WG I-D. > > 8) CR cannot initiate RR in this case. What this comment refers to? > > In the case where Mobile Router is behind NAT (or firewall) and > Correspondent Router is not, the Mobile Router will, when tunnel has > been established, send keepalive messages (ICMP echo requests) > through the tunnel. Until a reply has been received, the tunnel > SHOULD NOT be considered active. Once reply has been received, NAT > mapping is in place and traffic can be sent. > > 9) HA does not know the same NAT unless the same CoA address (use =20 > explicit language). Different IP address does not mean it=92s not the = =20 > same NAT. Ok. > > If Mobile Router and Correspondent Router are behind same NAT from > HA's point of view, it is possible to establish tunnel between them. Right. However, how likely scenario this is? Just trying to scope =20 whether it is worth adding extra features to detect/react to such case =20= if it turns out to be a corner case and would need huge amount of work =20= to get done properly. > > 10)Generic notification message could be used by HA to inform the =20 > MRs of new MRs/prefixes. Just a thought. Well, it could be used. Though, we did not originally pick it up =20 although the generic notification draft already existed when we =20 published the first version.. Cheers, Jouni > > Kent > From jari.arkko@piuha.net Fri Nov 20 03:44:25 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBCD3A69CC; Fri, 20 Nov 2009 03:44:25 -0800 (PST) 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 U1CT3duo16KM; Fri, 20 Nov 2009 03:44:24 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B18803A6922; Fri, 20 Nov 2009 03:44:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B7873D4954; Fri, 20 Nov 2009 13:44:20 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lNTqSIUkfJ2; Fri, 20 Nov 2009 13:44:19 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 93142D491E; Fri, 20 Nov 2009 13:44:19 +0200 (EET) Message-ID: <4B068112.7050805@piuha.net> Date: Fri, 20 Nov 2009 13:44:18 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ralph Droms , Cullen Jennings , Lars Eggert , "Romascanu, Dan (Dan)" , Robert Sparks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mip4-generic-notification-message@tools.ietf.org, Mobile IPv4 Mailing List , IESG Subject: [Mip4] coming back to draft-ietf-mip4-generic-notification-message X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 11:44:25 -0000 Lars, Cullen, Robert, Ralph, Dan, and other ADs who had critical comments on this draft, We discussed the situation in the MIP4 WG meeting in Hiroshima. Only Lars and me were in the meeting. Here's what we uncovered. As you may recall, the basic issue was threefold: whether there's an actual need to have this extension, why we need a generic mechanism as opposed to building specific protocol extensions when we need them, and whether we are opening the protocol for "free for all" extensions. The working group meeting gave us the following answers: On the need: First, Henrik expressed a desire that one previously designed extension would have been designed on top of this framework rather than designed as a standalone mechanism. But obviously the train has left the station for that. Regarding future extensions, there is one use case in 3GPP2 specifications which builds on the proposed generic mechanism. In addition, Kent gave us a couple of examples of what we might want to do in the future. The first example involves the home agent updating the mobile router's assigned prefix. The second example was host configuration changes (e.g., DNS or other server address changes) where the home agent would again wish to inform the mobile node. The room felt that these examples were potentially good uses cases for the extension. On the use of generic vs. standalone extensions: In general, all of these extensions CAN be designed as standalone, but the working group felt that it would be better to use a uniform design for all notifications in the ha->mn direction. To ensure that every extension does not implement the same thing in a different way. Even if the generic protocol itself is very minimal, basically just a new container. The ha->mn direction for notification is not something that the Mobile IPv4 protocol has traditionally supported. Free for all concern: The working group noted that there already exists vendor-specific extension mechanisms, and that the purpose of this extension is not to open the protocol for new extensions outside the IETF. Those extensions can already be done. At the end of the meeting, we proposed the following way forward. First, we wanted to convey the use cases and rationale to the IESG. Second, we would like to change the specification so that it requires a stricter IANA allocation policy. Specification required, RFC required, or something along those lines before a code point can be allocated on top of the generic notification service. Does this way forward help resolve your concerns about this extension? There are no minutes from the session yet, but audio recordings can be found here: ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch5-tue-afnoon.mp3 and the discussion starts around 25min from the beginning. Jari From dromasca@avaya.com Mon Nov 23 03:16:33 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C1228C14E; Mon, 23 Nov 2009 03:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 NLdtwV4QaLFF; Mon, 23 Nov 2009 03:16:32 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2BB5728C14F; Mon, 23 Nov 2009 03:16:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,271,1257138000"; d="scan'208";a="191284763" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Nov 2009 06:16:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Nov 2009 06:16:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 12:16:11 +0100 Message-ID: In-Reply-To: <4B068112.7050805@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: coming back to draft-ietf-mip4-generic-notification-message Thread-Index: Acpp1tUrsIB1GHcJTOajk/YE4sS8xwCV0u2Q References: <4B068112.7050805@piuha.net> From: "Romascanu, Dan (Dan)" To: "Jari Arkko" , "Ralph Droms" , "Cullen Jennings" , "Lars Eggert" , "Robert Sparks" Cc: draft-ietf-mip4-generic-notification-message@tools.ietf.org, Mobile IPv4 Mailing List , IESG Subject: Re: [Mip4] coming back to draft-ietf-mip4-generic-notification-message X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:16:33 -0000 Jari, Although I share to a certain degree the broader concerns expressed by other AD's the issues raised in my DISCUSS are more specific. I do not see them addressed in your response, so I am still expecting a response, or revised I-D for these to be addressed - of course assuming that this work continues.=20 Dan =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Jari Arkko > Sent: Friday, November 20, 2009 1:44 PM > To: Ralph Droms; Cullen Jennings; Lars Eggert; Romascanu, Dan=20 > (Dan); Robert Sparks > Cc:=20 > draft-ietf-mip4-generic-notification-message@tools.ietf.org;=20 > Mobile IPv4 Mailing List; IESG > Subject: coming back to draft-ietf-mip4-generic-notification-message >=20 > Lars, Cullen, Robert, Ralph, Dan, and other ADs who had=20 > critical comments on this draft, >=20 > We discussed the situation in the MIP4 WG meeting in=20 > Hiroshima. Only Lars and me were in the meeting. Here's what=20 > we uncovered. >=20 > As you may recall, the basic issue was threefold: whether=20 > there's an actual need to have this extension, why we need a=20 > generic mechanism as opposed to building specific protocol=20 > extensions when we need them, and whether we are opening the=20 > protocol for "free for all" extensions. The working group=20 > meeting gave us the following answers: >=20 > On the need: First, Henrik expressed a desire that one=20 > previously designed extension would have been designed on top=20 > of this framework rather than designed as a standalone=20 > mechanism. But obviously the train has left the station for=20 > that. Regarding future extensions, there is one use case in=20 > 3GPP2 specifications which builds on the proposed generic=20 > mechanism. In addition, Kent gave us a couple of examples of=20 > what we might want to do in the future. The first example=20 > involves the home agent updating the mobile router's assigned=20 > prefix. The second example was host configuration changes=20 > (e.g., DNS or other server address > changes) where the home agent would again wish to inform the=20 > mobile node. The room felt that these examples were=20 > potentially good uses cases for the extension. >=20 > On the use of generic vs. standalone extensions: In general,=20 > all of these extensions CAN be designed as standalone, but=20 > the working group felt that it would be better to use a=20 > uniform design for all notifications in the ha->mn direction.=20 > To ensure that every extension does not implement the same=20 > thing in a different way. Even if the generic protocol itself=20 > is very minimal, basically just a new container.=20 > The ha->mn direction for notification is not something that the Mobile > IPv4 protocol has traditionally supported. >=20 > Free for all concern: The working group noted that there=20 > already exists vendor-specific extension mechanisms, and that=20 > the purpose of this extension is not to open the protocol for=20 > new extensions outside the IETF. Those extensions can already be done. >=20 > At the end of the meeting, we proposed the following way=20 > forward. First, we wanted to convey the use cases and=20 > rationale to the IESG. Second, we would like to change the=20 > specification so that it requires a stricter IANA allocation=20 > policy. Specification required, RFC required, or something=20 > along those lines before a code point can be allocated on top=20 > of the generic notification service. >=20 > Does this way forward help resolve your concerns about this extension? >=20 > There are no minutes from the session yet, but audio=20 > recordings can be found here:=20 > ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch 5-tue-afnoon.mp3 and the discussion starts around 25min from the beginning. Jari From fluffy@cisco.com Tue Nov 24 08:51:25 2009 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548E63A6B51; Tue, 24 Nov 2009 08:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlhydybtETJq; Tue, 24 Nov 2009 08:51:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 51D7A3A6A60; Tue, 24 Nov 2009 08:51:24 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,280,1257120000"; d="scan'208";a="439584211" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 24 Nov 2009 16:51:20 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAOGpHPv024549; Tue, 24 Nov 2009 16:51:17 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B068112.7050805@piuha.net> Date: Tue, 24 Nov 2009 09:51:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B561AEC-7B62-4EC5-9196-97D9B022D10B@cisco.com> References: <4B068112.7050805@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Tue, 24 Nov 2009 10:55:56 -0800 Cc: draft-ietf-mip4-generic-notification-message@tools.ietf.org, Ralph Droms , Dan Romascanu , Mobile IPv4 Mailing List , IESG IESG , Lars Eggert , Robert Sparks Subject: Re: [Mip4] coming back to draft-ietf-mip4-generic-notification-message X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:51:25 -0000 sounds like a path that would resolve my issues. Would the WG also make = sure that the draft documents what sort of extensions are appropriate = and what sort are not? On Nov 20, 2009, at 4:44 AM, Jari Arkko wrote: > Lars, Cullen, Robert, Ralph, Dan, and other ADs who had critical = comments on this draft, >=20 > We discussed the situation in the MIP4 WG meeting in Hiroshima. Only = Lars and me were in the meeting. Here's what we uncovered. >=20 > As you may recall, the basic issue was threefold: whether there's an = actual need to have this extension, why we need a generic mechanism as = opposed to building specific protocol extensions when we need them, and = whether we are opening the protocol for "free for all" extensions. The = working group meeting gave us the following answers: >=20 > On the need: First, Henrik expressed a desire that one previously = designed extension would have been designed on top of this framework = rather than designed as a standalone mechanism. But obviously the train = has left the station for that. Regarding future extensions, there is one = use case in 3GPP2 specifications which builds on the proposed generic = mechanism. In addition, Kent gave us a couple of examples of what we = might want to do in the future. The first example involves the home = agent updating the mobile router's assigned prefix. The second example = was host configuration changes (e.g., DNS or other server address = changes) where the home agent would again wish to inform the mobile = node. The room felt that these examples were potentially good uses cases = for the extension. >=20 > On the use of generic vs. standalone extensions: In general, all of = these extensions CAN be designed as standalone, but the working group = felt that it would be better to use a uniform design for all = notifications in the ha->mn direction. To ensure that every extension = does not implement the same thing in a different way. Even if the = generic protocol itself is very minimal, basically just a new container. = The ha->mn direction for notification is not something that the Mobile = IPv4 protocol has traditionally supported. >=20 > Free for all concern: The working group noted that there already = exists vendor-specific extension mechanisms, and that the purpose of = this extension is not to open the protocol for new extensions outside = the IETF. Those extensions can already be done. >=20 > At the end of the meeting, we proposed the following way forward. = First, we wanted to convey the use cases and rationale to the IESG. = Second, we would like to change the specification so that it requires a = stricter IANA allocation policy. Specification required, RFC required, = or something along those lines before a code point can be allocated on = top of the generic notification service. >=20 > Does this way forward help resolve your concerns about this extension? >=20 > There are no minutes from the session yet, but audio recordings can be = found here: = ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch5-tue-afnoon= .mp3 and the discussion starts around 25min from the beginning. >=20 > Jari >=20