From mailman-bounces@ietf.org Fri Oct 1 08:16:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22905 for ; Fri, 1 Oct 2004 08:16:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJxj-0006qJ-9p for nemo-archive@lists.ietf.org; Fri, 01 Oct 2004 05:44:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:17:50 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-bounces@ietf.org Mon Oct 4 02:24:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00766 for ; Mon, 4 Oct 2004 02:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMER-0006dq-3O; Mon, 04 Oct 2004 02:21:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMB0-0005Aj-Jx for nemo@megatron.ietf.org; Mon, 04 Oct 2004 02:18:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00005 for ; Mon, 4 Oct 2004 02:18:24 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMK0-0002fW-Pt for nemo@ietf.org; Mon, 04 Oct 2004 02:27:46 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i946FGeU023267; Mon, 4 Oct 2004 14:15:16 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 808E7B240CD; Mon, 4 Oct 2004 14:21:54 +0800 (SGT) Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <415C162C.9020202@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096870913.9192.62.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 14:21:53 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Alex, I hope to address as much of your concern as possible to my best knowledge. Some issues you raised are beyond me, so I left them alone. /rgds /cwng On Thu, 2004-09-30 at 22:20, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > Like to ask the WG on their opinions of what is still lacking for the > > draft to be put forth as the RO Problem Space analysis. All comments > > are greatly appreciated. > > Dear Chan-Wah, I've read the draft in more detail and I have several > comments. I've hesitated before sending them, because they may look too > harsh, but then you say that all comments are greatly appreciated so I'm > sending them. I think the draft has some good parts and some badly > explained parts and some unnecessary parts. > No problem about comments being harsh (In fact, I don't think any of them is harsh, I thought your previous mail was harsher :)). Thank you for your insightful and thorough comments. > > between nodes in a mobile network and their correspodnet nodes. > > correspondent. > ok. > > route optimization with corresponding nodes initiated bu mobile > > by for bu. > ok. > > 3. performing RO over the routing infrastructure involving > > optimizing the route between two routers situated near to each end > > point, instead of end-to-end; > > Last words should be "instead of end-to-end RO" and "end-to-end RO" > should be defined somewhere. Where is it defined? google "end-to-end" > the first entry is right so you're lucky. > > "End-to-end" is like saying that your app talks to my app, and that your > app does not talk to my kernel. _That_ is "end-to-end". Ping is not > "end-to-end" because your app talks to my kernel. But better rely on > that paper's explanation and on that of RFC 3724 "The Rise of the Middle > and the Future of End-to-End" and of RFC 3439 "Architectural Guidelines". > > "End-to-end" is not adapted for what you're trying to say, to my taste. > I think what you're trying to say with "end-to-end RO" is more like > "keep the network dumb" or "empower the end user" or "keep soft state in > the network" or "fate-sharing" similar. I don't have a reference handy > for this, but the term "end-to-end" is so much used and so badly so > often that I'd take no risk and not use it at all. > I see, ok. Will use some other expression. > > Lastly, route optimizations involving nested mobile networks are > > explored. This involves minimizing the number of tunnels required > > when there is multiple levels of nesting. > > One can achieve minimal tunnels without actually offering shorter paths, > with ROHC. The two goals are different. > > > This scenario is useful when a lot of MNNs in a mobile network is > > communicating with a few > > "MNN's are communicating", not the "lot is communicating". > ok. > > In such cases the MR only needs to send one binding update (BU) to > > optimized the route between CN and a few MNNs. > > "optimize" instead. > ok. > If an MNN is actually a VMN, it is not sufficient for MR to send a BU to > CN, the comm still goes to that VMN's HA. Better use "LFN" instead of > "MNN". > That is arguably solution dependent. I propose to add in the word 'may', and will consider changing MNN to LMN. > > A major issue with this form of optimization is that the end-to-end > > principle of the MIPv6 Reverse Routability (RR) test is broken. > > What is the "e2e principle of the MIPv6 RR test(s)"? RFC 3775 Mobile > IPv6 has no such principle... RFC 3775 Mobile IPv6 has another > end-to-end mentioning of end-to-end IPsec, but it is not an end-to-end RR. > > So the reader is not convinced this is a "major issue"; and also it's > called Return not Reverse. Agreed to your objection in the use of the term 'e2e'. But it is still a major issue. I will address this in greater detail in the update version of the draft. > > > If not, the optimization may be limited to triangular routing > > MR->CN->HA->MR. > > better: "optimization would be limited to only eliminating the CN-HA and > HA-MR edges of the MR-CN-HA triangular path." > > What's "triangular routing" by the way? Is it that all 3 edges are used > to send packets? Is it that only two edges are used so? (a prior > version of MIP6 was wrongly using sending packets MN-CN and receiving > CN-HA-MN, so that was "triangular"; current MIP6 w/o RO is bi-angular > path because there's no CN-MN path and there's CN-HA and HA-MN). > Agreed. I think the use of the term "triangular routing" was largely (and I admit wrongly) based on historical usage of the term to describe the suboptimal routing problem (I think dated as far back to MIPv4). > > When a Mobile Node visits a Mobile Network, the best Route > > Optimization is obtained if the path in the Infrastructure is the > > same as if the Mobile Network was attached at the attachment point of > > the Mobile Router (i.e., there is not additional Tunneling that is > > linked to NEMO). > > I don't understand this. The Mobile Network _is_ attached at the > attachment point of the Mobile Router, yet routes are not optimal. > I think the confusion is our unfortunate typo mistake "... if the Mobile *Network* was ..." should read "... if the Mobile *Node* was ...". > > In this model, both the LFN behind the MR and the Correspondent can > > be MIP agnostic. > > The CN can not be MIP agnostic because RFC 3775 requires it to be a MIP > believer. The CN may be NEMO-agnostic, and not be NEMO-aware. I agree to change "MIP" to "NEMO", but the reason you gave I disagree. RFC3775 defines "CN to be a peer node with which a mobile node is communicating". It makes no assumption whether CN is MIP-aware or not. But this is a small matter, and this draft is addressing NEMO RO. So we shouldn't be talking about MIP-agnostic, but NEMO-agnostic. > > The goal is to locate the closest (BGP) gateway for a Correspondent > > that is located outside of the domain, and tunnel between the MR and > > that gateway as opposed to the Home Agent for that specific > > Correspondent. > > There is a reference for BGP and mobile networks at a this year's NANOG > by Cisco I believe, find it. ok. > > "4.2 Correspondent Router" > > But earlier the draft was talking about "C-side routers". What's the > difference? > > > The Core Routers for the network of the Correspondent are all CRs. > > Yes, because CR stands for Core Router. Or? > > > M-side routers > > What do you call an edge router to which MR visits and that also serves > a CN? Is it a CM-side router? > > What is an MR to which two MR's visit whose LFN's talk to each other? > is this AR a CM-side router? > I will look into this section and clarify in the next version. > > 5.1 Nested Tunnels Optimization ... > > > > With no Nested Tunnels Optimization, we would have three > > bi-directional nested tunnels > > > > Such a solution introduces the following problems: > > > > "Pinball" routing > > What _is_ Nested Tunnels Optimization? > > What "solution" introduces the pinball routing? > > By your logic it would mean that Nested Tunnels Optimization is a > solution to the problem of having three bi-directional nested tunnels > and this solution (supposedly eliminating the too many tunnels) induces > pinball routing! Is this what is meant? OH, another confusing sentence structure! "solution" in the second statement should refer to "a solution with no nested tunnel optimization". I will restructure the paragraphs. > > > On the other hand, with a Nested Tunnel Optimization, we would have > > at most one bi-directional tunnel outside the Mobile Network > > Partially agree. It is possible to have such a NT Optimization and > haveat most zero (instead of one) tunnels, at least within an > aggregation of moving networks. Zero-encapsulation RO for nested NEMO. > Zero encapsulation? That looks like a full RO solution. The idea of nested tunnel optimization is to eliminate the effect of nesting, so that the end result is as though there was no nesting. If there was no nesting, that basic NEMO will result in one tunnel. Furthermore, the text uses the words "at most one", which includes any solution that can reduce the number of tunnels to zero. > > The Reverse Routing Header (RRH) approach avoids the multiple > > encapsulation > > Depends what you call encapsulation. RRH, and any routing header for > that matter, is already a form of encapsulation because it adds data > fields to a pure base header. Of course, multiple encapsulation by > adding multiple 40byte base headers is worse than multiple encapsulation > by adding only 16byte addresses, but still, one can't say RRH is > avoiding multiple encapsulation. > I understand what you are driving at, but I wasn't aware that it is the common understanding among IETF folks that routing header is treated as a form of encapsulation. We would change the wordings if it is the common understanding that routing header is treated as a form of encapsulation, but AFAIK, most would not treat it that way. > > Although optimization within a mobile network is not within the > > charter of the NEMO working group, it might be insightful to discuss > > such optimizations. > > Optimization within a moving network is as much in the NEMO charter as > optimization outside of it: define the problem. Agreed, the problem should be defined first, before we decide if it was in the charter or not. > > > These approaches are generally difficult to secure unless all the > > Mobile Routers and Visiting Mobile Node belong to a same > > administrative domain and share predefined Security Associations. > > > Finally something to which I agree wholehartedly. Something to which > can be added "true if no widely deployed security infrastructure". > ok. > > 1. Binding Update storm > > Is this stormy or more windy? Because I know a paper simulating this > stuff and finding it to be more windy. Could you provide details to the paper? Anyway I suspect this is just a question of metaphor ... > > > 4. Missing BU > > > > If a CN doesn't receive the full set of PSBU sent by the MR, it will > > not be able to infer the full path to a node inside the nested Mobile > > Network. The RH will be incomplete and the packet may or may not be > > delivered. > > > Ok but don't try to make the BU-BAck exchanges any more reliable than > currently is. > > > 6.3 Mobile Access router selection > > Remove this. This is CARD. This is specified, Seamoby is closed. > > > 6.5 Multihoming stuff > > Remove this, it's not required by this charter item. > > > 6.5 Mobility Transparency > > Remove this, it's not required by this charter item. > > However, the effects of some nodes being NEMO-aware is required and this > section has discussion about this. So maybe write a new section keeping > those. > > > 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, > > What is a "MR-LFN dichotomy"? good question! I don't know myself ... From nemo-bounces@ietf.org Mon Oct 4 02:45:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03462 for ; Mon, 4 Oct 2004 02:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMTW-0001WJ-B3; Mon, 04 Oct 2004 02:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMQI-00011J-PH for nemo@megatron.ietf.org; Mon, 04 Oct 2004 02:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02208 for ; Mon, 4 Oct 2004 02:34:13 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMZJ-0003Io-HD for nemo@ietf.org; Mon, 04 Oct 2004 02:43:34 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i946V5jG023761; Mon, 4 Oct 2004 14:31:05 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 7F627B240CD; Mon, 4 Oct 2004 14:37:43 +0800 (SGT) Subject: Re: [nemo] RO Taxonomy From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <415BFBD6.9000701@motorola.com> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096871862.9209.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 14:37:43 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Alex, thanks for mapping the draft against the charter. It is very beneficial, as often authors (at least myself) got carried away and deviates from the charter. On Thu, 2004-09-30 at 20:28, Alexandru Petrescu wrote: > The Charter item does not require for an RO Taxonomy (classification). > It requires for a problem definition first so let's define the problem. > > Chan-Wah Ng wrote: > > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ro-taxonomy-02.txt > > > > > The respective charter item is the following: > > > An informational document which specifies a detailed problem > > statement for route optimization and looks at various approaches to > > solving this problem. > > So: first describe the problem. The problem is that paths are > artificially long. They are longer than if MIP6 were not used. The > problem is worse than with Mobile IPv6 for hosts because multiple HA's > are involved (MIP6 for hosts involves "triangular" paths, MIP6 for > routers involves "multi-angular" paths). Your "Pinball" routing is your > figurative way of understanding my "multi-angular" routing. I suggest > the latter term for the terminology document. We will be consistent with the terminology draft. > > The NEMO RO problem is not the same as the multiple encapsulation > problem. The too-big-packets-because-too-many-headers problem has > solutions like compress-those-headers aka ROHC. It may be that a NEMO > RO solution reduces the headers size too but that's only a side effect. > Solving the NEMO RO problem should at least reduce the path lengths but > it is not requiring to reduce the packet sizes. Yes, multiple encapsulation increases packet size is not the core problem. But it is still a problem. It does not matter if a solution already exists (eg ROHC). And the job of the WG charter item is to analyse the problem. > > The charter does not require to define Mobility Transparency either, > while the draft does it in three versions. > The charter does not require the WG item "not to mention Mobility Transparency" either. > The charter does not require dealing with multi-homing and NEMO RO, the > draft deals. > > > This document will look into the issues and tradeoffs involved in > > making the network's movement visible to some nodes, by optionally > > making them "NEMO aware". > > The draft describes (in section Mobility transparency and RO) how some > nodes are NEMO-aware. That's ok and needed. But I don't see the good > description satisfying the charter. > Agreed, we will re-work the section. > First, "end-to-end" principle is mentioned, should have the reference. > I don't understand how not passing mobility from MR to CN breaks the e2e > principle. > > Second, having nodes that are NEMO-aware is used as a solution to > achieve "mobility transparency". The charter does not require "mobility > transparency". It requires a description of the issues and tradeoffs > involved making the network's movement visible to some nodes, > NEMO-aware. Id' better write it like this: > > "In order to develop a solution for the problem describe in this > document, it might be needed that some nodes become NEMO aware. The CN > may be required to interpret bindings between a full address and a > partial prefix (instead of between 2 full addresses). The advantage of > this is that it may help achieve RO for all LFN's under MR but the > tradeoffs are: (1) successful attackers may reroute traffic of an entire > prefix (2) it is difficult to use RR tests for all addresses within a > prefix." > > This would be the idea how to write it, but more detailed it should be. > Thanks for the suggested text. > > The interaction between route optimization and IP routing will also > > be described in this document. > > So it should. > > > Furthermore, security considerations for the various approaches will > > also be considered. > > So it should. > agreed. /rgds /cwng From nemo-bounces@ietf.org Mon Oct 4 03:00:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05285 for ; Mon, 4 Oct 2004 03:00:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMoN-0004k4-Q2; Mon, 04 Oct 2004 02:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMmz-0004Jb-MM for nemo@megatron.ietf.org; Mon, 04 Oct 2004 02:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04895 for ; Mon, 4 Oct 2004 02:57:39 -0400 (EDT) Received: from amsterdam.ucdavis.edu ([169.237.104.160]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMw1-0004rI-CB for nemo@ietf.org; Mon, 04 Oct 2004 03:07:01 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by amsterdam.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i946vaKI001333; Sun, 3 Oct 2004 23:57:36 -0700 (PDT) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i946va90025910; Sun, 3 Oct 2004 23:57:36 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id i946vZNX025909; Sun, 3 Oct 2004 23:57:35 -0700 (PDT) Date: Sun, 3 Oct 2004 23:57:35 -0700 (PDT) Message-Id: <200410040657.i946vZNX025909@tremex.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [nemo] NEMO RO Problem X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, I wrote a document about NEMO RO problem, please click the following link to see the details: http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc This document benefits from a lot of discussions and drafts. It is still a preliminary version, so there are still a lot of questions. For example, Alex said that the charter does not requires dealing with multi-homing and NEMO RO. IMO, the requirement that RO solution should function for multi-homing NEMO networks and should not conflict with multi-homing mechanism seems OK. We may also take a stepwise approach to solve multi-homing and RO issues. Thanks for your comments. Sincerely, fan From nemo-bounces@ietf.org Mon Oct 4 04:18:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10515 for ; Mon, 4 Oct 2004 04:18:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENy3-0006x2-Kw; Mon, 04 Oct 2004 04:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDOwT-00053Z-3R for nemo@megatron.ietf.org; Fri, 01 Oct 2004 11:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07356 for ; Fri, 1 Oct 2004 11:03:27 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.203] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDP4v-0000bd-N5 for nemo@ietf.org; Fri, 01 Oct 2004 11:12:14 -0400 Received: by mproxy.gmail.com with SMTP id 75so640594rnk for ; Fri, 01 Oct 2004 08:03:17 -0700 (PDT) Received: by 10.38.59.51 with SMTP id h51mr3585916rna; Fri, 01 Oct 2004 08:03:17 -0700 (PDT) Received: by 10.38.76.41 with HTTP; Fri, 1 Oct 2004 08:03:17 -0700 (PDT) Message-ID: Date: Fri, 1 Oct 2004 23:03:17 +0800 From: Fred Lin To: nemo@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Oct 2004 04:13:08 -0400 Subject: [nemo] Question: m flag in NEMO Basic Support X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fred Lin List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi : I just start the nemo draft study and found something strange in NEMO Basic Support draft03 page 8, 4-1 Binding Update. Instead of flags |A|H|L|K|Res in RFC 3775, The flag is |A|H|L|K|M|R|Res . There are two new flags (M,R) in the header, but only Router flag(R) were mentioned in draft. I wonder to know why there's no description about M flag? Or had this flag been predefined by other draft? regards From nemo-bounces@ietf.org Mon Oct 4 04:35:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11709 for ; Mon, 4 Oct 2004 04:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOFB-0001O6-Ln; Mon, 04 Oct 2004 04:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEO8s-0000MV-Jo for nemo@megatron.ietf.org; Mon, 04 Oct 2004 04:24:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10843 for ; Mon, 4 Oct 2004 04:24:20 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOHu-0006ir-2e for nemo@ietf.org; Mon, 04 Oct 2004 04:33:43 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id i948QRxJ019631; Mon, 4 Oct 2004 01:26:27 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i946NteI030912; Mon, 4 Oct 2004 01:23:56 -0500 Message-ID: <416108A6.6030804@motorola.com> Date: Mon, 04 Oct 2004 10:24:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Lin Subject: Re: [nemo] Question: m flag in NEMO Basic Support References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig994491EB87689BADE7994EFF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig994491EB87689BADE7994EFF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fred Lin wrote: > Hi : > > I just start the nemo draft study and found something strange in NEMO > Basic Support draft03 page 8, 4-1 Binding Update. > > Instead of flags |A|H|L|K|Res in RFC 3775, The flag is > |A|H|L|K|M|R|Res . There are two new flags (M,R) in the header, but > only Router flag(R) were mentioned in draft. I wonder to know why > there's no description about M flag? Or had this flag been predefined > by other draft? Hi Fred, if I remember correctly the M flag is used by HMIPv6 to indicate a MAP registration - the document is now addressing the IESG comments, check the MIPSHOP Working Group. Alex --------------enig994491EB87689BADE7994EFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYQisMmC0w56zj54RAtuXAJ0b63nxsqOfat1yUMcn38VQBl5SkACg85Of dmW6Kz7vpoCxmSC+BJAc+so= =yL06 -----END PGP SIGNATURE----- --------------enig994491EB87689BADE7994EFF-- From nemo-bounces@ietf.org Mon Oct 4 04:50:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13412 for ; Mon, 4 Oct 2004 04:50:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEONw-0002aD-Qi; Mon, 04 Oct 2004 04:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOH9-0001eV-PK for nemo@megatron.ietf.org; Mon, 04 Oct 2004 04:32:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11494 for ; Mon, 4 Oct 2004 04:32:52 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOQ7-0007VO-V5 for nemo@ietf.org; Mon, 04 Oct 2004 04:42:16 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i948Ta3Q028124; Mon, 4 Oct 2004 16:29:36 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id BD75DB240CD; Mon, 4 Oct 2004 16:36:14 +0800 (SGT) Subject: Re: [nemo] Question: m flag in NEMO Basic Support From: Chan-Wah Ng To: Fred Lin In-Reply-To: References: Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096878974.9194.78.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 16:36:14 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Fred, On Fri, 2004-10-01 at 23:03, Fred Lin wrote: > Hi : > > I just start the nemo draft study and found something strange in NEMO > Basic Support draft03 page 8, 4-1 Binding Update. > > Instead of flags |A|H|L|K|Res in RFC 3775, The flag is |A|H|L|K|M|R|Res . > There are two new flags (M,R) in the header, but only Router flag(R) > were mentioned in draft. > I wonder to know why there's no description about M flag? Or had this > flag been predefined by other draft? > Yes, HMIP. See http://www.ietf.org/internet-drafts/draft-ietf-mipshop-hmipv6-02.txt /rgds /cwng From nemo-bounces@ietf.org Mon Oct 4 06:19:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20044 for ; Mon, 4 Oct 2004 06:19:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPqT-00079j-Fo; Mon, 04 Oct 2004 06:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPix-0005RT-Tf for nemo@megatron.ietf.org; Mon, 04 Oct 2004 06:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19220 for ; Mon, 4 Oct 2004 06:05:40 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPs1-0001O9-Bj for nemo@ietf.org; Mon, 04 Oct 2004 06:15:05 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i94A6kdO008965; Mon, 4 Oct 2004 03:06:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i94A5Lot005924; Mon, 4 Oct 2004 05:05:22 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 147958659B3; Mon, 4 Oct 2004 12:05:37 +0200 (CEST) Message-ID: <4161206B.4070808@motorola.com> Date: Mon, 04 Oct 2004 12:05:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] RO Taxonomy References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> In-Reply-To: <1096871862.9209.76.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00C4C1D89DA72BA7489AB80E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00C4C1D89DA72BA7489AB80E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >> The NEMO RO problem is not the same as the multiple encapsulation >> problem. The too-big-packets-because-too-many-headers problem has >> solutions like compress-those-headers aka ROHC. It may be that a >> NEMO RO solution reduces the headers size too but that's only a >> side effect. Solving the NEMO RO problem should at least reduce the >> path lengths but it is not requiring to reduce the packet sizes. > > Yes, multiple encapsulation increases packet size is not the core > problem. But it is still a problem. It does not matter if a > solution already exists (eg ROHC). And the job of the WG charter > item is to analyse the problem. Yes, it would be interesting to give a conclusion like: fragmentation starts when 3 levels of nestedness all using Ethernet MTU 1280, for data packets; for signalling, fragmentation starts at 10 levels. >> The charter does not require to define Mobility Transparency >> either, while the draft does it in three versions. > > The charter does not require the WG item "not to mention Mobility > Transparency" either. :-) Migration transparency, performance transparency, network mobility support transparency and operational transparency - are all requirements in the NEMO requirements/goals document. The statements in the taxonomy draft about mobility transparency are, in fact, relaxing the transparency requirements of the requirements/goals draft, was this the intention? Alex --------------enig00C4C1D89DA72BA7489AB80E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYSBwMmC0w56zj54RAoyTAJ9R18qOlYW6F8G02s7HyGRQeqRACgCgn117 KHJCAd3vlU7gmnb/zUQHpiI= =g8+e -----END PGP SIGNATURE----- --------------enig00C4C1D89DA72BA7489AB80E-- From nemo-bounces@ietf.org Mon Oct 4 06:36:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21331 for ; Mon, 4 Oct 2004 06:36:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ1U-0001QU-7j; Mon, 04 Oct 2004 06:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPzQ-00014D-NT for nemo@megatron.ietf.org; Mon, 04 Oct 2004 06:22:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20291 for ; Mon, 4 Oct 2004 06:22:41 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQ8T-00052l-Gq for nemo@ietf.org; Mon, 04 Oct 2004 06:32:06 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i94AJYq9001771; Mon, 4 Oct 2004 18:19:34 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 1BE13B240CD; Mon, 4 Oct 2004 18:26:12 +0800 (SGT) Subject: Re: [nemo] RO Taxonomy From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4161206B.4070808@motorola.com> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096885571.9209.96.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 18:26:11 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2004-10-04 at 18:05, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > >> The NEMO RO problem is not the same as the multiple encapsulation > >> problem. The too-big-packets-because-too-many-headers problem has > >> solutions like compress-those-headers aka ROHC. It may be that a > >> NEMO RO solution reduces the headers size too but that's only a > >> side effect. Solving the NEMO RO problem should at least reduce the > >> path lengths but it is not requiring to reduce the packet sizes. > > > > Yes, multiple encapsulation increases packet size is not the core > > problem. But it is still a problem. It does not matter if a > > solution already exists (eg ROHC). And the job of the WG charter > > item is to analyse the problem. > > Yes, it would be interesting to give a conclusion like: fragmentation > starts when 3 levels of nestedness all using Ethernet MTU 1280, for data > packets; for signalling, fragmentation starts at 10 levels. > :), that's a bit extreme, but I know what you are trying to point out. In the next version, I promise I'll do my best not to make the text sounds as if increased packet size is a significant problem. But I would definitely mention it as a consequence of nested NEMO. > >> The charter does not require to define Mobility Transparency > >> either, while the draft does it in three versions. > > > > The charter does not require the WG item "not to mention Mobility > > Transparency" either. > > :-) > > Migration transparency, performance transparency, network mobility > support transparency and operational transparency - are all requirements > in the NEMO requirements/goals document. > May I politely point out that they are requirements for NEMO Basic Support... or am I mistaken? > The statements in the taxonomy draft about mobility transparency are, in > fact, relaxing the transparency requirements of the requirements/goals > draft, was this the intention? > Nope, at least that wasn't my interpretation when I read/write (sorry don't really recall who wrote that text) the paragraph. The text about mobility transparency is mainly to discuss that in achieving RO, it might be necessary to have some nodes be RO-aware, eg CN (as you've highlighted in another fork of this thread). /rgds /cwng From nemo-bounces@ietf.org Mon Oct 4 06:45:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22082 for ; Mon, 4 Oct 2004 06:45:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQDR-0005cb-Hb; Mon, 04 Oct 2004 06:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ8p-0004Lj-So for nemo@megatron.ietf.org; Mon, 04 Oct 2004 06:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20853 for ; Mon, 4 Oct 2004 06:32:24 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQHt-0006g8-En for nemo@ietf.org; Mon, 04 Oct 2004 06:41:49 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i94AX42L023847; Mon, 4 Oct 2004 03:33:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i948W4eI011627; Mon, 4 Oct 2004 03:32:05 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D6FF98659B3; Mon, 4 Oct 2004 12:32:22 +0200 (CEST) Message-ID: <416126B0.4000500@motorola.com> Date: Mon, 04 Oct 2004 12:32:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> In-Reply-To: <1096870913.9192.62.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC8434B95C1184244DE93C7C" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC8434B95C1184244DE93C7C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >>> A major issue with this form of optimization is that the >>> end-to-end principle of the MIPv6 Reverse Routability (RR) test >>> is broken. >> >> What is the "e2e principle of the MIPv6 RR test(s)"? RFC 3775 >> Mobile IPv6 has no such principle... RFC 3775 Mobile IPv6 has >> another end-to-end mentioning of end-to-end IPsec, but it is not an >> end-to-end RR. >> >> So the reader is not convinced this is a "major issue"; and also >> it's called Return not Reverse. > > Agreed to your objection in the use of the term 'e2e'. But it is > still a major issue. Until I don't know what the e2e principle of the MIPv6 RR test is, I can not say whether that form of optimization is an issue or not (and even less of being 'major'). For example, maybe the e2e principle of the MIPv6 RR test states that only same-layer ends can address each other, but different-layer ends can not address each other; if that principle says so, then that form of optimization does not break that principle: MR's IP-layer talks to CN's IP-layer and LFN's app-layer talks to CN's app-layer. So no problem, no issue, and no need of an issue to that problem. >> What's "triangular routing" by the way? Is it that all 3 edges are >> used to send packets? Is it that only two edges are used so? (a >> prior version of MIP6 was wrongly using sending packets MN-CN and >> receiving CN-HA-MN, so that was "triangular"; current MIP6 w/o RO >> is bi-angular path because there's no CN-MN path and there's CN-HA >> and HA-MN). >> > Agreed. I think the use of the term "triangular routing" was largely > (and I admit wrongly) based on historical usage of the term to > describe the suboptimal routing problem (I think dated as far back to > MIPv4). Does the MIPv4 RFC define "triangular routing" somehow? >>> In this model, both the LFN behind the MR and the Correspondent >>> can be MIP agnostic. >> >> The CN can not be MIP agnostic because RFC 3775 requires it to be a >> MIP believer. The CN may be NEMO-agnostic, and not be NEMO-aware. > > I agree to change "MIP" to "NEMO", but the reason you gave I > disagree. RFC3775 defines "CN to be a peer node with which a mobile > node is communicating". It makes no assumption whether CN is > MIP-aware or not. Ok, I think that's right. >>> On the other hand, with a Nested Tunnel Optimization, we would >>> have at most one bi-directional tunnel outside the Mobile Network >>> >> >> Partially agree. It is possible to have such a NT Optimization and >> haveat most zero (instead of one) tunnels, at least within an >> aggregation of moving networks. Zero-encapsulation RO for nested >> NEMO. > > Zero encapsulation? That looks like a full RO solution. The idea of > nested tunnel optimization is to eliminate the effect of nesting, so > that the end result is as though there was no nesting. If there was > no nesting, that basic NEMO will result in one tunnel. One-tunnel? For MIP6 for hosts, after RR, there's no tunnel at all. > Furthermore, the text uses the words "at most one", which includes > any solution that can reduce the number of tunnels to zero. Right. >>> The Reverse Routing Header (RRH) approach avoids the multiple >>> encapsulation >> >> Depends what you call encapsulation. RRH, and any routing header >> for that matter, is already a form of encapsulation because it adds >> data fields to a pure base header. Of course, multiple >> encapsulation by adding multiple 40byte base headers is worse than >> multiple encapsulation by adding only 16byte addresses, but still, >> one can't say RRH is avoiding multiple encapsulation. >> > I understand what you are driving at, but I wasn't aware that it is > the common understanding among IETF folks that routing header is > treated as a form of encapsulation. We would change the wordings if > it is the common understanding that routing header is treated as a > form of encapsulation, but AFAIK, most would not treat it that way. Ok, I see what you mean. Let me put it this way: without MIP6 there's no additional data added to all application-level IPv6 packet (the encapsulating headers or the routing headers). With MIP6 there is. One can say that routing headers involve less of this overhead data (less than encapsulating base and IPsec headers), but it's still overhead. Wouldn't it be possible to have a sort of NEMO-RR after whose completion there's no encapsulating header, no routing header? I bet this is part of the solution space to the problem you're trying to define. >>> Although optimization within a mobile network is not within the >>> charter of the NEMO working group, it might be insightful to >>> discuss such optimizations. >> >> Optimization within a moving network is as much in the NEMO charter >> as optimization outside of it: define the problem. > > Agreed, the problem should be defined first, before we decide if it > was in the charter or not. I wanted to say that the RO problem for NEMO should define the RO problem within the nested aggregation too (not only outside of it). >> Is this stormy or more windy? Because I know a paper simulating >> this stuff and finding it to be more windy. > > Could you provide details to the paper? Anyway I suspect this is > just a question of metaphor ... Don't have it handy. Do you have a paper quantifying that being stormy? If one is sure that the BU storm is more windy than stormy then one does not consider it as a problem, metaphorically speaking. Alex --------------enigBC8434B95C1184244DE93C7C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYSa2MmC0w56zj54RAlxbAJ4yOV3dFX8OZfpL+Xi9hRFMYbgGVgCg0G4p fBOF6RabHb6Kib5726DNhEs= =pmcj -----END PGP SIGNATURE----- --------------enigBC8434B95C1184244DE93C7C-- From nemo-bounces@ietf.org Mon Oct 4 07:03:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23473 for ; Mon, 4 Oct 2004 07:03:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQR2-0007eT-Su; Mon, 04 Oct 2004 06:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQM8-00075H-P3 for nemo@megatron.ietf.org; Mon, 04 Oct 2004 06:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22120 for ; Mon, 4 Oct 2004 06:46:09 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQVC-0000ZF-Po for nemo@ietf.org; Mon, 04 Oct 2004 06:55:35 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i94AlPDx027386; Mon, 4 Oct 2004 03:47:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i94Ak7s6028366; Mon, 4 Oct 2004 05:46:07 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F2CEE8659B3; Mon, 4 Oct 2004 12:46:06 +0200 (CEST) Message-ID: <416129E9.6070008@motorola.com> Date: Mon, 04 Oct 2004 12:46:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] RO Taxonomy References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> <1096885571.9209.96.camel@localhost> In-Reply-To: <1096885571.9209.96.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig405D7D65C590E08BA825A4F0" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig405D7D65C590E08BA825A4F0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >> Yes, it would be interesting to give a conclusion like: >> fragmentation starts when 3 levels of nestedness all using Ethernet >> MTU 1280, for data packets; for signalling, fragmentation starts at >> 10 levels. >> > :), that's a bit extreme, but I know what you are trying to point > out. Sorry, what do you find to be extreme? 10 levels threshold before fragmentation for signalling is too much? Or using explicit numbers is extreme? Sorry... > In the next version, I promise I'll do my best not to make the text > sounds as if increased packet size is a significant problem. But I > would definitely mention it as a consequence of nested NEMO. Yes and can we have more discussion before modifying text? I don't think it's yet time to modify text. There's already much text around: three problem statements drafts. >>>> The charter does not require to define Mobility Transparency >>>> either, while the draft does it in three versions. >>> >>> The charter does not require the WG item "not to mention Mobility >>> Transparency" either. >> >> :-) >> >> Migration transparency, performance transparency, network mobility >> support transparency and operational transparency - are all >> requirements in the NEMO requirements/goals document. >> > > May I politely point out that they are requirements for NEMO Basic > Support... Absolutely! Yes, you're right, they're requirements for the NEMO Basic Support, which were changed to become more "goals". I wanted to learn how do you see the "mobility transparency" term with respect to the other "x transparency" terms in the NEMO goals document. >> The statements in the taxonomy draft about mobility transparency >> are, in fact, relaxing the transparency requirements of the >> requirements/goals draft, was this the intention? >> > > Nope, at least that wasn't my interpretation when I read/write (sorry > don't really recall who wrote that text) the paragraph. The text > about mobility transparency is mainly to discuss that in achieving > RO, it might be necessary to have some nodes be RO-aware, eg CN (as > you've highlighted in another fork of this thread). Yes. So why not titling such a discussion with "The Need for RO-aware Nodes". In my oppinion it is not because mobility should be transparent that we need RO-aware nodes. If one leaves place for such a light interpretation of why RO is needed then _any_ other argument would apparently play in its favor. For example: we need RO-aware nodes because handovers should be fast, we need RO-aware nodes because Internet should be end-2-end and so on. Those are all bogus arguments to me, they all lack concreteness. Metaphoring has its risks :-) Alex --------------enig405D7D65C590E08BA825A4F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYSnuMmC0w56zj54RAlvAAJ9pJsTqX9cNPdtRnMNruRvqr0RlFgCfUIJY XFc+dkfxWRNTM6APWv09pPY= =tXKL -----END PGP SIGNATURE----- --------------enig405D7D65C590E08BA825A4F0-- From nemo-bounces@ietf.org Tue Oct 5 00:20:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29952 for ; Tue, 5 Oct 2004 00:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEgiB-0005Vs-D4; Tue, 05 Oct 2004 00:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEgfW-0004TQ-Ix for nemo@megatron.ietf.org; Tue, 05 Oct 2004 00:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29076 for ; Tue, 5 Oct 2004 00:11:14 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEgoj-00064e-5v for nemo@ietf.org; Tue, 05 Oct 2004 00:20:49 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A57874C0B4 for ; Tue, 5 Oct 2004 13:10:26 +0900 (JST) Date: Tue, 5 Oct 2004 13:12:43 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RO Taxonomy Message-Id: <20041005131243.498ddc79.ernst@sfc.wide.ad.jp> In-Reply-To: <416129E9.6070008@motorola.com> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> <1096885571.9209.96.camel@localhost> <416129E9.6070008@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, > >> Migration transparency, performance transparency, network mobility > >> support transparency and operational transparency - are all > >> requirements in the NEMO requirements/goals document. > >> > > > > May I politely point out that they are requirements for NEMO Basic > > Support... > > Absolutely! Yes, you're right, they're requirements for the NEMO Basic > Support, which were changed to become more "goals". Well, not exactly. draft-ietf-nemo-requirements is about "Goals and Requirements". Section 4 is about "design goals" for both Basic and Extended, i.e. what is **desirable** to achieve (but which might not be possible, with limited effort). Section 5, on the other hand, is about **requirements** for NEMO Basic Support. It served as the basement of draft-ietf-nemo-basic-support. > I wanted to learn how do you see the "mobility transparency" term with > respect to the other "x transparency" terms in the NEMO goals document. > >> The statements in the taxonomy draft about mobility transparency > >> are, in fact, relaxing the transparency requirements of the > >> requirements/goals draft, was this the intention? > >> > > > > Nope, at least that wasn't my interpretation when I read/write (sorry > > don't really recall who wrote that text) the paragraph. The text > > about mobility transparency is mainly to discuss that in achieving > > RO, it might be necessary to have some nodes be RO-aware, eg CN (as > > you've highlighted in another fork of this thread). > > Yes. So why not titling such a discussion with "The Need for RO-aware > Nodes". In my oppinion it is not because mobility should be transparent > that we need RO-aware nodes. If one leaves place for such a light > interpretation of why RO is needed then _any_ other argument would > apparently play in its favor. For example: we need RO-aware nodes > because handovers should be fast, we need RO-aware nodes because > Internet should be end-2-end and so on. Those are all bogus arguments > to me, they all lack concreteness. Metaphoring has its risks :-) I kind of agree with Alex. On the other hand, I think it's extremely difficult to decide if we need RO-aware nodes or not without looking into the solutions. I think what we should do is definitely using "RO-aware nodes ?" as a metric to evaluate the many solutions, after the problem statement is issued. So, the discussion about the "need" could be left off after the document is issued and the existing solutions are analysed. Thierry. From nemo-bounces@ietf.org Tue Oct 5 01:40:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05050 for ; Tue, 5 Oct 2004 01:40:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEi2N-0002fV-Dq; Tue, 05 Oct 2004 01:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEhyt-000237-NW for nemo@megatron.ietf.org; Tue, 05 Oct 2004 01:35:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04669 for ; Tue, 5 Oct 2004 01:35:22 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEi86-00048a-O8 for nemo@ietf.org; Tue, 05 Oct 2004 01:44:55 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i955WD6D023055; Tue, 5 Oct 2004 13:32:13 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 852A4B240CD; Tue, 5 Oct 2004 13:38:49 +0800 (SGT) Subject: Re: [nemo] RO Taxonomy From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20041005131243.498ddc79.ernst@sfc.wide.ad.jp> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> <1096885571.9209.96.camel@localhost> <416129E9.6070008@motorola.com> <20041005131243.498ddc79.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096954728.5491.60.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 05 Oct 2004 13:38:48 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2004-10-05 at 12:12, Thierry Ernst wrote: > Hi, > > > >> The statements in the taxonomy draft about mobility transparency > > >> are, in fact, relaxing the transparency requirements of the > > >> requirements/goals draft, was this the intention? > > >> > > > > > > Nope, at least that wasn't my interpretation when I read/write (sorry > > > don't really recall who wrote that text) the paragraph. The text > > > about mobility transparency is mainly to discuss that in achieving > > > RO, it might be necessary to have some nodes be RO-aware, eg CN (as > > > you've highlighted in another fork of this thread). > > > > Yes. So why not titling such a discussion with "The Need for RO-aware > > Nodes". In my oppinion it is not because mobility should be transparent > > that we need RO-aware nodes. If one leaves place for such a light > > interpretation of why RO is needed then _any_ other argument would > > apparently play in its favor. For example: we need RO-aware nodes > > because handovers should be fast, we need RO-aware nodes because > > Internet should be end-2-end and so on. Those are all bogus arguments > > to me, they all lack concreteness. Metaphoring has its risks :-) > > I kind of agree with Alex. On the other hand, I think it's extremely > difficult to decide if we need RO-aware nodes or not without looking > into the solutions. > Agreed. > I think what we should do is definitely using "RO-aware nodes ?" as a > metric to evaluate the many solutions, after the problem statement is > issued. > > So, the discussion about the "need" could be left off after the document > is issued and the existing solutions are analysed. > Agreed. /rgds /cwng From nemo-bounces@ietf.org Tue Oct 5 02:12:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19112 for ; Tue, 5 Oct 2004 02:12:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEiWh-0001nb-F5; Tue, 05 Oct 2004 02:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEiTH-0000vA-4B for nemo@megatron.ietf.org; Tue, 05 Oct 2004 02:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13493 for ; Tue, 5 Oct 2004 02:06:46 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEicU-0001fx-PV for nemo@ietf.org; Tue, 05 Oct 2004 02:16:19 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9563dDG024421; Tue, 5 Oct 2004 14:03:39 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 9EA73B240CD; Tue, 5 Oct 2004 14:10:14 +0800 (SGT) Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <416126B0.4000500@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1096956613.5491.92.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 05 Oct 2004 14:10:14 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2004-10-04 at 18:32, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > >>> A major issue with this form of optimization is that the > >>> end-to-end principle of the MIPv6 Reverse Routability (RR) test > >>> is broken. > >> > >> What is the "e2e principle of the MIPv6 RR test(s)"? RFC 3775 > >> Mobile IPv6 has no such principle... RFC 3775 Mobile IPv6 has > >> another end-to-end mentioning of end-to-end IPsec, but it is not an > >> end-to-end RR. > >> > >> So the reader is not convinced this is a "major issue"; and also > >> it's called Return not Reverse. > > > > Agreed to your objection in the use of the term 'e2e'. But it is > > still a major issue. > > Until I don't know what the e2e principle of the MIPv6 RR test is, I can > not say whether that form of optimization is an issue or not (and even > less of being 'major'). For example, maybe the e2e principle of the > MIPv6 RR test states that only same-layer ends can address each other, > but different-layer ends can not address each other; if that principle > says so, then that form of optimization does not break that principle: > MR's IP-layer talks to CN's IP-layer and LFN's app-layer talks to CN's > app-layer. So no problem, no issue, and no need of an issue to that > problem. > I have a, should I say, vague idea about the problem of RR procedure with respect to its application in NEMO-RO. Give me some time to organize my thoughts, and I would return to this with a clearer idea in mind. > >> What's "triangular routing" by the way? Is it that all 3 edges are > >> used to send packets? Is it that only two edges are used so? (a > >> prior version of MIP6 was wrongly using sending packets MN-CN and > >> receiving CN-HA-MN, so that was "triangular"; current MIP6 w/o RO > >> is bi-angular path because there's no CN-MN path and there's CN-HA > >> and HA-MN). > >> > > Agreed. I think the use of the term "triangular routing" was largely > > (and I admit wrongly) based on historical usage of the term to > > describe the suboptimal routing problem (I think dated as far back to > > MIPv4). > > Does the MIPv4 RFC define "triangular routing" somehow? > Not that I recall, but I remember the term triangular routing refers to the sending of packets from FA to CN, and the return path of CN->HA->FA (thus forming the triangle). That is the time when the issue of ingress filtering was not that obvious/significant. > >>> On the other hand, with a Nested Tunnel Optimization, we would > >>> have at most one bi-directional tunnel outside the Mobile Network > >>> > >> > >> Partially agree. It is possible to have such a NT Optimization and > >> haveat most zero (instead of one) tunnels, at least within an > >> aggregation of moving networks. Zero-encapsulation RO for nested > >> NEMO. > > > > Zero encapsulation? That looks like a full RO solution. The idea of > > nested tunnel optimization is to eliminate the effect of nesting, so > > that the end result is as though there was no nesting. If there was > > no nesting, that basic NEMO will result in one tunnel. > > One-tunnel? For MIP6 for hosts, after RR, there's no tunnel at all. We are talking about nested tunnel optimization, so by your reference to MIPv6 for host, I presume you have the VMN behind a MR in mind. Even with MIPv6 RO (with RR completed), there is still a tunnel between MR and HA-of-MR. With nested tunnel optimization, assuming the solution can be extended to MIPv6 hosts, it is possible to have zero or one encapsulation. It depends on the solution. A solution can either result in a direct routing over MR (by means of an extended routing header or otherwise), which would then result in zero encapsulation (for simplicity, we don't treat routing headers as encapsulation). Alternatively, another solution might result in a tunnel established between MR and the CN. Then there is one level of encapsulation. > > > Furthermore, the text uses the words "at most one", which includes > > any solution that can reduce the number of tunnels to zero. > > Right. > > >>> The Reverse Routing Header (RRH) approach avoids the multiple > >>> encapsulation > >> > >> Depends what you call encapsulation. RRH, and any routing header > >> for that matter, is already a form of encapsulation because it adds > >> data fields to a pure base header. Of course, multiple > >> encapsulation by adding multiple 40byte base headers is worse than > >> multiple encapsulation by adding only 16byte addresses, but still, > >> one can't say RRH is avoiding multiple encapsulation. > >> > > I understand what you are driving at, but I wasn't aware that it is > > the common understanding among IETF folks that routing header is > > treated as a form of encapsulation. We would change the wordings if > > it is the common understanding that routing header is treated as a > > form of encapsulation, but AFAIK, most would not treat it that way. > > Ok, I see what you mean. Let me put it this way: without MIP6 there's > no additional data added to all application-level IPv6 packet (the > encapsulating headers or the routing headers). With MIP6 there is. One > can say that routing headers involve less of this overhead data (less > than encapsulating base and IPsec headers), but it's still overhead. > > Wouldn't it be possible to have a sort of NEMO-RR after whose completion > there's no encapsulating header, no routing header? I bet this is part > of the solution space to the problem you're trying to define. > That would be very difficult to achieve. By your definition of overheads, a home-address destination option would also constitute as an overhead. I don't see how a NEMO-RO solution can hope to achieve zero overhead, except perhaps using an entirely and drastically different routing infrastructure. I remember coming across Motorola's solution of using multicast addressing to achieve RO. That might be one approach to achieve zero overhead ... or maybe not zero, but minimal, since some overheads will be required to map that multicast address to the home-address of the mobile node (VMN, LMN, or LFN). > >>> Although optimization within a mobile network is not within the > >>> charter of the NEMO working group, it might be insightful to > >>> discuss such optimizations. > >> > >> Optimization within a moving network is as much in the NEMO charter > >> as optimization outside of it: define the problem. > > > > Agreed, the problem should be defined first, before we decide if it > > was in the charter or not. > > I wanted to say that the RO problem for NEMO should define the RO > problem within the nested aggregation too (not only outside of it). > > >> Is this stormy or more windy? Because I know a paper simulating > >> this stuff and finding it to be more windy. > > > > Could you provide details to the paper? Anyway I suspect this is > > just a question of metaphor ... > > Don't have it handy. Do you have a paper quantifying that being stormy? > Nope, but let's do a bit of thought experiment. If you are looking at the NEMO being a W-PAN or a car network, it might not even be windy at all! Perhaps only a little breezy, so to speak. ;) However expand that little W-PAN or car network to a train with hundreds of VMN. IF every change in point of attachment of such a large NEMO must be accompanied with one BU per CN, we can expect 100 BUs after a change in point of attachment. Is that stormy? Now add in the BAcks, and perhaps even RR messages. Is that stormy? > If one is sure that the BU storm is more windy than stormy then one does > not consider it as a problem, metaphorically speaking. > I suspect the differentiation of stormy and windy is itself subjective enough. Whats makes stormy stormy? 100 packets per sec? A thousand packets per second? Or a million? It also depends on the scale of the NEMO. In the worst cases, we assume an entire mass transport vehicle is the NEMO, and any breeze would scaled to a hurricane. On the other hand, one can quantify the question of stormy/windy by normalizing the number of signalling packets with the number of data packets. Then perhaps we can have scale invariance. I think it make sense to have the draft talk about all these issues. Make sense? /rgds /cwng From nemo-bounces@ietf.org Tue Oct 5 12:41:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12839 for ; Tue, 5 Oct 2004 12:41:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsBQ-0002RQ-Kh; Tue, 05 Oct 2004 12:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEs97-0001sc-7d for nemo@megatron.ietf.org; Tue, 05 Oct 2004 12:26:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11735 for ; Tue, 5 Oct 2004 12:26:34 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEsIO-0003Qg-QM for nemo@ietf.org; Tue, 05 Oct 2004 12:36:15 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i95GQTDV018717; Tue, 5 Oct 2004 09:26:30 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i95EQ87c010513; Tue, 5 Oct 2004 09:26:09 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A6FD18859B1; Tue, 5 Oct 2004 18:26:26 +0200 (CEST) Message-ID: <4162CB2C.60903@motorola.com> Date: Tue, 05 Oct 2004 18:26:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] RO Taxonomy References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> <1096885571.9209.96.camel@localhost> <416129E9.6070008@motorola.com> <20041005131243.498ddc79.ernst@sfc.wide.ad.jp> <1096954728.5491.60.camel@localhost> In-Reply-To: <1096954728.5491.60.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F31985FCA34243CECE513A9" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF NEMO WG , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F31985FCA34243CECE513A9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >>>>>The statements in the taxonomy draft about mobility transparency >>>>>are, in fact, relaxing the transparency requirements of the >>>>>requirements/goals draft, was this the intention? >>>> >>>>Nope, at least that wasn't my interpretation when I read/write (sorry >>>> don't really recall who wrote that text) the paragraph. The text >>>>about mobility transparency is mainly to discuss that in achieving >>>>RO, it might be necessary to have some nodes be RO-aware, eg CN (as >>>>you've highlighted in another fork of this thread). >>> >>>Yes. So why not titling such a discussion with "The Need for RO-aware >>>Nodes". In my oppinion it is not because mobility should be transparent >>>that we need RO-aware nodes. If one leaves place for such a light >>>interpretation of why RO is needed then _any_ other argument would >>>apparently play in its favor. For example: we need RO-aware nodes >>>because handovers should be fast, we need RO-aware nodes because >>>Internet should be end-2-end and so on. Those are all bogus arguments >>>to me, they all lack concreteness. Metaphoring has its risks :-) >> >>I kind of agree with Alex. On the other hand, I think it's extremely >>difficult to decide if we need RO-aware nodes or not without looking >>into the solutions. > > Agreed. > >>I think what we should do is definitely using "RO-aware nodes ?" as a >>metric to evaluate the many solutions, after the problem statement is >>issued. >> >>So, the discussion about the "need" could be left off after the document >>is issued and the existing solutions are analysed. >> > Agreed. I can deduce you agree that the mobility transparency section is not needed? Alex --------------enig7F31985FCA34243CECE513A9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYssyMmC0w56zj54RAoAnAJ9bkHic1GCdNcMphdH67viGTlhpHgCfV/Vs mTsX/JGGRVtFzRuXHvCRSPk= =x40l -----END PGP SIGNATURE----- --------------enig7F31985FCA34243CECE513A9-- From nemo-bounces@ietf.org Tue Oct 5 13:23:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17657 for ; Tue, 5 Oct 2004 13:23:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsue-0002I8-4V; Tue, 05 Oct 2004 13:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEslp-0000Uu-JC for nemo@megatron.ietf.org; Tue, 05 Oct 2004 13:06:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15831 for ; Tue, 5 Oct 2004 13:06:34 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEsv9-0001eT-NT for nemo@ietf.org; Tue, 05 Oct 2004 13:16:16 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i95H7eEj012915; Tue, 5 Oct 2004 10:07:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i95F6C7c030730; Tue, 5 Oct 2004 10:06:13 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CF34D8A3A64; Tue, 5 Oct 2004 19:06:30 +0200 (CEST) Message-ID: <4162D491.5060303@motorola.com> Date: Tue, 05 Oct 2004 19:06:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> In-Reply-To: <1096956613.5491.92.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0E7ADD2F7DB5D490C6D3D0DA" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E7ADD2F7DB5D490C6D3D0DA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > Not that I recall, but I remember the term triangular routing refers > to the sending of packets from FA to CN, and the return path of > CN->HA->FA (thus forming the triangle). That is the time when the > issue of ingress filtering was not that obvious/significant. Yes, MIP4 RFC3344 has Figure 1 that ressembles to a triangle, but the RFC does not contain the string "triang". I am looking for other early definitions of "triangular routing" in an RFC or email discussions or early Internet Drafts. >> Wouldn't it be possible to have a sort of NEMO-RR after whose >> completion there's no encapsulating header, no routing header? I >> bet this is part of the solution space to the problem you're trying >> to define. > > That would be very difficult to achieve. By your definition of > overheads, a home-address destination option would also constitute as > an overhead. I don't see how a NEMO-RO solution can hope to achieve > zero overhead, except perhaps using an entirely and drastically > different routing infrastructure. I agree with the DO containing the HoA means no zero-encapsulation and overhead. I don't see how a NEMO-RO solution can hope to achieve zero overhead with existing routing infrastructure, but I see how a NEMO-RO solution can achieve zero-overhead without the existing (and not any other) infrastructure. That is, if the aggregatation of moving networks is disconnected from the infrastructure, then it is possible to have that zero-overhead, no routing header, no DO. > I remember coming across Motorola's solution of using multicast > addressing to achieve RO. That might be one approach to achieve zero > overhead ... or maybe not zero, but minimal, since some overheads > will be required to map that multicast address to the home-address of > the mobile node (VMN, LMN, or LFN). Ah yes? > Nope, but let's do a bit of thought experiment. If you are looking > at the NEMO being a W-PAN or a car network, it might not even be > windy at all! Perhaps only a little breezy, so to speak. ;) But the number of BU's depend not on the size of the moving network! Let me however follow your thought experiment. > However expand that little W-PAN or car network to a train with > hundreds of VMN. IF every change in point of attachment of such a > large NEMO must be accompanied with one BU per CN, we can expect 100 > BUs after a change in point of attachment. Hundreds of VMN's in a train send zero BU's when the MR changes its attachment point, no? It's the MR that sends the unique BU no? > It also depends on the scale of the NEMO. The nunmber of BU's/second does not depend on the size of the moving network, except certain assumptions. If there were no NEMO-based MR, and if every MN in the train is connecting to the successive AR's along the track, and if every MN is having a continuous communication, then the number of BU's is exactly the number of MN's, yes. But if any of those 'if's is not then no storm. And "stormy" to what? Who is imposed a stress because of too many BU's? Let me write a different mail on that... Alex --------------enig0E7ADD2F7DB5D490C6D3D0DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYtSWMmC0w56zj54RAuYhAJ9UleYJ8hJq0QOz6nVmxJbC0XJ+MQCg1tmS D/esO6x8Qr0tkyCncbeAYLQ= =P4GF -----END PGP SIGNATURE----- --------------enig0E7ADD2F7DB5D490C6D3D0DA-- From nemo-bounces@ietf.org Tue Oct 5 13:42:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19189 for ; Tue, 5 Oct 2004 13:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtBO-0004sz-0t; Tue, 05 Oct 2004 13:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEt2q-0003iL-OQ for nemo@megatron.ietf.org; Tue, 05 Oct 2004 13:24:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17837 for ; Tue, 5 Oct 2004 13:24:10 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEtCA-0004YP-98 for nemo@ietf.org; Tue, 05 Oct 2004 13:33:51 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i95HPPDx018461; Tue, 5 Oct 2004 10:25:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i95HO6s6002543; Tue, 5 Oct 2004 12:24:07 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4A9668859B1; Tue, 5 Oct 2004 19:24:06 +0200 (CEST) Message-ID: <4162D8AB.5010400@motorola.com> Date: Tue, 05 Oct 2004 19:23:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> In-Reply-To: <1096956613.5491.92.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig57A54E0A5FB8CF91E9F7BC0F" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF NEMO WG Subject: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig57A54E0A5FB8CF91E9F7BC0F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit draft: > An intermediate MR would keep track of all the pending communications > between hosts in its subtree of Mobile Networks and their CNs, and a > binding message to each CN each time it changes its point of > attachment. > > If this was done, then each CN, by receiving all the binding messages > and processing them recursively, could infer a partial topology of > the nested Mobile Network, sufficient to build a multi-hop routing > header for packets sent to nodes inside the nested Mobile Network. > > However, this extension has a cost: > > 1. Binding Update storm > > when one MR changes its point of attachment, it needs to send a BU to > all the CNs of each node behind him. When the Mobile Network is > nested, the number of nodes and relative CNs can be huge, leading to > congestions and drops. related, not relative (minor). What is more precisely the network on which numerous BU's will act as a storm? It is actually the segment between TLMR and the last common router on the path between the new AR and all CN's. If you look closely, it is exactly the same common path that all packets (not only BU's to CN's) between all MNN's and their CN's will impose a stress. Imagine a train with many people watching different videos over Internet approaching the new AR. That new AR's upstream connection is relatively quiet (as preparing for a storm). When that AR receives the train's TLMR suddenly all those BU/BAck's followed by application-level packets will storm that common segment. However, the number of BU/BAck's is much smaller than the number of video-streaming packets. The "storm" has a small BU/BAck component. Eliminate that component and it's still "stormy". This is to say I do not think a BU storm is an inconvenient of having MR send BU's on behalf of its MNN's, or LFN's. And, if a MR-RO-for-LFN's BU's were stormy in the sense like that of RS's of hosts powering up on a common subnet, would an exponential backoff algorithm limiting and randomizing the order of sent BU's apply as a solution. Alex --------------enig57A54E0A5FB8CF91E9F7BC0F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYti2MmC0w56zj54RAr5TAJ4wwwzhc05cQr7XzgiHFM4QXQXyeACg23uK Cz58aVNgZwEC2X833P3k1sU= =/PXz -----END PGP SIGNATURE----- --------------enig57A54E0A5FB8CF91E9F7BC0F-- From nemo-bounces@ietf.org Tue Oct 5 14:09:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21464 for ; Tue, 5 Oct 2004 14:09:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtZY-0000qA-EX; Tue, 05 Oct 2004 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtY7-0000Rp-EK for nemo@megatron.ietf.org; Tue, 05 Oct 2004 13:56:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20300 for ; Tue, 5 Oct 2004 13:56:29 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEthO-0000mZ-3D for nemo@ietf.org; Tue, 05 Oct 2004 14:06:10 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 458F42D31C; Tue, 5 Oct 2004 19:55:52 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id E2AF62D31A; Tue, 5 Oct 2004 19:55:51 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4162D8AB.5010400@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K9f7XavnbUkbGFACEhYu" Organization: Universidad Carlos III de Madrid Message-Id: <1096998982.2457.110.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 05 Oct 2004 19:56:22 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-K9f7XavnbUkbGFACEhYu Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mar, 05-10-2004 a las 19:23, Alexandru Petrescu escribi=F3: > draft: > > An intermediate MR would keep track of all the pending communications > > between hosts in its subtree of Mobile Networks and their CNs, and a > > binding message to each CN each time it changes its point of=20 > > attachment. > >=20 > > If this was done, then each CN, by receiving all the binding messages > > and processing them recursively, could infer a partial topology of=20 > > the nested Mobile Network, sufficient to build a multi-hop routing=20 > > header for packets sent to nodes inside the nested Mobile Network. > >=20 > > However, this extension has a cost: > >=20 > > 1. Binding Update storm > >=20 > > when one MR changes its point of attachment, it needs to send a BU to > > all the CNs of each node behind him. When the Mobile Network is > > nested, the number of nodes and relative CNs can be huge, leading to > > congestions and drops. >=20 > related, not relative (minor). >=20 > What is more precisely the network on which numerous BU's will act as a=20 > storm? It is actually the segment between TLMR and the last common=20 > router on the path between the new AR and all CN's. If you look=20 > closely, it is exactly the same common path that all packets (not only=20 > BU's to CN's) between all MNN's and their CN's will impose a stress. >=20 > Imagine a train with many people watching different videos over Internet=20 > approaching the new AR. That new AR's upstream connection is relatively=20 > quiet (as preparing for a storm). When that AR receives the train's=20 > TLMR suddenly all those BU/BAck's followed by application-level packets=20 > will storm that common segment. However, the number of BU/BAck's is=20 > much smaller than the number of video-streaming packets. The "storm"=20 > has a small BU/BAck component. Eliminate that component and it's still=20 > "stormy". I agree with you that, in the scenario you've pointed out, sending or not sending those BUs really doesn't make any (appreciable) difference. Nevertheless, if you think in a different scenario, like, for example, the following, perhaps the effect of this signalling (i.e. BU) storm can be significant: Imagine the same train with many people browsing the web (i.e. many connections to many different CNs) approaching to a new AR. In this scenario, we can think in having some parts of the train's route covered only by some kind of 2.5/3G access technology (e.g. GPRS) in which the bandwidth is a very scarce resource. Therefore, in this scenario, having a signalling storm may be really suboptimal, leading to congestions and drops. What do you think? Thanks a lot. Cheers, Carlos J. > This is to say I do not think a BU storm is an inconvenient of having MR=20 > send BU's on behalf of its MNN's, or LFN's. >=20 > And, if a MR-RO-for-LFN's BU's were stormy in the sense like that of=20 > RS's of hosts powering up on a common subnet, would an exponential=20 > backoff algorithm limiting and randomizing the order of sent BU's apply=20 > as a solution. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-K9f7XavnbUkbGFACEhYu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBYuBF5vKyPtrWqkARAinDAKDd3zdVwRFdJBrDfCEbjsOERhuB/ACg2bir T9eC5wblR2jMp6HYwh8LRoA= =JBx5 -----END PGP SIGNATURE----- --=-K9f7XavnbUkbGFACEhYu-- From nemo-bounces@ietf.org Tue Oct 5 14:17:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22065 for ; Tue, 5 Oct 2004 14:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtmA-0003ED-Sq; Tue, 05 Oct 2004 14:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtic-0002SO-4w for nemo@megatron.ietf.org; Tue, 05 Oct 2004 14:07:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21296 for ; Tue, 5 Oct 2004 14:07:20 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEtrw-0002el-0W for nemo@ietf.org; Tue, 05 Oct 2004 14:17:01 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i95I8aDx027310; Tue, 5 Oct 2004 11:08:36 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i95I6651030557; Tue, 5 Oct 2004 13:06:07 -0500 Message-ID: <4162E2CD.9050907@motorola.com> Date: Tue, 05 Oct 2004 20:07:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> In-Reply-To: <1096998982.2457.110.camel@acorde> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4E4398D48E0EACAE35CDA11" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4E4398D48E0EACAE35CDA11 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Carlos Jesús Bernardos Cano wrote: > I agree with you that, in the scenario you've pointed out, sending or > not sending those BUs really doesn't make any (appreciable) > difference. Nevertheless, if you think in a different scenario, like, > for example, the following, perhaps the effect of this signalling > (i.e. BU) storm can be significant: > > Imagine the same train with many people browsing the web (i.e. many > connections to many different CNs) approaching to a new AR. In this > scenario, we can think in having some parts of the train's route > covered only by some kind of 2.5/3G access technology (e.g. GPRS) in > which the bandwidth is a very scarce resource. Therefore, in this > scenario, having a signalling storm may be really suboptimal, leading > to congestions and drops. > > What do you think? Thanks for asking. Saying 2.5/3G GPRS/UMTS leads to my oppinion that there is no BU at all, so no 'storm' because there is no change in IP address, neither the MNN's neither the MR is changing its IP address. This is the case with various GPRS/UMTS I'm accustomed with. GPRS/UMTS have indeed lower bandwidth than WLAN. I was trying to say that "BU storm" is a very vague problem that does not invite for a solution. I was trying to say that BU storm is not a drawback of having MR do RO on behalf of MNN's. Alex --------------enigC4E4398D48E0EACAE35CDA11 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBYuLTMmC0w56zj54RAh8jAKDNPN5a/uxqw5O1Qd/zey/iR32UGQCfeajE NCM9GL8+DU77cL7jpRo1l98= =RHju -----END PGP SIGNATURE----- --------------enigC4E4398D48E0EACAE35CDA11-- From nemo-bounces@ietf.org Tue Oct 5 14:27:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22787 for ; Tue, 5 Oct 2004 14:27:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEttF-0004bO-Op; Tue, 05 Oct 2004 14:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtqN-0003wM-MT for nemo@megatron.ietf.org; Tue, 05 Oct 2004 14:15:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21914 for ; Tue, 5 Oct 2004 14:15:22 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEtzh-000402-Vs for nemo@ietf.org; Tue, 05 Oct 2004 14:25:02 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7A6D7406CC; Tue, 5 Oct 2004 20:14:51 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 27A18406D1; Tue, 5 Oct 2004 20:14:51 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4162E2CD.9050907@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> <4162E2CD.9050907@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3cwjBTfOX3j/5PTZial2" Organization: Universidad Carlos III de Madrid Message-Id: <1097000121.2457.118.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 05 Oct 2004 20:15:22 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-3cwjBTfOX3j/5PTZial2 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mar, 05-10-2004 a las 20:07, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > > I agree with you that, in the scenario you've pointed out, sending or > > not sending those BUs really doesn't make any (appreciable) > > difference. Nevertheless, if you think in a different scenario, like, > > for example, the following, perhaps the effect of this signalling > > (i.e. BU) storm can be significant: > >=20 > > Imagine the same train with many people browsing the web (i.e. many=20 > > connections to many different CNs) approaching to a new AR. In this=20 > > scenario, we can think in having some parts of the train's route > > covered only by some kind of 2.5/3G access technology (e.g. GPRS) in > > which the bandwidth is a very scarce resource. Therefore, in this > > scenario, having a signalling storm may be really suboptimal, leading > > to congestions and drops. > >=20 > > What do you think? >=20 > Thanks for asking. >=20 > Saying 2.5/3G GPRS/UMTS leads to my oppinion that there is no BU at all, > so no 'storm' because there is no change in IP address, neither the > MNN's neither the MR is changing its IP address. This is the case with > various GPRS/UMTS I'm accustomed with. I was thinking in inter-technology handovers (e.g. WLAN-GPRS). The train may obtain connectivity by any 802.11x (or maybe 802.16) access technology while, for example , crossing cities and then it handovers to GPRS. BTW, I'm not sure if this would be a realistic scenario, but it could be. Of course, if the train is always connected to GPRS, there is no L3 handover at all. >=20 > GPRS/UMTS have indeed lower bandwidth than WLAN. >=20 > I was trying to say that "BU storm" is a very vague problem that does > not invite for a solution. >=20 > I was trying to say that BU storm is not a drawback of having MR do RO > on behalf of MNN's. I agree. But I also think that it is worth to point the problem and try to address it. Cheers, Carlos J. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-3cwjBTfOX3j/5PTZial2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBYuS55vKyPtrWqkARAtG9AJ9x0cFvqSYO4i7Cmvtza0sJfUocWQCgxS4I kcWK995w3lZDV7vX60v3du4= =hZTE -----END PGP SIGNATURE----- --=-3cwjBTfOX3j/5PTZial2-- From nemo-bounces@ietf.org Tue Oct 5 23:14:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11786 for ; Tue, 5 Oct 2004 23:14:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF2Di-0005cY-HB; Tue, 05 Oct 2004 23:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF2AA-0004df-AY for nemo@megatron.ietf.org; Tue, 05 Oct 2004 23:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11235 for ; Tue, 5 Oct 2004 23:08:19 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF2JW-0006Zl-Rk for nemo@ietf.org; Tue, 05 Oct 2004 23:18:06 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i96354tW017764; Wed, 6 Oct 2004 11:05:04 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 6D1F0B240CD; Wed, 6 Oct 2004 11:11:39 +0800 (SGT) Subject: Re: [nemo] RO Taxonomy From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4162CB2C.60903@motorola.com> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> <415BFBD6.9000701@motorola.com> <1096871862.9209.76.camel@localhost> <4161206B.4070808@motorola.com> <1096885571.9209.96.camel@localhost> <416129E9.6070008@motorola.com> <20041005131243.498ddc79.ernst@sfc.wide.ad.jp> <1096954728.5491.60.camel@localhost> <4162CB2C.60903@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1097032298.9781.39.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 11:11:38 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-10-06 at 00:26, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > >>>>>The statements in the taxonomy draft about mobility transparency > >>>>>are, in fact, relaxing the transparency requirements of the > >>>>>requirements/goals draft, was this the intention? > >>>> > >>>>Nope, at least that wasn't my interpretation when I read/write (sorry > >>>> don't really recall who wrote that text) the paragraph. The text > >>>>about mobility transparency is mainly to discuss that in achieving > >>>>RO, it might be necessary to have some nodes be RO-aware, eg CN (as > >>>>you've highlighted in another fork of this thread). > >>> > >>>Yes. So why not titling such a discussion with "The Need for RO-aware > >>>Nodes". In my oppinion it is not because mobility should be transparent > >>>that we need RO-aware nodes. If one leaves place for such a light > >>>interpretation of why RO is needed then _any_ other argument would > >>>apparently play in its favor. For example: we need RO-aware nodes > >>>because handovers should be fast, we need RO-aware nodes because > >>>Internet should be end-2-end and so on. Those are all bogus arguments > >>>to me, they all lack concreteness. Metaphoring has its risks :-) > >> > >>I kind of agree with Alex. On the other hand, I think it's extremely > >>difficult to decide if we need RO-aware nodes or not without looking > >>into the solutions. > > > > Agreed. > > > >>I think what we should do is definitely using "RO-aware nodes ?" as a > >>metric to evaluate the many solutions, after the problem statement is > >>issued. > >> > >>So, the discussion about the "need" could be left off after the document > >>is issued and the existing solutions are analysed. > >> > > Agreed. > > I can deduce you agree that the mobility transparency section is not needed? > Partly. To be specific, I agree change the mobility transparency section to a section discussing the need for NEMO-aware nodes in a RO solution. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 6 03:17:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26019 for ; Wed, 6 Oct 2004 03:17:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF5zt-0001Bk-HU; Wed, 06 Oct 2004 03:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF5zT-00013b-2t for nemo@megatron.ietf.org; Wed, 06 Oct 2004 03:13:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25783 for ; Wed, 6 Oct 2004 03:13:32 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF68t-0003UH-RD for nemo@ietf.org; Wed, 06 Oct 2004 03:23:20 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i967AO03027050; Wed, 6 Oct 2004 15:10:24 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 94CC5B240CD; Wed, 6 Oct 2004 15:16:58 +0800 (SGT) Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4162D491.5060303@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1097047017.9783.81.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 15:16:57 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-10-06 at 01:06, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > >> Wouldn't it be possible to have a sort of NEMO-RR after whose > >> completion there's no encapsulating header, no routing header? I > >> bet this is part of the solution space to the problem you're trying > >> to define. > > > > That would be very difficult to achieve. By your definition of > > overheads, a home-address destination option would also constitute as > > an overhead. I don't see how a NEMO-RO solution can hope to achieve > > zero overhead, except perhaps using an entirely and drastically > > different routing infrastructure. > > I agree with the DO containing the HoA means no zero-encapsulation and > overhead. I don't see how a NEMO-RO solution can hope to achieve zero > overhead with existing routing infrastructure, but I see how a NEMO-RO > solution can achieve zero-overhead without the existing (and not any > other) infrastructure. That is, if the aggregatation of moving networks > is disconnected from the infrastructure, then it is possible to have > that zero-overhead, no routing header, no DO. > Ah, I see. It means we use a different address space for NEMO-RO so that these address are not routed using aggregation, but rely on the mobile router running some kind of dynamic routing protocol. However, I foresee other problems with this approach, Off-hand, (1) that will mean RO is achieved in a way that is totally incompatible with NEMO-Basic, (2) imagine millions of mobile networks in the future, and we just created another routing table explosion, etc. > > Nope, but let's do a bit of thought experiment. If you are looking > > at the NEMO being a W-PAN or a car network, it might not even be > > windy at all! Perhaps only a little breezy, so to speak. ;) > > But the number of BU's depend not on the size of the moving network! > Let me however follow your thought experiment. > > > However expand that little W-PAN or car network to a train with > > hundreds of VMN. IF every change in point of attachment of such a > > large NEMO must be accompanied with one BU per CN, we can expect 100 > > BUs after a change in point of attachment. > > Hundreds of VMN's in a train send zero BU's when the MR changes its > attachment point, no? It's the MR that sends the unique BU no? Depending on the RO-solution, it can be the VMNs sending the BU, or MR sending the BU on behalf of VMNs. Point is, there will be hundreds of BU generated from the mobile network. > > > It also depends on the scale of the NEMO. > > The nunmber of BU's/second does not depend on the size of the moving > network, except certain assumptions. > > If there were no NEMO-based MR, and if every MN in the train is > connecting to the successive AR's along the track, and if every MN is > having a continuous communication, then the number of BU's is exactly > the number of MN's, yes. But if any of those 'if's is not then no storm. > You statement maybe correct, again it depends on the solution of NEMO-RO. That's why the draft as a problem analysis draft should discuss it. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 6 04:23:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00927 for ; Wed, 6 Oct 2004 04:23:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF73S-0003QT-EZ; Wed, 06 Oct 2004 04:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF70g-0002y7-7N for nemo@megatron.ietf.org; Wed, 06 Oct 2004 04:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00645 for ; Wed, 6 Oct 2004 04:18:51 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7A8-00082e-1E for nemo@ietf.org; Wed, 06 Oct 2004 04:28:40 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i968FgOo029500; Wed, 6 Oct 2004 16:15:42 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id A3524B240CD; Wed, 6 Oct 2004 16:22:16 +0800 (SGT) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4162D8AB.5010400@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1097050935.9783.110.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 16:22:16 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-10-06 at 01:23, Alexandru Petrescu wrote: > draft: > > An intermediate MR would keep track of all the pending communications > > between hosts in its subtree of Mobile Networks and their CNs, and a > > binding message to each CN each time it changes its point of > > attachment. > > > > If this was done, then each CN, by receiving all the binding messages > > and processing them recursively, could infer a partial topology of > > the nested Mobile Network, sufficient to build a multi-hop routing > > header for packets sent to nodes inside the nested Mobile Network. > > > > However, this extension has a cost: > > > > 1. Binding Update storm > > > > when one MR changes its point of attachment, it needs to send a BU to > > all the CNs of each node behind him. When the Mobile Network is > > nested, the number of nodes and relative CNs can be huge, leading to > > congestions and drops. > > related, not relative (minor). OK. > > What is more precisely the network on which numerous BU's will act as a > storm? It is actually the segment between TLMR and the last common > router on the path between the new AR and all CN's. If you look > closely, it is exactly the same common path that all packets (not only > BU's to CN's) between all MNN's and their CN's will impose a stress. > Right. > Imagine a train with many people watching different videos over Internet > approaching the new AR. That new AR's upstream connection is relatively > quiet (as preparing for a storm). When that AR receives the train's > TLMR suddenly all those BU/BAck's followed by application-level packets > will storm that common segment. However, the number of BU/BAck's is > much smaller than the number of video-streaming packets. The "storm" > has a small BU/BAck component. Eliminate that component and it's still > "stormy". What you've mentioned here is I believe what I discussed in the previous mail about normalizing the signaling packets (BU/BA/RR) against the data packets (video/audio packets, in this example). The catch here is in quoting the video streaming example, the number of data packets per second is huge, making the number of signalling packets to be smaller in comparison. However, if we used another example of web-browsing, or instant-messaging, the number of data packets generated by the application will be smaller per second. In this scenario, the sudden surge of sending N * BU messages, where N = number of MNNs, may be significant. Having said that, one still have to relate back to the application and user experience. For web-browsing, or IM, the user would most likely be quite tolerant of "random" (in the perspective of user) increased delay caused by "BU Storm". For video streaming, users will be irritated more by sudden delays. Sorry if I seems to be contradicting myself, but I just want to explore the issue deeper. > > This is to say I do not think a BU storm is an inconvenient of having MR > send BU's on behalf of its MNN's, or LFN's. You might be surprised, but in fact, I tend to think the same way as you do. However, I also felt that it is necessary to include such discussions in the draft. It is yet to be decided whether BU storm is a significant issue. From my discussions above, I believe it is dependent on the applications. For an application that generates small number of data packets per second, but cannot tolerate delays, BU storm may be an important consideration. One such application that comes to mind will be VoIP. > > And, if a MR-RO-for-LFN's BU's were stormy in the sense like that of > RS's of hosts powering up on a common subnet, would an exponential > backoff algorithm limiting and randomizing the order of sent BU's apply > as a solution. True. Shouldn't this be documented in the draft as well? /rgds /cwng From nemo-bounces@ietf.org Wed Oct 6 04:31:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01491 for ; Wed, 6 Oct 2004 04:31:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF78B-00045r-Qg; Wed, 06 Oct 2004 04:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF73Y-0003VA-6P for nemo@megatron.ietf.org; Wed, 06 Oct 2004 04:21:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00807 for ; Wed, 6 Oct 2004 04:21:49 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7D0-0008Ds-Lr for nemo@ietf.org; Wed, 06 Oct 2004 04:31:38 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i968N6Dx005836; Wed, 6 Oct 2004 01:23:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i968Kc51012969; Wed, 6 Oct 2004 03:20:39 -0500 Received: from [10.161.201.135] (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 090588659B3; Wed, 6 Oct 2004 10:21:48 +0200 (CEST) Message-ID: <4163AB1B.3000801@motorola.com> Date: Wed, 06 Oct 2004 10:21:47 +0200 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> <4162E2CD.9050907@motorola.com> <1097000121.2457.118.camel@acorde> In-Reply-To: <1097000121.2457.118.camel@acorde> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id i968N6Dx005836 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah Ng , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Sorry to jump in... >>Carlos Jes=FAs Bernardos Cano wrote: > [...] > I was thinking in inter-technology handovers (e.g. WLAN-GPRS). The > train may obtain connectivity by any 802.11x (or maybe 802.16) access > technology while, for example , crossing cities and then it handovers t= o > GPRS. BTW, I'm not sure if this would be a realistic scenario, but it > could be. >=20 > Of course, if the train is always connected to GPRS, there is no L3 > handover at all. >=20 >=20 >>GPRS/UMTS have indeed lower bandwidth than WLAN. Sorry to jump in... IMHO, if the bandwith is limited (e.g . GPRS) is it also highly possible=20 that the many user applications would not be able to survive (or with=20 significant QoS degradation) the handover anyway....whether there is a=20 "BU storm or not".... >>I was trying to say that "BU storm" is a very vague problem that does >>not invite for a solution. >> >>I was trying to say that BU storm is not a drawback of having MR do RO >>on behalf of MNN's. >=20 I agree. It seems to me that the BU storm looks like a nice theoritical=20 issue, but may have little foundations in realistic deployements... Indeed the MR-to-CN BUs for RO will increase as the number of CN=20 increases, but the impact on the TLMR-AR link should not be too much an=20 issue since realistic deployement should consider high bandwith TLMR-AR=20 link in case of large nemo (with possibly large number of CNs)....just=20 to be able to support the traffic from applications. thoughts? Christophe CHristophe. From nemo-bounces@ietf.org Wed Oct 6 04:40:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02294 for ; Wed, 6 Oct 2004 04:40:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7CR-0004z2-Eb; Wed, 06 Oct 2004 04:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF759-0003nm-Eg for nemo@megatron.ietf.org; Wed, 06 Oct 2004 04:23:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00917 for ; Wed, 6 Oct 2004 04:23:29 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7Eb-0008Ed-CU for nemo@ietf.org; Wed, 06 Oct 2004 04:33:18 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i968KN3Q029698; Wed, 6 Oct 2004 16:20:23 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 3F91FB240CD; Wed, 6 Oct 2004 16:26:57 +0800 (SGT) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Chan-Wah Ng To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1097000121.2457.118.camel@acorde> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> <4162E2CD.9050907@motorola.com> <1097000121.2457.118.camel@acorde> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Laboratories Message-Id: <1097051216.9781.115.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 16:26:56 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i968KN3Q029698 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Carlos,=20 On Wed, 2004-10-06 at 02:15, Carlos Jes=FAs Bernardos Cano wrote: > Hi Alex, >=20 > > I was trying to say that "BU storm" is a very vague problem that does > > not invite for a solution. > >=20 > > I was trying to say that BU storm is not a drawback of having MR do R= O > > on behalf of MNN's. >=20 > I agree. But I also think that it is worth to point the problem and tr= y > to address it. >=20 I don't meant to troll, but I must say "me too!" to that last sentence :) /rgds /cwng From nemo-bounces@ietf.org Wed Oct 6 05:52:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07206 for ; Wed, 6 Oct 2004 05:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8Rp-00005F-DW; Wed, 06 Oct 2004 05:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8MQ-0007rm-JQ for nemo@megatron.ietf.org; Wed, 06 Oct 2004 05:45:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06833 for ; Wed, 6 Oct 2004 05:45:23 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8Vr-0004rF-BR for nemo@ietf.org; Wed, 06 Oct 2004 05:55:14 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2004 11:55:43 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i969icVG028222; Wed, 6 Oct 2004 11:44:47 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 11:44:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) Date: Wed, 6 Oct 2004 11:44:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC28361C@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) Thread-Index: AcSrAreVMBAWKw1ISaiqqx5NNcxESAAbjgUA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Chan-Wah Ng" X-OriginalArrivalTime: 06 Oct 2004 09:44:46.0676 (UTC) FILETIME=[1D7C2140:01C4AB89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Alex: Let's take examples ------------------- Case 1: MR joins a tree. Say a MR with an LFN attaches into an existing tree at depth 3. so we have: Root-MR <- MR1 <- MR2 <- MR . Say LFN starts a connection with CN, and say we want to optimize that. With the assumptions in the quoted text, our MR has to bind its MNP to the CN with its careof. But CN does not know how to reach that careof, which is from MNP2 (MR2's MNP). So MR2 has to bind MNP2 with its careof with CN. Recursively, MR1 and root-MR have to bind to CN as well. So we need 4 bindings, which have to be synchronized while maintained individually. On the other hand, if you look at RRH, only the MR that moves sends a binding. The BU traces the way out. That's a single BU, with a snapshot of the tree at the time of the packet. No state in the intermediate routers. No additional BUs that the CN has to correlate together.=20 Case 2: Root-MR now changes its point of attachment. With the assumptions in the quoted text, it has to send one BU to all CNs of all the LFNs in the tree. This causes a burst on the network. If there's no special code to support that in the MR, packets might even be discarded inside the box because the output queue is saturated. Each BU that gets dropped means a hung connection. On the other hand, if the same amount of BUs was issued by the MRs to which the LFNs are attached, they would arrive in a more dispersed manner, which would help digesting them. With RRH, MRs might delay the BU for a small amount of time in case there's upstream traffic for that CN that would update the RRH cache in the CN in-band, avoiding many of the BUs.=20 Conclusion ---------- With the assumptions in the quoted text, for each (LFN, CN) that's ROed binding, each MR above the LFN in the nested structure needs to send a BU to all these CNs when it moves, so that a CN has the chain of BUs that enables building a path down the tree.=20 When a MR moves to a new place in the tree, it has to rebind for all CNs down its tree, as we said. But then all MRs above it have to do it too. And MRs up its previous location have to stop doing it, otherwise the CN is very confused. There no mechanism in NEMO for a MR to discover and maintain states about MR-CN RO binding down its subtree. In the context of that chapter, it means snooping.=20 The text speak to the good sense and means, in short, how deep do you want to go before you try something else? > This is to say I do not think a BU storm is an inconvenient of having MR > send BU's on behalf of its MNN's, or LFN's. The BU storm problem mentioned here is *not* that it would be wrong to do RO from the first MR as opposed to LFN (where did you read that?). It's about more then the minimum BUs being sent, and BUs being sent by the wrong MRs. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: mardi 5 octobre 2004 19:24 > To: Chan-Wah Ng > Cc: IETF NEMO WG > Subject: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on > the RO Taxonomy draft) >=20 > draft: > > An intermediate MR would keep track of all the pending communications > > between hosts in its subtree of Mobile Networks and their CNs, and a > > binding message to each CN each time it changes its point of > > attachment. > > > > If this was done, then each CN, by receiving all the binding messages > > and processing them recursively, could infer a partial topology of > > the nested Mobile Network, sufficient to build a multi-hop routing > > header for packets sent to nodes inside the nested Mobile Network. > > > > However, this extension has a cost: > > > > 1. Binding Update storm > > > > when one MR changes its point of attachment, it needs to send a BU to > > all the CNs of each node behind him. When the Mobile Network is > > nested, the number of nodes and relative CNs can be huge, leading to > > congestions and drops. >=20 > related, not relative (minor). >=20 > What is more precisely the network on which numerous BU's will act as a > storm? It is actually the segment between TLMR and the last common > router on the path between the new AR and all CN's. If you look > closely, it is exactly the same common path that all packets (not only > BU's to CN's) between all MNN's and their CN's will impose a stress. >=20 > Imagine a train with many people watching different videos over Internet > approaching the new AR. That new AR's upstream connection is relatively > quiet (as preparing for a storm). When that AR receives the train's > TLMR suddenly all those BU/BAck's followed by application-level packets > will storm that common segment. However, the number of BU/BAck's is > much smaller than the number of video-streaming packets. The "storm" > has a small BU/BAck component. Eliminate that component and it's still > "stormy". >=20 > This is to say I do not think a BU storm is an inconvenient of having MR > send BU's on behalf of its MNN's, or LFN's. >=20 > And, if a MR-RO-for-LFN's BU's were stormy in the sense like that of > RS's of hosts powering up on a common subnet, would an exponential > backoff algorithm limiting and randomizing the order of sent BU's apply > as a solution. >=20 > Alex From nemo-bounces@ietf.org Wed Oct 6 07:10:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11917 for ; Wed, 6 Oct 2004 07:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9dY-0003UJ-Uv; Wed, 06 Oct 2004 07:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9WZ-0002fr-T3 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 07:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11371 for ; Wed, 6 Oct 2004 06:59:56 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF9fz-0000rW-Tm for nemo@ietf.org; Wed, 06 Oct 2004 07:09:48 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BC9B82F461; Wed, 6 Oct 2004 12:59:23 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 6426C2F466; Wed, 6 Oct 2004 12:59:23 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Christophe Janneteau In-Reply-To: <4163AB1B.3000801@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> <4162E2CD.9050907@motorola.com> <1097000121.2457.118.camel@acorde> <4163AB1B.3000801@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rcKpYqG1px+ErUzvv/IJ" Organization: Universidad Carlos III de Madrid Message-Id: <1097060395.2425.44.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 12:59:55 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF NEMO WG , Chan-Wah Ng , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-rcKpYqG1px+ErUzvv/IJ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Christophe, El mi=E9, 06-10-2004 a las 10:21, Christophe Janneteau escribi=F3: > Hi, >=20 > Sorry to jump in... >=20 > >>Carlos Jes=FAs Bernardos Cano wrote: > > [...] > > I was thinking in inter-technology handovers (e.g. WLAN-GPRS). The > > train may obtain connectivity by any 802.11x (or maybe 802.16) access > > technology while, for example , crossing cities and then it handovers t= o > > GPRS. BTW, I'm not sure if this would be a realistic scenario, but it > > could be. > >=20 > > Of course, if the train is always connected to GPRS, there is no L3 > > handover at all. > >=20 > >=20 > >>GPRS/UMTS have indeed lower bandwidth than WLAN. >=20 > Sorry to jump in... >=20 > IMHO, if the bandwith is limited (e.g . GPRS) is it also highly possible=20 > that the many user applications would not be able to survive (or with=20 > significant QoS degradation) the handover anyway....whether there is a=20 > "BU storm or not".... IMHO, it depends on the scenario. GPRS is only an example, and 'significant QoS degradation' depends also on the applications, the specific service provided to the users by the network operator, etc. I just wanted to point out that, IMHO, I agree that the "BU storm" is not such a big problem, but it interesting enough to at least address it.=20 >=20 > >>I was trying to say that "BU storm" is a very vague problem that does > >>not invite for a solution. > >> > >>I was trying to say that BU storm is not a drawback of having MR do RO > >>on behalf of MNN's. > >=20 >=20 > I agree. It seems to me that the BU storm looks like a nice theoritical=20 > issue, but may have little foundations in realistic deployements... > Indeed the MR-to-CN BUs for RO will increase as the number of CN=20 > increases, but the impact on the TLMR-AR link should not be too much an=20 > issue since realistic deployement should consider high bandwith TLMR-AR=20 > link in case of large nemo (with possibly large number of CNs)....just=20 > to be able to support the traffic from applications. The TLMR-AR link would be likely wireless, so even it is well provisioned, we couldn't expect higher bandwidths, so it is worth to take into account also the performance improvement of the protocols in terms of signalling overhead, IMHO. Kind regards, Carlos J. >=20 > thoughts? >=20 > Christophe >=20 > CHristophe. --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-rcKpYqG1px+ErUzvv/IJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBY9Ap5vKyPtrWqkARAhIaAJ0dxz9RZOhhciEAWLtiyrDg8lRhUwCfQAbw bLJaFYdhaUqpyDmYdZhwvfU= =76Uu -----END PGP SIGNATURE----- --=-rcKpYqG1px+ErUzvv/IJ-- From nemo-bounces@ietf.org Wed Oct 6 08:56:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20638 for ; Wed, 6 Oct 2004 08:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBD6-0007NM-He; Wed, 06 Oct 2004 08:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBAN-0006z1-W3 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 08:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19801 for ; Wed, 6 Oct 2004 08:45:10 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBJr-0007bV-Mi for nemo@ietf.org; Wed, 06 Oct 2004 08:55:01 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96CkMhZ011070; Wed, 6 Oct 2004 05:46:22 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i96Cj3s6018805; Wed, 6 Oct 2004 07:45:04 -0500 Received: from [10.161.201.135] (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A3BDC88DF9B; Wed, 6 Oct 2004 14:45:02 +0200 (CEST) Message-ID: <4163E8CD.6040002@motorola.com> Date: Wed, 06 Oct 2004 14:45:01 +0200 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) References: <7892795E1A87F04CADFCCF41FADD00FC28361C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC28361C@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Chan-Wah Ng , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Salut Pascal, Some comments on your email below. Pascal Thubert (pthubert) wrote: > Let's take examples > ------------------- > > Case 1: MR joins a tree. > > Say a MR with an LFN attaches into an existing tree at depth 3. so we > have: > Root-MR <- MR1 <- MR2 <- MR . Say LFN starts a connection with CN, and > say we want to optimize that. > > With the assumptions in the quoted text, our MR has to bind its MNP to > the CN with its careof. But CN does not know how to reach that careof, > which is from MNP2 (MR2's MNP). So MR2 has to bind MNP2 with its careof > with CN. Recursively, MR1 and root-MR have to bind to CN as well. > So we need 4 bindings, which have to be synchronized while maintained > individually. Right. But note that the applications are still maintained even if the full path for RO is not known at CN (e.g. binding for MR2 missing), and the path would still be partially optimized. That said, there may be some ways to speed up and "synchronize" the sending of the bindings of nested MRs to CN, so that CN gets all of them "at once". > On the other hand, if you look at RRH, only the MR that moves sends a > binding. The BU traces the way out. That's a single BU, with a snapshot > of the tree at the time of the packet. No state in the intermediate > routers. No additional BUs that the CN has to correlate together. RRH may have advantages, but also has drawbacks (e.g. significant departure from Basic-NEMO BU semantic, determining optimun number of slot in RRH header, security, etc...). BTW, It may be too early now to start comparing solutions, this may turn in an endless thread :) When doing this exercise one should make sure that all the various criterias for comparison are taken into account. They also need to be defined first... > > Case 2: Root-MR now changes its point of attachment. > > With the assumptions in the quoted text, it has to send one BU to all > CNs of all the LFNs in the tree. This causes a burst on the network. But only Root-MR would sent BU, thus zero overhead is introduced inside the aggregation while this would not be true with RRH. If RRH is to be used only in BU messages, then lower MRs in the aggregation need to discover Root-MR movement in order to send BU...thus extra signalling. In addition all MRs behind Root-MR will then need to send BUs to update CNs with their optimized path, thus extra signalling. If in-band RRH (i.e. in all data packets) is used then overhead of RRH header takes place for each packet?... [...] > With RRH, MRs might delay the BU for a small amount of time in case > there's upstream traffic for that CN that would update the RRH cache in > the CN in-band, avoiding many of the BUs. Well, with MR-to-CN BU, only Root-MR would need to send the BU to the CNs, and of course could arrange not to send the simultaneously to avoid overhead on the TLMR-RA link... > > Conclusion > ---------- > > With the assumptions in the quoted text, for each (LFN, CN) that's ROed > binding, each MR above the LFN in the nested structure needs to send a > BU to all these CNs when it moves, so that a CN has the chain of BUs > that enables building a path down the tree. > > When a MR moves to a new place in the tree, it has to rebind for all CNs > down its tree, as we said. But then all MRs above it have to do it too. > And MRs up its previous location have to stop doing it, otherwise the CN > is very confused. No, I don't think CN will be confused if it still has bindings for the mobile routers up to MR's previous location. As soon as CN gets the new MR's binding, it knows that the MR has moved to a new location. This new location could match the prefix of a new upper mobile router. If CN has a binding for this new upper-MR is will use it, and route packet along new-upper-MR CoA and MR CoA. Entries for old-upper-MR is not used and does not arm at all.... Christophe. From nemo-bounces@ietf.org Wed Oct 6 08:57:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20783 for ; Wed, 6 Oct 2004 08:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBD7-0007NV-4j; Wed, 06 Oct 2004 08:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBBQ-00074l-29 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 08:46:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19956 for ; Wed, 6 Oct 2004 08:46:14 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBKu-0007cd-Qy for nemo@ietf.org; Wed, 06 Oct 2004 08:56:05 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i96CgLtV002316; Wed, 6 Oct 2004 05:42:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i96CcuNK030663; Wed, 6 Oct 2004 07:38:57 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AE93D88DF9B; Wed, 6 Oct 2004 14:41:08 +0200 (CEST) Message-ID: <4163E7DE.1040306@motorola.com> Date: Wed, 06 Oct 2004 14:41:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC28361C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC28361C@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F5B90EF088E3B6A6B2C46D3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: IETF NEMO WG , Chan-Wah Ng Subject: [nemo] Re: RRH (was: Re: BU storms when MR does RO on behalf of LFN's) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F5B90EF088E3B6A6B2C46D3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Case 1: MR joins a tree. > > Say a MR with an LFN attaches into an existing tree at depth 3. so we > have: Root-MR <- MR1 <- MR2 <- MR . Say LFN starts a connection with > CN, and say we want to optimize that. > > With the assumptions in the quoted text, our MR has to bind its MNP > to the CN with its careof. But CN does not know how to reach that > careof, which is from MNP2 (MR2's MNP). So MR2 has to bind MNP2 with > its careof with CN. Recursively, MR1 and root-MR have to bind to CN > What's "recursive" here? I see "successively" but no "recursion". (????) > as well. So we need 4 bindings, which have to be synchronized while > maintained individually. I don't understand, what's the problem with being synchronized while being maintained individually? > On the other hand, if you look at RRH, only the MR that moves sends a > binding. The BU traces the way out. That's a single BU, with a > snapshot of the tree at the time of the packet. No state in the > intermediate routers. No additional BUs that the CN has to correlate > together. Advertising for a solution has no place in problem discussion. If you want, we can discuss RRH separately, in a separate thread. > Case 2: Root-MR now changes its point of attachment. > > With the assumptions in the quoted text, it has to send one BU to all > CNs of all the LFNs in the tree. This causes a burst on the network. > If there's no special code to support that in the MR, packets might > even be discarded inside the box because the output queue is > saturated. Each BU that gets dropped means a hung connection. > > On the other hand, if the same amount of BUs was issued by the MRs to > which the LFNs are attached, they would arrive in a more dispersed > manner, which would help digesting them. > > With RRH, MRs might delay the BU for a small amount of time in case > there's upstream traffic for that CN that would update the RRH cache > in the CN in-band, avoiding many of the BUs. > > > Conclusion ---------- > > With the assumptions in the quoted text, for each (LFN, CN) that's > ROed binding, each MR above the LFN in the nested structure needs to > send a BU to all these CNs when it moves, so that a CN has the chain > of BUs that enables building a path down the tree. > > When a MR moves to a new place in the tree, it has to rebind for all > CNs down its tree, as we said. But then all MRs above it have to do > it too. And MRs up its previous location have to stop doing it, > otherwise the CN is very confused. > > There no mechanism in NEMO for a MR to discover and maintain states > about MR-CN RO binding down its subtree. In the context of that > chapter, it means snooping. > > The text speak to the good sense and means, in short, how deep do you > want to go before you try something else? I think the text speaks in a way that says RO is a problem and RRH is a solution. >> This is to say I do not think a BU storm is an inconvenient of >> having MR send BU's on behalf of its MNN's, or LFN's. > > The BU storm problem mentioned here is *not* that it would be wrong > to do RO from the first MR as opposed to LFN (where did you read > that?). It's about more then the minimum BUs being sent, and BUs > being sent by the wrong MRs. I read in the taxonomy draft that having an MR to send BU's on behalf of the hosts in the subtree has a cost: BU storm (and 4 other costs too); section 6.2. (BTW, what do you call "processing BU's recursively" and "recursive fashion"? What module/part/function calls upon itself? I don't see any recursion in processing several incoming BU's and CN _iterating_ through the BC to build a RH; anyways, be it iteration or recursion, I don't see the computation burden...) Alex --------------enig6F5B90EF088E3B6A6B2C46D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY+fkMmC0w56zj54RAilgAKCQ3ISmZxcNEWoV6/VInBn1nliXwwCfX6XE Fn7BNH/i/rPdGdfeW9mZZEM= =k72V -----END PGP SIGNATURE----- --------------enig6F5B90EF088E3B6A6B2C46D3-- From nemo-bounces@ietf.org Wed Oct 6 08:59:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20904 for ; Wed, 6 Oct 2004 08:59:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBMp-0000sq-Qa; Wed, 06 Oct 2004 08:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBEW-0007WP-Vo for nemo@megatron.ietf.org; Wed, 06 Oct 2004 08:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20074 for ; Wed, 6 Oct 2004 08:49:27 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBNz-0007nV-Ov for nemo@ietf.org; Wed, 06 Oct 2004 08:59:18 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96CofhZ014770; Wed, 6 Oct 2004 05:50:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i96CmD51020700; Wed, 6 Oct 2004 07:48:13 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9D6D688DF9B; Wed, 6 Oct 2004 14:49:22 +0200 (CEST) Message-ID: <4163E9CD.3090106@motorola.com> Date: Wed, 06 Oct 2004 14:49:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> <1097047017.9783.81.camel@localhost> In-Reply-To: <1097047017.9783.81.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig599018E57F2298028D021382" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig599018E57F2298028D021382 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >> I agree with the DO containing the HoA means no zero-encapsulation >> and overhead. I don't see how a NEMO-RO solution can hope to >> achieve zero overhead with existing routing infrastructure, but I >> see how a NEMO-RO solution can achieve zero-overhead without the >> existing (and not any other) infrastructure. That is, if the >> aggregatation of moving networks is disconnected from the >> infrastructure, then it is possible to have that zero-overhead, no >> routing header, no DO. >> > Ah, I see. It means we use a different address space for NEMO-RO so > that these address are not routed using aggregation, but rely on the > mobile router running some kind of dynamic routing protocol. No, it means that when you have an aggregation of moving networks whose TLMR is disconnected (no infrastructure), there should be a way to make those networks talk to each other without RH's nor DO's. > However, I foresee other problems with this approach, Off-hand, (1) > that will mean RO is achieved in a way that is totally incompatible > with NEMO-Basic, Exactly, that solution should interoperate with NEMO basic, that's for sure, although if off-hand it looks as if it doesn't. > (2) imagine millions of mobile networks in the future, and we just > created another routing table explosion, etc. As long as there's no infrastructure I can't quite imagine millions of mobile networks. >>> Nope, but let's do a bit of thought experiment. If you are >>> looking at the NEMO being a W-PAN or a car network, it might not >>> even be windy at all! Perhaps only a little breezy, so to speak. >>> ;) >> >> But the number of BU's depend not on the size of the moving >> network! Let me however follow your thought experiment. >> >> >>> However expand that little W-PAN or car network to a train with >>> hundreds of VMN. IF every change in point of attachment of such >>> a large NEMO must be accompanied with one BU per CN, we can >>> expect 100 BUs after a change in point of attachment. >> >> Hundreds of VMN's in a train send zero BU's when the MR changes its >> attachment point, no? It's the MR that sends the unique BU no? > > > Depending on the RO-solution, it can be the VMNs sending the BU, or > MR sending the BU on behalf of VMNs. Point is, there will be > hundreds of BU generated from the mobile network. What's "hundreds of BU's" compared to "millions of UDP packets"? >> If there were no NEMO-based MR, and if every MN in the train is >> connecting to the successive AR's along the track, and if every MN >> is having a continuous communication, then the number of BU's is >> exactly the number of MN's, yes. But if any of those 'if's is not >> then no storm. > > You statement maybe correct, again it depends on the solution of > NEMO-RO. That's why the draft as a problem analysis draft should > discuss it. YEs, depends on the solution. A problem statement draft for route optimization should discuss it and look in a non-biased way at various approaches to solve this problem... Alex --------------enig599018E57F2298028D021382 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY+nSMmC0w56zj54RAviCAKDJSw4xq4WGiD/pevz4QNmobRhw7QCg6E0g J0CTw8WjGJbgDTNBneQlEsc= =OZ71 -----END PGP SIGNATURE----- --------------enig599018E57F2298028D021382-- From nemo-bounces@ietf.org Wed Oct 6 09:06:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21478 for ; Wed, 6 Oct 2004 09:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBN8-0000wq-3A; Wed, 06 Oct 2004 08:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBKI-0008Vw-P7 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 08:55:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20483 for ; Wed, 6 Oct 2004 08:55:24 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBTm-00084u-KV for nemo@ietf.org; Wed, 06 Oct 2004 09:05:16 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96CuehZ020175; Wed, 6 Oct 2004 05:56:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i96CtLs6000318; Wed, 6 Oct 2004 07:55:22 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4BBDF8A358D; Wed, 6 Oct 2004 14:55:21 +0200 (CEST) Message-ID: <4163EB32.8060501@motorola.com> Date: Wed, 06 Oct 2004 14:55:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1096998982.2457.110.camel@acorde> <4162E2CD.9050907@motorola.com> <1097000121.2457.118.camel@acorde> In-Reply-To: <1097000121.2457.118.camel@acorde> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24B3265A494B89F27A07A4F3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24B3265A494B89F27A07A4F3 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Carlos Jesús Bernardos Cano wrote: > I agree. But I also think that it is worth to point the problem and > try to address it. YEs, absolutely. But there are ways and ways to describe problems. Alex --------------enig24B3265A494B89F27A07A4F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY+s5MmC0w56zj54RAoQ9AKCGBdCcHYHd3WlaqK4N7Q9P6b91CQCfSVZj uTUnkhEkwfMfCzUJnCDGRy8= =ygRl -----END PGP SIGNATURE----- --------------enig24B3265A494B89F27A07A4F3-- From nemo-bounces@ietf.org Wed Oct 6 09:21:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23294 for ; Wed, 6 Oct 2004 09:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBba-0003su-Vl; Wed, 06 Oct 2004 09:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBUy-0002er-BM for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:06:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21518 for ; Wed, 6 Oct 2004 09:06:26 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBeS-0000Ys-68 for nemo@ietf.org; Wed, 06 Oct 2004 09:16:17 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i96D6PAt008190; Wed, 6 Oct 2004 06:06:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i96CwO1h023304; Wed, 6 Oct 2004 07:58:25 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E5ADF88DF9B; Wed, 6 Oct 2004 15:06:22 +0200 (CEST) Message-ID: <4163EDC8.9070403@motorola.com> Date: Wed, 06 Oct 2004 15:06:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> In-Reply-To: <1097050935.9783.110.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB415C626DCA929E2372A27A1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB415C626DCA929E2372A27A1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > However, if we used another example of web-browsing, or > instant-messaging, the number of data packets generated by the > application will be smaller per second. In this scenario, the sudden > surge of sending N * BU messages, where N = number of MNNs, may be > significant. I'd think that a real BU storm when train changes AR can only apppear if all passengers click Reload simultaneously and at the exact moment of changing AR... > Having said that, one still have to relate back to the application > and user experience. For web-browsing, or IM, the user would most > likely be quite tolerant of "random" (in the perspective of user) > increased delay caused by "BU Storm". For video streaming, users > will be irritated more by sudden delays. Yes. > Sorry if I seems to be contradicting myself, but I just want to > explore the issue deeper. It's just a discussion, I experience that too. >> This is to say I do not think a BU storm is an inconvenient of >> having MR send BU's on behalf of its MNN's, or LFN's. > > You might be surprised, but in fact, I tend to think the same way as > you do. However, I also felt that it is necessary to include such > discussions in the draft. That's the prerequisite for having a WG item IMHO. >> And, if a MR-RO-for-LFN's BU's were stormy in the sense like that >> of RS's of hosts powering up on a common subnet, would an >> exponential backoff algorithm limiting and randomizing the order of >> sent BU's apply as a solution. > > True. Shouldn't this be documented in the draft as well? Which draft? Alex --------------enigB415C626DCA929E2372A27A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY+3OMmC0w56zj54RAiZwAJ9I2AxmXLjIzI8d55TCxLFPW1bZ7ACfWHum f8+KgBJEPOIrVsFaTBKpF9o= =ylOE -----END PGP SIGNATURE----- --------------enigB415C626DCA929E2372A27A1-- From nemo-bounces@ietf.org Wed Oct 6 09:27:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23928 for ; Wed, 6 Oct 2004 09:27:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBlO-0005Ra-Cg; Wed, 06 Oct 2004 09:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBby-00041N-G8 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:13:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22158 for ; Wed, 6 Oct 2004 09:13:40 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBlT-000103-Az for nemo@ietf.org; Wed, 06 Oct 2004 09:23:31 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2004 15:24:06 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i96DCUVk011531; Wed, 6 Oct 2004 15:13:07 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 15:13:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) Date: Wed, 6 Oct 2004 15:12:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC283702@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft) Thread-Index: AcSrolaJ/rpUhRWsSu6j9ntwgfKV8AAAZiOA From: "Pascal Thubert \(pthubert\)" To: "Christophe Janneteau" X-OriginalArrivalTime: 06 Oct 2004 13:13:00.0565 (UTC) FILETIME=[346C4C50:01C4ABA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah Ng , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Salut Christophe :) > Some comments on your email below. >=20 > Pascal Thubert (pthubert) wrote: > > Let's take examples > > ------------------- > > > > Case 1: MR joins a tree. > > > > Say a MR with an LFN attaches into an existing tree at depth 3. so we > > have: > > Root-MR <- MR1 <- MR2 <- MR . Say LFN starts a connection with CN, and > > say we want to optimize that. > > > > With the assumptions in the quoted text, our MR has to bind its MNP to > > the CN with its careof. But CN does not know how to reach that careof, > > which is from MNP2 (MR2's MNP). So MR2 has to bind MNP2 with its careof > > with CN. Recursively, MR1 and root-MR have to bind to CN as well. > > So we need 4 bindings, which have to be synchronized while maintained > > individually. >=20 > Right. But note that the applications are still maintained even if the > full path for RO is not known at CN (e.g. binding for MR2 missing), and > the path would still be partially optimized. True for an initial binding. Now if there's a movement and the CN has an old state for one hop, then the traffic could be disrupted. =20 >=20 > That said, there may be some ways to speed up and "synchronize" the > sending of the bindings of nested MRs to CN, so that CN gets all of them > "at once". Yes :) One way is to take a snapshot of the path on the way of the packet. >=20 > > On the other hand, if you look at RRH, only the MR that moves sends a > > binding. The BU traces the way out. That's a single BU, with a snapshot > > of the tree at the time of the packet. No state in the intermediate > > routers. No additional BUs that the CN has to correlate together. >=20 > RRH may have advantages, but also has drawbacks (e.g. significant > departure from Basic-NEMO BU semantic, determining optimun number of > slot in RRH header, security, etc...). BTW, It may be too early now to > start comparing solutions, this may turn in an endless thread :) Right. I used that as an example to explain clearly the difference of approach. Specking in general terms is sometimes very opaque. =20 > When doing this exercise one should make sure that all the various > criterias for comparison are taken into account. They also need to be > defined first... >=20 cool > > > > Case 2: Root-MR now changes its point of attachment. > > > > With the assumptions in the quoted text, it has to send one BU to all > > CNs of all the LFNs in the tree. This causes a burst on the network. >=20 > But only Root-MR would sent BU, thus zero overhead is introduced inside > the aggregation while this would not be true with RRH. If RRH is to be > used only in BU messages, then lower MRs in the aggregation need to > discover Root-MR movement in order to send BU...thus extra signalling. > In addition all MRs behind Root-MR will then need to send BUs to update > CNs with their optimized path, thus extra signalling. >=20 > If in-band RRH (i.e. in all data packets) is used then overhead of RRH > header takes place for each packet?... Actually, there are a number of possible optimizations. RRH does not have to be added to all packets. The draft suggests a type 3 that's just a home address in most packets. In the case we discuss, since a movement is detected, then the RRH is forced. > [...] >=20 > > With RRH, MRs might delay the BU for a small amount of time in case > > there's upstream traffic for that CN that would update the RRH cache in > > the CN in-band, avoiding many of the BUs. >=20 > Well, with MR-to-CN BU, only Root-MR would need to send the BU to the > CNs, and of course could arrange not to send the simultaneously to avoid > overhead on the TLMR-RA link... >=20 Right, there needs to be an additional complexity in the MR that moves to pace down the flow of BUs in order not to clog itself even before it clogs the link. But that's not the worst complexity. Figuring out which are the CN is much harder, mostly if ESP is used.=20 > > > > Conclusion > > ---------- > > > > With the assumptions in the quoted text, for each (LFN, CN) that's ROed > > binding, each MR above the LFN in the nested structure needs to send a > > BU to all these CNs when it moves, so that a CN has the chain of BUs > > that enables building a path down the tree. > > > > When a MR moves to a new place in the tree, it has to rebind for all CNs > > down its tree, as we said. But then all MRs above it have to do it too. > > And MRs up its previous location have to stop doing it, otherwise the CN > > is very confused. >=20 > No, I don't think CN will be confused if it still has bindings for the > mobile routers up to MR's previous location. As soon as CN gets the new > MR's binding, it knows that the MR has moved to a new location. This new > location could match the prefix of a new upper mobile router. If CN has > a binding for this new upper-MR is will use it, and route packet along > new-upper-MR CoA and MR CoA. Entries for old-upper-MR is not used and > does not arm at all.... >=20 If the CN only gets extra information that it does not need anymore, that seems right :) I'm afraid of corner cases when a single BU is missing. I do think that the path should be traced in one message so 1) it's simple to parse and 2) it reflects a consistent snapshot of the tree at a given point of time. Pascal From nemo-bounces@ietf.org Wed Oct 6 09:52:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26660 for ; Wed, 6 Oct 2004 09:52:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFC7s-0000yO-Tr; Wed, 06 Oct 2004 09:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFC4i-0000QX-Fz for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:43:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25674 for ; Wed, 6 Oct 2004 09:43:21 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCEC-0003Bp-4a for nemo@ietf.org; Wed, 06 Oct 2004 09:53:13 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C24B22EB7B; Wed, 6 Oct 2004 15:42:50 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 6DBD62EB40; Wed, 6 Oct 2004 15:42:50 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4163EDC8.9070403@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> <4163EDC8.9070403@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L5CnAgIZIVnSX4DOMSXm" Organization: Universidad Carlos III de Madrid Message-Id: <1097070196.2425.72.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 15:43:20 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-L5CnAgIZIVnSX4DOMSXm Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, I don't want to be a pain ;->, I'll try to make this my last comment on this issue... El mi=E9, 06-10-2004 a las 15:06, Alexandru Petrescu escribi=F3: > Chan-Wah Ng wrote: > > However, if we used another example of web-browsing, or=20 > > instant-messaging, the number of data packets generated by the=20 > > application will be smaller per second. In this scenario, the sudden=20 > > surge of sending N * BU messages, where N =3D number of MNNs, may be=20 > > significant. >=20 > I'd think that a real BU storm when train changes AR can only apppear if > all passengers click Reload simultaneously and at the exact moment of > changing AR... Well, not at the exact moment... Binding cache entries have a lifetime, so it is not needed to click the reload button exactly at the moment of the handover is taking place, is it? Kind Regards, Carlos J. >=20 > > Having said that, one still have to relate back to the application=20 > > and user experience. For web-browsing, or IM, the user would most=20 > > likely be quite tolerant of "random" (in the perspective of user)=20 > > increased delay caused by "BU Storm". For video streaming, users=20 > > will be irritated more by sudden delays. >=20 > Yes. >=20 > > Sorry if I seems to be contradicting myself, but I just want to=20 > > explore the issue deeper. >=20 > It's just a discussion, I experience that too. >=20 > >> This is to say I do not think a BU storm is an inconvenient of=20 > >> having MR send BU's on behalf of its MNN's, or LFN's. > >=20 > > You might be surprised, but in fact, I tend to think the same way as > > you do. However, I also felt that it is necessary to include such > > discussions in the draft. >=20 > That's the prerequisite for having a WG item IMHO. >=20 > >> And, if a MR-RO-for-LFN's BU's were stormy in the sense like that=20 > >> of RS's of hosts powering up on a common subnet, would an=20 > >> exponential backoff algorithm limiting and randomizing the order of > >> sent BU's apply as a solution. > >=20 > > True. Shouldn't this be documented in the draft as well? >=20 > Which draft? >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-L5CnAgIZIVnSX4DOMSXm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBY/Zv5vKyPtrWqkARAlQ5AKCsEY+0X/vqRNiO3LAF5jBlmpV11ACfWgs6 zwjn3PIvfxJMmcNMvGa3eMI= =Edfg -----END PGP SIGNATURE----- --=-L5CnAgIZIVnSX4DOMSXm-- From nemo-bounces@ietf.org Wed Oct 6 09:58:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27302 for ; Wed, 6 Oct 2004 09:58:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCF5-0002wI-Kg; Wed, 06 Oct 2004 09:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCAJ-0001ZQ-2P for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26093 for ; Wed, 6 Oct 2004 09:49:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCJm-0003ZS-70 for nemo@ietf.org; Wed, 06 Oct 2004 09:59:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2004 15:59:33 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i96DmQVE020149; Wed, 6 Oct 2004 15:48:34 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 15:48:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2004 15:48:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC28371B@xmb-ams-337.emea.cisco.com> Thread-Topic: RRH (was: Re: BU storms when MR does RO on behalf of LFN's) Thread-Index: AcSrooJWld7gA1ItRu+s49JSo4MZ/gABv//g From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 06 Oct 2004 13:48:28.0696 (UTC) FILETIME=[28E35180:01C4ABAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah Ng Subject: [nemo] RE: RRH (was: Re: BU storms when MR does RO on behalf of LFN's) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > > as well. So we need 4 bindings, which have to be synchronized while > > maintained individually. >=20 > I don't understand, what's the problem with being synchronized while > being maintained individually? When the MR moves into the new tree, all MRs above need to bind with all CNs at that time, so that they reflect a same state of the tree. Yet, they are managed by individual routers.=20 > > The BU storm problem mentioned here is *not* that it would be wrong > > to do RO from the first MR as opposed to LFN (where did you read > > that?). It's about more then the minimum BUs being sent, and BUs > > being sent by the wrong MRs. >=20 > I read in the taxonomy draft that having an MR to send BU's on behalf of > the hosts in the subtree has a cost: BU storm (and 4 other costs too); > section 6.2. Right, it's talking about the subtrees, not the MR MNPs. But maybe we can make it even clearer. =20 > (BTW, what do you call "processing BU's recursively" and "recursive > fashion"? What module/part/function calls upon itself? I don't see > any recursion in processing several incoming BU's and CN _iterating_ > through the BC to build a RH; anyways, be it iteration or recursion, I > don't see the computation burden...) If you take the MR tree as a system, you'll see it. Also, if you look at the process in the CN that goes through its BCEs. All this is unnecessary complexity. Pascal From nemo-bounces@ietf.org Wed Oct 6 09:59:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27430 for ; Wed, 6 Oct 2004 09:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCFj-00032Z-Hm; Wed, 06 Oct 2004 09:54:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCBP-0002A5-Sz for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26271 for ; Wed, 6 Oct 2004 09:50:17 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCKs-0003dS-8D for nemo@ietf.org; Wed, 06 Oct 2004 10:00:09 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96DpVhZ011600; Wed, 6 Oct 2004 06:51:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i96Dn251017322; Wed, 6 Oct 2004 08:49:03 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3F65F88DF9B; Wed, 6 Oct 2004 15:50:12 +0200 (CEST) Message-ID: <4163F80E.6080300@motorola.com> Date: Wed, 06 Oct 2004 15:50:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> <4163EDC8.9070403@motorola.com> <1097070196.2425.72.camel@acorde> In-Reply-To: <1097070196.2425.72.camel@acorde> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3467F937536B0CDB0A96DAC7" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3467F937536B0CDB0A96DAC7 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Carlos Jesús Bernardos Cano wrote: > I don't want to be a pain ;->, I'll try to make this my last comment > on this issue... Not at all a pain! Am I a pain? The pain is when we loose track, I think; the problem should be defined. >>> However, if we used another example of web-browsing, or >>> instant-messaging, the number of data packets generated by the >>> application will be smaller per second. In this scenario, the >>> sudden surge of sending N * BU messages, where N = number of >>> MNNs, may be significant. >> >> I'd think that a real BU storm when train changes AR can only >> apppear if all passengers click Reload simultaneously and at the >> exact moment of changing AR... > > Well, not at the exact moment... Binding cache entries have a > lifetime, so it is not needed to click the reload button exactly at > the moment of the handover is taking place, is it? Ok, so BC entries have lifetimes, and when they're renewed BU's are sent. The lifetime fields in the BC have various values, rarely identical, so no simultaneous BU's sent, no storm, no? Alex --------------enig3467F937536B0CDB0A96DAC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY/gUMmC0w56zj54RAuM5AJ48XEBWaI7A0L1358rrcmgBnYrcLgCff5K9 QJsMBa5ztKO1+vulk3qrg6Y= =njl9 -----END PGP SIGNATURE----- --------------enig3467F937536B0CDB0A96DAC7-- From nemo-bounces@ietf.org Wed Oct 6 10:01:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27579 for ; Wed, 6 Oct 2004 10:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCGB-0003EG-6b; Wed, 06 Oct 2004 09:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCDV-0002W8-71 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 09:52:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26706 for ; Wed, 6 Oct 2004 09:52:26 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCMz-0003sY-Fa for nemo@ietf.org; Wed, 06 Oct 2004 10:02:18 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96DrhhZ013971 for ; Wed, 6 Oct 2004 06:53:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i96DqPmY002623 for ; Wed, 6 Oct 2004 08:52:25 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 09E3188DF9B for ; Wed, 6 Oct 2004 15:52:25 +0200 (CEST) Message-ID: <4163F88E.4050009@motorola.com> Date: Wed, 06 Oct 2004 15:52:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DE256AC44A14F65744601A9" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [nemo] Comments on draft-na-nemo-gen-ro-model-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DE256AC44A14F65744601A9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear authors of draft-na-nemo-gen-ro-model-00, The draft proposes a generic model for RO for moving networks. The model contains 3 generic entities TE (Tunnel Endpoint), TS (Switcher) and TR (Relay) interconnected in a linear topology with a TE at each end and TS's and TR's in between. The model also defines attributes ROI (who's initiating RO), ROR (who's responding) and others such as ROTS, RORI, RODM and ROTT. The draft then maps known RO methods (such as ORC) on the generic RO model and finds that, for the ORC example, the TE is MR, ROI is MR, ROR is an ORC Router and, among attributes, that RODM is IPv6 anycast addressing. The draft is work in progress. Initially I was excited by the abstract saying "we analyze typical RO problems by virtue of that [framework]", because I'm looking for RO problems. However, the current text only contains two short descriptions of such problems: "optimized path" and "nested tunnelling", lightly described. But it is a good reading, that shows that many RO solutions can be effectively classified, like with a taxonomy. It also shows that very many RO solutions are possible (RO solution space is large), which is good. Alex --------------enig2DE256AC44A14F65744601A9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBY/iYMmC0w56zj54RApVOAJ9sRdybvvXs8eTYxUX7WevK9XmzrgCdEIwg b3dmjql9eGHpsMN5+nhWPCU= =fYML -----END PGP SIGNATURE----- --------------enig2DE256AC44A14F65744601A9-- From nemo-bounces@ietf.org Wed Oct 6 10:49:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03721 for ; Wed, 6 Oct 2004 10:49:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFD0e-0001H8-AO; Wed, 06 Oct 2004 10:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCxr-0000fw-PX for nemo@megatron.ietf.org; Wed, 06 Oct 2004 10:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02873 for ; Wed, 6 Oct 2004 10:40:21 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFD7N-00075Q-2Q for nemo@ietf.org; Wed, 06 Oct 2004 10:50:13 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 40F822CC1D; Wed, 6 Oct 2004 16:39:51 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id E495C2CC1A; Wed, 6 Oct 2004 16:39:50 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4163F80E.6080300@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> <4163EDC8.9070403@motorola.com> <1097070196.2425.72.camel@acorde> <4163F80E.6080300@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gKXhcqsNUaii+fsYvchq" Organization: Universidad Carlos III de Madrid Message-Id: <1097073622.2425.91.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 16:40:22 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-gKXhcqsNUaii+fsYvchq Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mi=E9, 06-10-2004 a las 15:50, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > > I don't want to be a pain ;->, I'll try to make this my last comment > > on this issue... >=20 > Not at all a pain! Am I a pain? The pain is when we loose track, I > think; the problem should be defined. OK, then I'll make one more comment ;-> >=20 > >>> However, if we used another example of web-browsing, or=20 > >>> instant-messaging, the number of data packets generated by the=20 > >>> application will be smaller per second. In this scenario, the > >>> sudden surge of sending N * BU messages, where N =3D number of > >>> MNNs, may be significant. > >>=20 > >> I'd think that a real BU storm when train changes AR can only > >> apppear if all passengers click Reload simultaneously and at the > >> exact moment of changing AR... > >=20 > > Well, not at the exact moment... Binding cache entries have a > > lifetime, so it is not needed to click the reload button exactly at > > the moment of the handover is taking place, is it? >=20 > Ok, so BC entries have lifetimes, and when they're renewed BU's are > sent. The lifetime fields in the BC have various values, rarely > identical, so no simultaneous BU's sent, no storm, no? Yes, when the NEMO is not moving, the entries in the BC will likely have different values. But, when the MR moves, it should send BUs to all the CNs, shouldn't it? So some sort-of BU storm happens, IMHO. Kind regards, Carlos J. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-gKXhcqsNUaii+fsYvchq Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZAPW5vKyPtrWqkARApssAKCNHT/Q/NVPfqbCx/p5A/dp4CHvTQCgxo+q Q9KKYq44EH/qeeah5t78Qzk= =7rWk -----END PGP SIGNATURE----- --=-gKXhcqsNUaii+fsYvchq-- From nemo-bounces@ietf.org Wed Oct 6 11:18:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06065 for ; Wed, 6 Oct 2004 11:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDX4-0001Dq-Q3; Wed, 06 Oct 2004 11:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDSm-0000Zu-9Y for nemo@megatron.ietf.org; Wed, 06 Oct 2004 11:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05693 for ; Wed, 6 Oct 2004 11:12:17 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDcH-0000eY-Di for nemo@ietf.org; Wed, 06 Oct 2004 11:22:10 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96FDXhZ012219; Wed, 6 Oct 2004 08:13:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i96FCEs6019136; Wed, 6 Oct 2004 10:12:15 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 78D8988DF9B; Wed, 6 Oct 2004 17:12:14 +0200 (CEST) Message-ID: <41640B48.2000604@motorola.com> Date: Wed, 06 Oct 2004 17:12:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> <4163EDC8.9070403@motorola.com> <1097070196.2425.72.camel@acorde> <4163F80E.6080300@motorola.com> <1097073622.2425.91.camel@acorde> In-Reply-To: <1097073622.2425.91.camel@acorde> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3134A8C535FF02C93229624C" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3134A8C535FF02C93229624C Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Carlos Jesús Bernardos Cano wrote: >>>>> However, if we used another example of web-browsing, or >>>>> instant-messaging, the number of data packets generated by >>>>> the application will be smaller per second. In this scenario, >>>>> the sudden surge of sending N * BU messages, where N = >>>>> number of MNNs, may be significant. >>>> >>>> I'd think that a real BU storm when train changes AR can only >>>> apppear if all passengers click Reload simultaneously and at >>>> the exact moment of changing AR... >>> >>> Well, not at the exact moment... Binding cache entries have a >>> lifetime, so it is not needed to click the reload button exactly >>> at the moment of the handover is taking place, is it? >> >> Ok, so BC entries have lifetimes, and when they're renewed BU's are >> sent. The lifetime fields in the BC have various values, rarely >> identical, so no simultaneous BU's sent, no storm, no? > > Yes, when the NEMO is not moving, the entries in the BC will likely > have different values. But, when the MR moves, it should send BUs to > all the CNs, shouldn't it? So some sort-of BU storm happens, IMHO. Exactly. So in order to avoid the "sort-of BU storm" let's use rate limitation. Hopefully MR will act like an RFC3775 MN: "The mobile node is responsible for retransmissions and rate limiting in the return routability procedure, registrations, and in solicited prefix discovery." If we say, like the taxonomy draft says, that because MR sends BU to CN's then BU storms appear, the immediate thought is to think "don't let MR send BU's to CN's". If we say, however, that an MR not using rate limiting may provoke BU storms (easier than MH would provoke), then the immediate thought is to think "use rate limiting". Alex --------------enig3134A8C535FF02C93229624C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZAtOMmC0w56zj54RAlkTAKDTA1yhVw1ovIwnWuWM6W+lZ3Ur5ACeNWw8 7vK9ieaq/kqx8RFqN7c6eAM= =EI0q -----END PGP SIGNATURE----- --------------enig3134A8C535FF02C93229624C-- From nemo-bounces@ietf.org Wed Oct 6 11:37:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07356 for ; Wed, 6 Oct 2004 11:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDnZ-000457-IU; Wed, 06 Oct 2004 11:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDhs-00035y-5F for nemo@megatron.ietf.org; Wed, 06 Oct 2004 11:27:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06765 for ; Wed, 6 Oct 2004 11:27:53 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDrO-0001ad-AP for nemo@ietf.org; Wed, 06 Oct 2004 11:37:46 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i96FT9hZ029500; Wed, 6 Oct 2004 08:29:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i96FRos6018390; Wed, 6 Oct 2004 10:27:51 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E2E6588DF9B; Wed, 6 Oct 2004 17:27:49 +0200 (CEST) Message-ID: <41640EF0.50500@motorola.com> Date: Wed, 06 Oct 2004 17:27:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao References: <200410040657.i946vZNX025909@tremex.ucdavis.edu> In-Reply-To: <200410040657.i946vZNX025909@tremex.ucdavis.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5716089206E253E7A667D664" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org Subject: [nemo] Re: Comments on ROProblem.doc (was: NEMO RO Problem) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5716089206E253E7A667D664 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Fan Zhao wrote: > Dear all, > > I wrote a document about NEMO RO problem, please click the following > link to see the details: > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > > This document benefits from a lot of discussions and drafts. It is > still a preliminary version, so there are still a lot of questions. > For example, Alex said that the charter does not requires dealing > with multi-homing and NEMO RO. IMO, the requirement that RO solution > should function for multi-homing NEMO networks and should not > conflict with multi-homing mechanism seems OK. We may also take a > stepwise approach to solve multi-homing and RO issues. Thanks for > your comments. Dear Fan, I've read the document and have comments on it. Please submit it as an Internet Draft, should be easy. If problems formatting, boilerplate, deadlines, whatever - I can help. The document is longish and tries to do many things. Not only it looks at defining a NEMO problem in great detail, but it also offers goals for RO, Rx requirements and even RO performance evaluation metrics. > As it has been understood for a long time that the routing path in > the Internet is asymmetric The path taken by packets of the same session between two fixed communicating ends depends on the order of the src and dst fields. Same end's outgoing and incoming packets may take different paths. Also, packets of the same session and in the same direction, may take different paths, varying with time and network load. > More preciously, location precisely > Although in MIPv6 the Care-of-Address represents the location of > attachment to the Internet, a single Care-of-Address is not > sufficient any more to represent the location of VMN/MR in nested > NEMO because it sometimes represents the point of attachment to the > upper level of mobile network. I don't understand this. Why is it necessary to have more than one CoA to represent the location of a VMN/MR in a nested NEMO? > The “optimal route” inside the NEMO network is formed by the decision > of each MR along the outbound and inbound path An "optimal route" is formed by route segments, not by "decisions" no? > When MRi associates with MRj, it may choose MRj as the default router > Yes ok, but I don't know where this leads to. "Looping problems"? > The inbound path inside the nested NEMO may be different from the > outbound path. However, since the route inside the NEMO network does > not involve HA, the optimal route is based on the decision of each > MR. ...is based only on the decision of MR's, and not that of the remote HA's. > If the intersection of p1 and p2 is not empty, denoted by MR_1,i2, …, MR_1,ik> = where i1 < i2 < > … < ik and j1 < j2 < … < jk. If it is not empty then what? Premature end? > Ideally the optimal path between node1 and node2 is …, MR_1,i1, …, MR_2,2, MR_2,1>. I do not see what the second indices represent (1,2,i1,2,1). Maybe a graphical picture would be suggestive. What is in plain English the optimal path? The one that is the intersection of the two sets? > Worse than MIPv6, in nested NEMO network the packets are forwarded to > multiple intermediate boxes ... (the HA's) > As a TCP/UDP connection is identified by a 4-tuple address, source port, destination IP address, destination port>, in > order to maintain the continuous session, the end point must use the > same IP addresses during the session. Not only for TCP connections are the stable IP addresses needed, but also for ICMP (ping). > As IP address perfectly represents both identity and location of end > host in the fixed network, we usually just put emphasis on one and > sometimes even mix their meanings. However, in the mobile network > environment, we need to represent the binding between identity and > location that is what the binding between home- address and > care-of-address does. > Similar with MIPv4 and MIPv6, NEMO focuses on the solution in data > plane rather than in the signaling plane What's the data and signalling planes? Is a BU signalling plane? > a RO solution in data plane may qualify as a necessary step before An RO solution would most probably use BU's, is this data or signalling? > a nature extension natural... > MR may choose to perform RO function just with its HA if the number > of different CNs is large and all CNs scatter around the Internet Is this equivalent to saying MR may choose to _not_ do RO? I don't see how MR does RO only with its HA. > 1.7.4 Security vs. optimal route In NEMO basic support, it is very > possible that there pre-exists the security association between MR > and HA, which helps resist the various attack. However in NMEO RO > solution, as the MR-HA tunnel may not exist and there is no > pre-existing security association between two entities from the > different domains, it is more challenging to maintain the same > security strength as in NEMO basic support. An insecure RO solution for mobile hosts risks a CN and a MH. An insecure RO solution for NEMO risks not only CN and MH but also the bunch of LFN's in the moving network. It is difficult to do per-host RR tests (as currently RFC3775 does) for all the hosts within the MNP. Alex --------------enig5716089206E253E7A667D664 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZA71MmC0w56zj54RAv9CAJ0ZZU9PHjD4NAy+E1QUakZvnHHYxACfbQZt OutA+pdtD52TtprMNVUrAuo= =znzk -----END PGP SIGNATURE----- --------------enig5716089206E253E7A667D664-- From nemo-bounces@ietf.org Wed Oct 6 12:00:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08939 for ; Wed, 6 Oct 2004 12:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEAx-0000YO-GC; Wed, 06 Oct 2004 11:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFE3i-0007bn-Sb for nemo@megatron.ietf.org; Wed, 06 Oct 2004 11:50:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08319 for ; Wed, 6 Oct 2004 11:50:28 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFEDE-00036t-6N for nemo@ietf.org; Wed, 06 Oct 2004 12:00:21 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id i96FqdC3004775 for ; Wed, 6 Oct 2004 08:52:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i96FgP1h006782 for ; Wed, 6 Oct 2004 10:42:26 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 870C788DF9B for ; Wed, 6 Oct 2004 17:50:23 +0200 (CEST) Message-ID: <41641439.9080902@motorola.com> Date: Wed, 06 Oct 2004 17:50:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB3CECE31A8F954134EACD05" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [nemo] RO Problem snippets X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB3CECE31A8F954134EACD05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I went through various drafts related to RO problem statement and I extracted the following snippets. Is this all? > RO problems have a common property that there is an optimized path, > but it cannot be used > > One of NEMO-specific RO problem is a nested tunneling problem > > ... it results in a non-optimal route (triangle-routing) between > > By using IP-in-IP header [...] causes big overheads in packet payload > and bandwidth. > > NEMO RO problem introduces more challenges and more difficulties than > MIPv6 RO problem because of nested NEMO network > > Without NEMO RO solution, the performance becomes worse especially in > nested NEMO. > > Location Privacy problem > > Looping problem > > "Cross-over" tunnels problem > > Disconnected operation problem > > Packets destined to the mobile node will have to be routed not only > to its home agent but also the home agent of the mobile router. > > With no Nested Tunnels Optimization, we would have three > bi-directional nested tunnels > > "Pinball" routing > > BU Storm > > Protocol Hacks > > Computation Burden of the CN > > Missing BU > > Obsolete BU > > The RR test prevents a MR-LFN dichotomy on the Mobile Side > > The RR test has no negotiable option and is not open for extension > > The HaO and RH type 2 are designed for a collocated CareOf Address. Alex --------------enigEB3CECE31A8F954134EACD05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZBQ/MmC0w56zj54RAizjAKCgxiMR0sUXqHRzre/uALdUSLte3ACcDH3T SdPT56lcMnthhgkt9ey7/TY= =/DTn -----END PGP SIGNATURE----- --------------enigEB3CECE31A8F954134EACD05-- From nemo-bounces@ietf.org Wed Oct 6 12:09:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09306 for ; Wed, 6 Oct 2004 12:09:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFECm-00018h-8Z; Wed, 06 Oct 2004 11:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFE9W-0008Vo-V6 for nemo@megatron.ietf.org; Wed, 06 Oct 2004 11:56:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08690 for ; Wed, 6 Oct 2004 11:56:28 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFEJ2-0003Ri-G2 for nemo@ietf.org; Wed, 06 Oct 2004 12:06:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2004 18:06:49 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i96FtAVa022365; Wed, 6 Oct 2004 17:55:47 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 17:55:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: BU storms when MR does RO on behalf of LFN's Date: Wed, 6 Oct 2004 17:51:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: BU storms when MR does RO on behalf of LFN's Thread-Index: AcSrt8fzQIFduLePSd6SXGnzQ5NXAgABCQ2A From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 06 Oct 2004 15:55:11.0269 (UTC) FILETIME=[DC5FE550:01C4ABBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > If we say, like the taxonomy draft says, that because MR sends BU to > CN's then BU storms appear, the immediate thought is to think "don't = let > MR send BU's to CN's". Sorry, that was not intended at all.=20 =20 > If we say, however, that an MR not using rate limiting may provoke BU > storms (easier than MH would provoke), then the immediate thought is = to > think "use rate limiting". One immediate thought is "design so that there's an absolute minimum = amount of BUs to be sent". Then, I do agree, shape the storm as much as you can. But any delay is a = window for packet loss, so we must be very careful. Pascal From nemo-bounces@ietf.org Wed Oct 6 12:09:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09341 for ; Wed, 6 Oct 2004 12:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFECm-000190-UO; Wed, 06 Oct 2004 11:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFE9t-0000Gh-Cu for nemo@megatron.ietf.org; Wed, 06 Oct 2004 11:56:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08707 for ; Wed, 6 Oct 2004 11:56:50 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFEJN-0003Ru-IJ for nemo@ietf.org; Wed, 06 Oct 2004 12:06:44 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BE3EC401AC; Wed, 6 Oct 2004 17:56:18 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 626B3401C0; Wed, 6 Oct 2004 17:56:18 +0200 (CEST) Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <41640B48.2000604@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D8AB.5010400@motorola.com> <1097050935.9783.110.camel@localhost> <4163EDC8.9070403@motorola.com> <1097070196.2425.72.camel@acorde> <4163F80E.6080300@motorola.com> <1097073622.2425.91.camel@acorde> <41640B48.2000604@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Jj4B0bofKnzoHmvSrJom" Organization: Universidad Carlos III de Madrid Message-Id: <1097078209.2425.127.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 17:56:49 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Jj4B0bofKnzoHmvSrJom Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mi=E9, 06-10-2004 a las 17:12, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > >>>>> However, if we used another example of web-browsing, or=20 > >>>>> instant-messaging, the number of data packets generated by=20 > >>>>> the application will be smaller per second. In this scenario, > >>>>> the sudden surge of sending N * BU messages, where N =3D > >>>>> number of MNNs, may be significant. > >>>>=20 > >>>> I'd think that a real BU storm when train changes AR can only=20 > >>>> apppear if all passengers click Reload simultaneously and at=20 > >>>> the exact moment of changing AR... > >>>=20 > >>> Well, not at the exact moment... Binding cache entries have a=20 > >>> lifetime, so it is not needed to click the reload button exactly=20 > >>> at the moment of the handover is taking place, is it? > >>=20 > >> Ok, so BC entries have lifetimes, and when they're renewed BU's are > >> sent. The lifetime fields in the BC have various values, rarely=20 > >> identical, so no simultaneous BU's sent, no storm, no? > >=20 > > Yes, when the NEMO is not moving, the entries in the BC will likely=20 > > have different values. But, when the MR moves, it should send BUs to=20 > > all the CNs, shouldn't it? So some sort-of BU storm happens, IMHO. >=20 > Exactly. >=20 > So in order to avoid the "sort-of BU storm" let's use rate limitation. > Hopefully MR will act like an RFC3775 MN: "The mobile node is > responsible for retransmissions and rate limiting in the return > routability procedure, registrations, and in solicited prefix discovery." >=20 > If we say, like the taxonomy draft says, that because MR sends BU to=20 > CN's then BU storms appear, the immediate thought is to think "don't let=20 > MR send BU's to CN's". >=20 I completely agree > If we say, however, that an MR not using rate limiting may provoke BU=20 > storms (easier than MH would provoke), then the immediate thought is to=20 > think "use rate limiting". I agree again ;-> Kind Regards, Carlos J. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-Jj4B0bofKnzoHmvSrJom Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZBXB5vKyPtrWqkARAkcZAKDVnN30iCwFmgNYl9O931L/sZkAtQCgm8DH Luz/l7h2J1hgEJtlwgnP9GU= =nm9n -----END PGP SIGNATURE----- --=-Jj4B0bofKnzoHmvSrJom-- From nemo-bounces@ietf.org Wed Oct 6 12:32:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10885 for ; Wed, 6 Oct 2004 12:32:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEgn-00081W-8D; Wed, 06 Oct 2004 12:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEcR-0007HQ-Dj for nemo@megatron.ietf.org; Wed, 06 Oct 2004 12:26:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10402 for ; Wed, 6 Oct 2004 12:26:20 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFElx-0005Mh-Cv for nemo@ietf.org; Wed, 06 Oct 2004 12:36:14 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2294C2CCB4; Wed, 6 Oct 2004 18:25:47 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id BF76F2CC88; Wed, 6 Oct 2004 18:25:46 +0200 (CEST) Subject: Re: [nemo] RO Problem snippets From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <41641439.9080902@motorola.com> References: <41641439.9080902@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-N4koQX7Ftx/6D/slGZg3" Organization: Universidad Carlos III de Madrid Message-Id: <1097079977.2425.146.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 18:26:18 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-N4koQX7Ftx/6D/slGZg3 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, First, thanks for providing this list! Then, some minor comments/questions in-line El mi=E9, 06-10-2004 a las 17:50, Alexandru Petrescu escribi=F3: > I went through various drafts related to RO problem statement and I > extracted the following snippets. Is this all? >=20 > > RO problems have a common property that there is an optimized path,=20 > > but it cannot be used > >=20 > > One of NEMO-specific RO problem is a nested tunneling problem > >=20 > > ... it results in a non-optimal route (triangle-routing) between > >=20 > > By using IP-in-IP header [...] causes big overheads in packet payload > > and bandwidth. IMHO, not only IP-in-IP header causes big overheads. The use of routing headers and/or Home Address DO adds also overhead (IMHO they can be seen also as sort-of tunnels), so their use should be minimised (e.g. number of hops in a routing header, etc) > >=20 > > NEMO RO problem introduces more challenges and more difficulties than > > MIPv6 RO problem because of nested NEMO network IMHO, as I understand the Network Mobility problem (i.e. mobility of a whole network managed by a single entity: the MR, and with the MNNs even unaware of the mobility - at least the LFNs), I think that the requirement of providing such a (optimised) solution that maintains this transparency to the MNNs is also challenging. I'm not saying that the RO solutions based on NEMO-aware MNNs are not valid, but that one of the key differenced between Network Mobility and Terminal Mobility IMHO is that the nodes that are actually moving can be totally unaware of the movement (and that those nodes should profit of some route optimisation if possible). > >=20 > > Without NEMO RO solution, the performance becomes worse especially in > > nested NEMO. > >=20 > > Location Privacy problem > >=20 > > Looping problem > >=20 > > "Cross-over" tunnels problem > >=20 > > Disconnected operation problem I'm not sure if it's included in this snippet (probably, it is), but the RO solutions should be also take into account communications between nodes of different NEMOs within a nested topology. I mean, not only ensuring that the nodes can communicate when the NEMO is disconnected from the infrastructure, but also that this communication is somehow optimised. BTW, I'm not sure if this makes any sense... just writing what come up from my mind ;-> > >=20 > > Packets destined to the mobile node will have to be routed not only=20 > > to its home agent but also the home agent of the mobile router. > >=20 > > With no Nested Tunnels Optimization, we would have three=20 > > bi-directional nested tunnels > >=20 > > "Pinball" routing > >=20 > > BU Storm > >=20 > > Protocol Hacks > >=20 > > Computation Burden of the CN > >=20 > > Missing BU > >=20 > > Obsolete BU > >=20 > > The RR test prevents a MR-LFN dichotomy on the Mobile Side > >=20 > > The RR test has no negotiable option and is not open for extension > >=20 > > The HaO and RH type 2 are designed for a collocated CareOf Address. I'd add one more (although it's likely implicit): security And also a question, do we want to address the RO problem when multihoming is also involved? Thanks a lot. Kind Regards, Carlos J. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-N4koQX7Ftx/6D/slGZg3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZByp5vKyPtrWqkARAoUJAKCvysYyQNnSKAWf8Zn0JYGaDnYLYQCfTsj8 vvbtACed0X2LciCbVCg3vnw= =qUrS -----END PGP SIGNATURE----- --=-N4koQX7Ftx/6D/slGZg3-- From nemo-bounces@ietf.org Wed Oct 6 12:43:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11428 for ; Wed, 6 Oct 2004 12:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEqv-000128-8q; Wed, 06 Oct 2004 12:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEl4-0000F3-NH for nemo@megatron.ietf.org; Wed, 06 Oct 2004 12:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11076 for ; Wed, 6 Oct 2004 12:35:15 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFEub-0005xq-Av for nemo@ietf.org; Wed, 06 Oct 2004 12:45:09 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i96GaQsU024128; Wed, 6 Oct 2004 09:36:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i96EYs7c012788; Wed, 6 Oct 2004 09:34:55 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0B0C488DF9B; Wed, 6 Oct 2004 18:35:13 +0200 (CEST) Message-ID: <41641EBB.3050302@motorola.com> Date: Wed, 06 Oct 2004 18:35:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5377E013642866015F22F329" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF NEMO WG , Chan-Wah Ng , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5377E013642866015F22F329 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> If we say, like the taxonomy draft says, that because MR sends BU >> to CN's then BU storms appear, the immediate thought is to think >> "don't let MR send BU's to CN's". > > Sorry, that was not intended at all. Ok. And what _was_ intended by mentioning the BU storm? >> If we say, however, that an MR not using rate limiting may provoke >> BU storms (easier than MH would provoke), then the immediate >> thought is to think "use rate limiting". > > One immediate thought is "design so that there's an absolute minimum > amount of BUs to be sent". Yes, that sounds like an Rx requirement (Rx like R1, R2... R3 requirements in the goals and requirements document). IMHO, a problem should sound like this "the problem is that paths are so long, really long". It should not invite for a solution or a requirement, just say the problem. I'm usually very hesitant to talk about problems because whatever kind of problem one may imagine then a solution pops up immediately, ending in an argument that there is no problem, or worse, in a too early competition of solution drafts (or "war") :-) Alex --------------enig5377E013642866015F22F329 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZB7AMmC0w56zj54RAq7zAKDFnBS/vAgXkYUpYpvZq0XMWnLxugCgks7b wF5gesTrghpDIQHfslk39go= =zWs2 -----END PGP SIGNATURE----- --------------enig5377E013642866015F22F329-- From nemo-bounces@ietf.org Wed Oct 6 13:03:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12874 for ; Wed, 6 Oct 2004 13:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFA3-0004CJ-DP; Wed, 06 Oct 2004 13:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFF6b-0003r2-Bn for nemo@megatron.ietf.org; Wed, 06 Oct 2004 12:57:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12547 for ; Wed, 6 Oct 2004 12:57:30 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFFG7-0007Qr-Az for nemo@ietf.org; Wed, 06 Oct 2004 13:07:24 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i96GvxCG028631; Wed, 6 Oct 2004 09:58:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i96Gt3NK032367; Wed, 6 Oct 2004 11:55:03 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4A7BB88DF9B; Wed, 6 Oct 2004 18:57:15 +0200 (CEST) Message-ID: <416423E5.2060804@motorola.com> Date: Wed, 06 Oct 2004 18:57:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] RO Problem snippets References: <41641439.9080902@motorola.com> <1097079977.2425.146.camel@acorde> In-Reply-To: <1097079977.2425.146.camel@acorde> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34D9B3B91A0DA190EEC03508" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34D9B3B91A0DA190EEC03508 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Carlos Jesús Bernardos Cano wrote: >>> By using IP-in-IP header [...] causes big overheads in packet >>> payload and bandwidth. > > IMHO, not only IP-in-IP header causes big overheads. The use of > routing headers and/or Home Address DO adds also overhead (IMHO they > can be seen also as sort-of tunnels), so their use should be > minimised (e.g. number of hops in a routing header, etc) Agree. So talk to the author of that draft if you need it corrected, suggest him/her a better and shorter text and you're done. >>> NEMO RO problem introduces more challenges and more difficulties >>> than MIPv6 RO problem because of nested NEMO network > > IMHO, as I understand the Network Mobility problem (i.e. mobility of > a whole network managed by a single entity: the MR, and with the > MNNs even unaware of the mobility - at least the LFNs), I think that > the requirement of providing such a (optimised) solution that > maintains this transparency to the MNNs is also challenging. I'm not > saying that the RO solutions based on NEMO-aware MNNs are not valid, > but that one of the key differenced between Network Mobility and > Terminal Mobility IMHO is that the nodes that are actually moving can > be totally unaware of the movement (and that those nodes should > profit of some route optimisation if possible). So it is a requirement Rx that a NEMO RO solution still allows for LFN's to not be mobility aware. >>> Without NEMO RO solution, the performance becomes worse >>> especially in nested NEMO. >>> >>> Location Privacy problem >>> >>> Looping problem >>> >>> "Cross-over" tunnels problem >>> >>> Disconnected operation problem > > I'm not sure if it's included in this snippet (probably, it is) YEs I think it is. > but the RO solutions should be also take into account communications > between nodes of different NEMOs within a nested topology. I mean, > not only ensuring that the nodes can communicate when the NEMO is > disconnected from the infrastructure, but also that this > communication is somehow optimised. BTW, I'm not sure if this makes > any sense... just writing what come up from my mind ;-> I think it does make sense but you've just written new requirements. What's the problem itself? What's the problem of not having optimized communications between two nodes within the nested topology of moving networks? If we had a solution to the "disconnected operation problem" what part of that potential solution would make the intra-aggregation communication be under-optimal? > I'd add one more (although it's likely implicit): security Yes, so what's the snippet? > And also a question, do we want to address the RO problem when > multihoming is also involved? Some WG members agree that the RO problem should include multihoming RO aspects. I personally IMHO think that multihoming aspects have not been clarified not even for the base NEMO protocol (not that it should have); I don't think that there's anything in "multihoming" that makes it sound more appealing to RO than to base NEMO. Caution: do not understand me wrong. I am not saying that multihoming is bad or not good. It's good to have two egress interfaces so that if one goes down the other takes its place. It's just that up to now it looked so much as a problem w/o a NEMO solution (so we get problem and classification drafts and joined classification drafts). But it's not like a problem that we know how to tackle at all, there are so many ways of addressing "multi-homing". Or, with NEMO base, we knew it was relying on Mobile IP... No offence intended and IMHO. Alex --------------enig34D9B3B91A0DA190EEC03508 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZCPrMmC0w56zj54RAsYsAJ9V9Zi4515igKhAKmgvYM5cMnHkUQCcDGqz iU8bg3XO8JL6pLhOjuI9Q5Q= =/EWq -----END PGP SIGNATURE----- --------------enig34D9B3B91A0DA190EEC03508-- From nemo-bounces@ietf.org Wed Oct 6 13:18:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14240 for ; Wed, 6 Oct 2004 13:18:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFOy-0006qs-CK; Wed, 06 Oct 2004 13:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFOB-0006kD-Oh for nemo@megatron.ietf.org; Wed, 06 Oct 2004 13:15:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13995 for ; Wed, 6 Oct 2004 13:15:40 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFFXi-00005e-J7 for nemo@ietf.org; Wed, 06 Oct 2004 13:25:35 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 05DC62EC85; Wed, 6 Oct 2004 19:15:11 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 9DFDF2E9CB; Wed, 6 Oct 2004 19:15:10 +0200 (CEST) Subject: Re: [nemo] RO Problem snippets From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <416423E5.2060804@motorola.com> References: <41641439.9080902@motorola.com> <1097079977.2425.146.camel@acorde> <416423E5.2060804@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6qnU6G9OpE5yIfJ4lTfU" Organization: Universidad Carlos III de Madrid Message-Id: <1097082940.2425.163.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 19:15:41 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-6qnU6G9OpE5yIfJ4lTfU Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mi=E9, 06-10-2004 a las 18:57, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > >>> By using IP-in-IP header [...] causes big overheads in packet=20 > >>> payload and bandwidth. > >=20 > > IMHO, not only IP-in-IP header causes big overheads. The use of=20 > > routing headers and/or Home Address DO adds also overhead (IMHO they > > can be seen also as sort-of tunnels), so their use should be=20 > > minimised (e.g. number of hops in a routing header, etc) >=20 > Agree. So talk to the author of that draft if you need it corrected, > suggest him/her a better and shorter text and you're done. OK >=20 > >>> NEMO RO problem introduces more challenges and more difficulties > >>> than MIPv6 RO problem because of nested NEMO network > >=20 > > IMHO, as I understand the Network Mobility problem (i.e. mobility of > > a whole network managed by a single entity: the MR, and with the > > MNNs even unaware of the mobility - at least the LFNs), I think that > > the requirement of providing such a (optimised) solution that > > maintains this transparency to the MNNs is also challenging. I'm not > > saying that the RO solutions based on NEMO-aware MNNs are not valid, > > but that one of the key differenced between Network Mobility and > > Terminal Mobility IMHO is that the nodes that are actually moving can > > be totally unaware of the movement (and that those nodes should > > profit of some route optimisation if possible). >=20 > So it is a requirement Rx that a NEMO RO solution still allows for LFN's > to not be mobility aware >=20 > >>> Without NEMO RO solution, the performance becomes worse=20 > >>> especially in nested NEMO. > >>>=20 > >>> Location Privacy problem > >>>=20 > >>> Looping problem > >>>=20 > >>> "Cross-over" tunnels problem > >>>=20 > >>> Disconnected operation problem > >=20 > > I'm not sure if it's included in this snippet (probably, it is) >=20 > YEs I think it is. >=20 > > but the RO solutions should be also take into account communications > > between nodes of different NEMOs within a nested topology. I mean,=20 > > not only ensuring that the nodes can communicate when the NEMO is=20 > > disconnected from the infrastructure, but also that this=20 > > communication is somehow optimised. BTW, I'm not sure if this makes=20 > > any sense... just writing what come up from my mind ;-> >=20 > I think it does make sense but you've just written new requirements. > What's the problem itself? What's the problem of not having optimized > communications between two nodes within the nested topology of moving > networks? Yes, you are right, they are requirements. I was thinking in the overhead problem if some tunneling is used to enable this communication within a nested NEMO. >=20 > If we had a solution to the "disconnected operation problem" what part > of that potential solution would make the intra-aggregation > communication be under-optimal? It depends on how this solution works, but it's just the endless problem: making the things work, but working as better as possible :-> (i.e. allow NEMOs to work disconnected, but also with minor overhead, and so on...) >=20 > > I'd add one more (although it's likely implicit): security >=20 > Yes, so what's the snippet? Just to address the security issues of the RO problem within NEMO (some may be the same of MIPv6, some may be new) >=20 > > And also a question, do we want to address the RO problem when=20 > > multihoming is also involved? >=20 > Some WG members agree that the RO problem should include multihoming RO > aspects. I personally IMHO think that multihoming aspects have not been > clarified not even for the base NEMO protocol (not that it should have); > I don't think that there's anything in "multihoming" that makes it sound > more appealing to RO than to base NEMO. >=20 > Caution: do not understand me wrong. I am not saying that multihoming > is bad or not good. It's good to have two egress interfaces so that if > one goes down the other takes its place. It's just that up to now > it looked so much as a problem w/o a NEMO solution (so we get problem > and classification drafts and joined classification drafts). But it's > not like a problem that we know how to tackle at all, there are so many > ways of addressing "multi-homing". Or, with NEMO base, we knew it was > relying on Mobile IP... No offence intended and IMHO. I agree that the multihoming aspects in NEMO are still unclear. I just wanted to point out that IMHO we should be careful in defining RO solutions that are compatible with multihoming scenarios. Thanks for your comments and clarifications. Kind Regards, Carlos J. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-6qnU6G9OpE5yIfJ4lTfU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZCg85vKyPtrWqkARApbdAJ9IwhHZM08xq7Xy2gaDqMF32DeargCgkVI8 YSr/iT/VCOWBh7OVv99kE5o= =KjFC -----END PGP SIGNATURE----- --=-6qnU6G9OpE5yIfJ4lTfU-- From nemo-bounces@ietf.org Wed Oct 6 22:32:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12305 for ; Wed, 6 Oct 2004 22:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFO3S-0005hK-UH; Wed, 06 Oct 2004 22:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFO1s-0005Nz-AG for nemo@megatron.ietf.org; Wed, 06 Oct 2004 22:29:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12171 for ; Wed, 6 Oct 2004 22:29:13 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFOBT-00061I-OC for nemo@ietf.org; Wed, 06 Oct 2004 22:39:12 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i972Q2Fr016114; Thu, 7 Oct 2004 10:26:02 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id D7E9BB240CC; Thu, 7 Oct 2004 10:32:34 +0800 (SGT) Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4163E9CD.3090106@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> <1097047017.9783.81.camel@localhost> <4163E9CD.3090106@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1097116354.9209.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 10:32:34 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-10-06 at 20:49, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > >> I agree with the DO containing the HoA means no zero-encapsulation > >> and overhead. I don't see how a NEMO-RO solution can hope to > >> achieve zero overhead with existing routing infrastructure, but I > >> see how a NEMO-RO solution can achieve zero-overhead without the > >> existing (and not any other) infrastructure. That is, if the > >> aggregatation of moving networks is disconnected from the > >> infrastructure, then it is possible to have that zero-overhead, no > >> routing header, no DO. > >> > > Ah, I see. It means we use a different address space for NEMO-RO so > > that these address are not routed using aggregation, but rely on the > > mobile router running some kind of dynamic routing protocol. > > No, it means that when you have an aggregation of moving networks whose > TLMR is disconnected (no infrastructure), there should be a way to make > those networks talk to each other without RH's nor DO's. > Okay, I see. Isn't that threading a bit too close to MANET? > >> If there were no NEMO-based MR, and if every MN in the train is > >> connecting to the successive AR's along the track, and if every MN > >> is having a continuous communication, then the number of BU's is > >> exactly the number of MN's, yes. But if any of those 'if's is not > >> then no storm. > > > > You statement maybe correct, again it depends on the solution of > > NEMO-RO. That's why the draft as a problem analysis draft should > > discuss it. > > YEs, depends on the solution. A problem statement draft for route > optimization should discuss it and look in a non-biased way at various > approaches to solve this problem... Agree whole-heartedly. It is my intent to address the concern of the draft being too, should I say, solution-specific. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 6 22:53:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13553 for ; Wed, 6 Oct 2004 22:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFONj-0000lg-Ku; Wed, 06 Oct 2004 22:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFOM5-0000TU-6l for nemo@megatron.ietf.org; Wed, 06 Oct 2004 22:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13234 for ; Wed, 6 Oct 2004 22:50:06 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFOVg-0007Gs-VP for nemo@ietf.org; Wed, 06 Oct 2004 23:00:05 -0400 Received: from cucujus.ucdavis.edu (cucujus.ucdavis.edu [169.237.104.179]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i972o4u6028689; Wed, 6 Oct 2004 19:50:04 -0700 (PDT) Received: from cucujus.ucdavis.edu (localhost [127.0.0.1]) by cucujus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i972o4e5023257; Wed, 6 Oct 2004 19:50:04 -0700 (PDT) Received: (from www@localhost) by cucujus.ucdavis.edu (8.12.10/8.12.9/Submit) id i972o4XO023256; Wed, 6 Oct 2004 19:50:04 -0700 (PDT) Date: Wed, 6 Oct 2004 19:50:04 -0700 (PDT) Message-Id: <200410070250.i972o4XO023256@cucujus.ucdavis.edu> To: Alexandru Petrescu From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.49.8] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: nemo@ietf.org Subject: [nemo] Re: Comments on ROProblem.doc (was: NEMO RO Problem) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Alex, Thank you very much for your comments. Please see the details in line. Best regards, fan > Dear Fan, I've read the document and have comments on it. > > Please submit it as an Internet Draft, should be easy. If problems > formatting, boilerplate, deadlines, whatever - I can help. Thanks for your encouragements. I really appreciate your help. > > The document is longish and tries to do many things. Not only it looks > at defining a NEMO problem in great detail, but it also offers goals for > RO, Rx requirements and even RO performance evaluation metrics. > I can narrow down the scope of draft based on the requirements of WG. > > As it has been understood for a long time that the routing path in > > the Internet is asymmetric > > The path taken by packets of the same session between two fixed > communicating ends depends on the order of the src and dst fields. Same > end's outgoing and incoming packets may take different paths. Also, > packets of the same session and in the same direction, may take > different paths, varying with time and network load. > Exactly. > > More preciously, location > > precisely > Yes, thanks. > > Although in MIPv6 the Care-of-Address represents the location of > > attachment to the Internet, a single Care-of-Address is not > > sufficient any more to represent the location of VMN/MR in nested > > NEMO because it sometimes represents the point of attachment to the > > upper level of mobile network. > > I don't understand this. Why is it necessary to have more than one > CoA to represent the location of a VMN/MR in a nested NEMO? > Except the case of root-MR, one CoA represents the location inside the mobile network associated with MR. In the nested NEMO, MR/VMN/LFN (except root-MR) is not accessible by using its CoA as the destination IP address without being forwarded by HA. The “location” here is the position relative to the Internet. > > The “optimal route” inside the NEMO network is formed by the decision > > of each MR along the outbound and inbound path > > An "optimal route" is formed by route segments, not by "decisions" no? > In the outbound direction, MR just forwards the packets to its default router. However in the inbound direction, based on the solution, MR forwards the packets to the next hop. I do not quite understand the route segments. Can you explain it more? > > When MRi associates with MRj, it may choose MRj as the default router > > > Yes ok, but I don't know where this leads to. "Looping problems"? > What I want to say here is how the outbound path inside the nested NEMO is formed. > > The inbound path inside the nested NEMO may be different from the > > outbound path. However, since the route inside the NEMO network does > > not involve HA, the optimal route is based on the decision of each > > MR. > > ...is based only on the decision of MR's, and not that of the remote HA's. > OK. > > If the intersection of p1 and p2 is not empty, denoted by > MR_1,i2, …, MR_1,ik> = where i1 < i2 < > > … < ik and j1 < j2 < … < jk. > > If it is not empty then what? Premature end? > Sorry about it. The correct sentence is “If the intersection of p1 and p2 is not empty, denoted by = where i1 < i2 < … < ik and j1 < j2 < … < jk, then ideally the optimal path between node1 and node2 is .” Note that MR_(1,i1) is equal to MR_(2, j1). > > Ideally the optimal path between node1 and node2 is > …, MR_1,i1, …, MR_2,2, MR_2,1>. > > I do not see what the second indices represent (1,2,i1,2,1). Maybe a > graphical picture would be suggestive. > > What is in plain English the optimal path? The one that is the > intersection of the two sets? > |----MR2---MR3—LFN3 | Root-MR---MR1---| | |----MR4---MR5-LFN5 In the nested NEMO like above, the optimal route between LFN3 and LFN5 is MR3<->MR2<->MR1<->MR4<->MR5. We probably can say the optimal route in this situation is the route turning around at the first MR that is aware of how to forward the data packets from one node to another without going out of the nested NEMO. > > Worse than MIPv6, in nested NEMO network the packets are forwarded to > > multiple intermediate boxes > > ... (the HA's) > OK. > > As a TCP/UDP connection is identified by a 4-tuple > address, source port, destination IP address, destination port>, in > > order to maintain the continuous session, the end point must use the > > same IP addresses during the session. > > Not only for TCP connections are the stable IP addresses needed, but > also for ICMP (ping). > That is right. > > As IP address perfectly represents both identity and location of end > > host in the fixed network, we usually just put emphasis on one and > > sometimes even mix their meanings. However, in the mobile network > > environment, we need to represent the binding between identity and > > location that is what the binding between home- address and > > care-of-address does. > > > Similar with MIPv4 and MIPv6, NEMO focuses on the solution in data > > plane rather than in the signaling plane > > What's the data and signalling planes? Is a BU signalling plane? > Thanks for asking. I should have more words about it. In NEMO the routing decision is carried in each data packet, such as IP- in-IP header. Signaling plane method mostly involves the specific signaling message to exchange the information and build up some state. It is possible to design a new NEMO signaling protocol for CN to acquire the binding information of mobile node and for HA to broadcast the binding information into the routing infrastructure. It does not require the special payload in the data packet instead of signaling messages. In some situation where a lot of data packets are sent and mobile node is fairly stable, signaling method is much efficient. However one drawback is that it requires more fundamental changes or a brand new protocol, which will be a big hurdle of deployment. (Considering that how ISPs are reluctant to upgrade to IPV6.) Yes, BU is signaling message but we here categorize NEMO as a data plane method because it introduces large changes in the data packet. > > a RO solution in data plane may qualify as a necessary step before > > An RO solution would most probably use BU's, is this data or signalling? > > > a nature extension > > natural... > OK. > > MR may choose to perform RO function just with its HA if the number > > of different CNs is large and all CNs scatter around the Internet > > Is this equivalent to saying MR may choose to _not_ do RO? I don't see > how MR does RO only with its HA. > Yes, it becomes like in NEMO basic support. In other words, this is a tradeoff between simplicity and unoptimization. There are a lot of factors to influence MR’s decision to do RO or not. Depending on the solution, the better route than that in NEMO basic support is still possible because other MR can perform RO function. But so far it seems to me that NEMO basic support and RO solution are united under the term of CR (CA). HA is defined from the perspective of MR and is CR (CA) from the perspective of CN. I have not got time to match the already proposed RO solutions. But at least in RRH, the intermediate MR overwrites the source IP address with its own CoA can be thought as performing RO function with one CR that is HA of the child MR. > > 1.7.4 Security vs. optimal route In NEMO basic support, it is very > > possible that there pre-exists the security association between MR > > and HA, which helps resist the various attack. However in NMEO RO > > solution, as the MR-HA tunnel may not exist and there is no > > pre-existing security association between two entities from the > > different domains, it is more challenging to maintain the same > > security strength as in NEMO basic support. > > An insecure RO solution for mobile hosts risks a CN and a MH. An > insecure RO solution for NEMO risks not only CN and MH but also the > bunch of LFN's in the moving network. > > It is difficult to do per-host RR tests (as currently RFC3775 does) for > all the hosts within the MNP. > Yes, good points. > Alex > From nemo-bounces@ietf.org Thu Oct 7 03:55:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20673 for ; Thu, 7 Oct 2004 03:55:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFSxD-0004v0-Gj; Thu, 07 Oct 2004 03:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFSqt-0003M5-36 for nemo@megatron.ietf.org; Thu, 07 Oct 2004 03:38:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19190 for ; Thu, 7 Oct 2004 03:38:12 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFT0V-0007uj-J6 for nemo@ietf.org; Thu, 07 Oct 2004 03:48:13 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 606894C086; Thu, 7 Oct 2004 16:37:24 +0900 (JST) Date: Thu, 7 Oct 2004 16:39:42 +0900 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft Message-Id: <20041007163942.2bf3ee05.ernst@sfc.wide.ad.jp> In-Reply-To: <4162D491.5060303@motorola.com> References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, cwng@psl.com.sg X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit > > That would be very difficult to achieve. By your definition of > > overheads, a home-address destination option would also constitute as Here are a few comments on this thread. > > an overhead. I don't see how a NEMO-RO solution can hope to achieve > > zero overhead, except perhaps using an entirely and drastically > > different routing infrastructure. > > I agree with the DO containing the HoA means no zero-encapsulation and > overhead. I don't see how a NEMO-RO solution can hope to achieve zero > overhead with existing routing infrastructure, but I see how a NEMO-RO > solution can achieve zero-overhead without the existing (and not any > other) infrastructure. That is, if the aggregatation of moving networks > is disconnected from the infrastructure, then it is possible to have > that zero-overhead, no routing header, no DO. I would propose to use the terms: - "Packet Overhead" instead of "Encapsulation" (which is a kind of packet overhead). - And, instead of Zero Overhead, we should speak about "Minimal Overhead". In this thread, do we speak about requirements, or metrics to evaluate the solutions ? BTW, "Minimal Overhead" is already listed in the requirement draft. > > Nope, but let's do a bit of thought experiment. If you are looking > > at the NEMO being a W-PAN or a car network, it might not even be > > windy at all! Perhaps only a little breezy, so to speak. ;) > > But the number of BU's depend not on the size of the moving network! > Let me however follow your thought experiment. The number of BUs depends on the number of recipients (# HAs ? # CRs ? # CNs ? : how to qualify the recipient depends on the solution's internals). Note that I can do a video-conference from a car, or have a web server on a car, so there is no need for a "big network" for a huge number of CNs. Size of the network and #CNs are orthogonal. We already said that on this list tens of times. > > However expand that little W-PAN or car network to a train with > > hundreds of VMN. IF every change in point of attachment of such a > > large NEMO must be accompanied with one BU per CN, we can expect 100 > > BUs after a change in point of attachment. > > Hundreds of VMN's in a train send zero BU's when the MR changes its > attachment point, no? It's the MR that sends the unique BU no? That depends on the solutions. Some solution may propose that the MNNs send BUs (I think this is a bad idea because it doesn't scale, but bad ideas don't prevent people to propose such solutions). > > It also depends on the scale of the NEMO. > > The nunmber of BU's/second does not depend on the size of the moving > network, except certain assumptions. > > If there were no NEMO-based MR, and if every MN in the train is > connecting to the successive AR's along the track, and if every MN is > having a continuous communication, then the number of BU's is exactly > the number of MN's, yes. But if any of those 'if's is not then no storm. > > And "stormy" to what? Who is imposed a stress because of too many BU's? > Let me write a different mail on that... This may depend on the type of link. If it's a cellular phone, that could become stormy quickly. > Imagine a train with many people watching different videos over Internet > approaching the new AR. That new AR's upstream connection is relatively > quiet (as preparing for a storm). When that AR receives the train's > TLMR suddenly all those BU/BAck's followed by application-level packets > will storm that common segment. However, the number of BU/BAck's is > much smaller than the number of video-streaming packets. The "storm" > has a small BU/BAck component. Eliminate that component and it's still > "stormy". > > This is to say I do not think a BU storm is an inconvenient of having MR > send BU's on behalf of its MNN's, or LFN's. What about the multihoming context ? The video may be received by the satellite (unidirectional link), but you use the cellular phone to send BU/ack. If all the 800 people do that in the train, that is a problem. I just wanted to point out that we shouldn't eliminate this issue of our minds (it's not such a theoritical issue as pointed out by Christophe and Alex (BTW, hi to both of you;-). And I agree with Carlos that it worth to keep an eye on improving the bandwidth by decreasing the signaling, whatever ratio of available bandwidth vs cost of signaling (I think you sort of meant that ?) So, we have to be careful at the same time about the so-many possilble configurations of the mobile networks, how it is connected to the Internet, and the type of applications running on top of that connections. > > I remember coming across Motorola's solution of using multicast > > addressing to achieve RO. That might be one approach to achieve zero > > overhead ... or maybe not zero, but minimal, since some overheads > > will be required to map that multicast address to the home-address of > > the mobile node (VMN, LMN, or LFN). I did suggest this multicast idea, one old paper is available on my web page, and the complete simulation results are in my PhD dissertation. The reason why I suggested the use of multicast was not to limit packet overhead, but to avoid the BU storm (I called that BU explosion), particularly on the first hops between the MR and the CNs (of course, building multicast trees is also expensive in terms of signaling, unless you use XCAST, but then you cannot accomodate millions of CNs). > > However, I foresee other problems with this approach, Off-hand, (1) > > that will mean RO is achieved in a way that is totally incompatible > > with NEMO-Basic, > > Exactly, that solution should interoperate with NEMO basic, that's for > sure, although if off-hand it looks as if it doesn't. It doesn't have too. It is desirable. That's another metric to qualify the solutions. If there is no good solution that is compatible with NEMO Basic Support, we should definitely consider something not compatible. > > (2) imagine millions of mobile networks in the future, and we just > > created another routing table explosion, etc. > > As long as there's no infrastructure I can't quite imagine millions of > mobile networks. I can. There is a big earthquake in Tokyo (we just had one yesterday: 5,8), the infrastructure is destroyed, each person (=1 PAN x few millions of equipped people) and each car (=1 in-vehicle network) are self-organizing. But this also looks like ad-hoc networks, so I don't like very much when we mention "no infrastructure" in this thread. Please define what's the intend. In summary, I think a problem statement draft should speak about the problem, the issues (with no solution in mind, which is hard to achieve) and propose some metrics to evaluate all the solutions. This list of metrics could/should include, but is not limited to: - packet overhead - signaling overhead - delay - amount of state - etc Then, we could see which solutions could qualify or not according to: - minimal overhead - minimal signaling - minimal delay - mininum state at routers/dedicated servers - level of compatibility with NEMO Basic support - scalability - etc. Thierry. From nemo-bounces@ietf.org Thu Oct 7 04:19:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22275 for ; Thu, 7 Oct 2004 04:19:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTPF-0002Ye-LY; Thu, 07 Oct 2004 04:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTL4-0001bh-LI for nemo@megatron.ietf.org; Thu, 07 Oct 2004 04:09:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21504 for ; Thu, 7 Oct 2004 04:09:24 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTUj-0001go-BC for nemo@ietf.org; Thu, 07 Oct 2004 04:19:26 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A5C534C086 for ; Thu, 7 Oct 2004 17:08:54 +0900 (JST) Date: Thu, 7 Oct 2004 17:11:12 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RO Problem snippets Message-Id: <20041007171112.2db23134.ernst@sfc.wide.ad.jp> In-Reply-To: <416423E5.2060804@motorola.com> References: <41641439.9080902@motorola.com> <1097079977.2425.146.camel@acorde> <416423E5.2060804@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, A few more comments. > >>> NEMO RO problem introduces more challenges and more difficulties > >>> than MIPv6 RO problem because of nested NEMO network > > > > IMHO, as I understand the Network Mobility problem (i.e. mobility of > > a whole network managed by a single entity: the MR, and with the > > MNNs even unaware of the mobility - at least the LFNs), I think that > > the requirement of providing such a (optimised) solution that > > maintains this transparency to the MNNs is also challenging. I'm not > > saying that the RO solutions based on NEMO-aware MNNs are not valid, > > but that one of the key differenced between Network Mobility and > > Terminal Mobility IMHO is that the nodes that are actually moving can > > be totally unaware of the movement (and that those nodes should > > profit of some route optimisation if possible). > > So it is a requirement Rx that a NEMO RO solution still allows for LFN's > to not be mobility aware. Back to my the last 2 mails, I suggest to list this (call it "mobility transparency for MNNs" or "NEMO-enabled") as one of the metric/qualifier to evaluate which proposition qualifies or not for a solution. We can only decide which is our degree of tolerance for each qualifier when we have a good view of the potential solutions. > > And also a question, do we want to address the RO problem when > > multihoming is also involved? > > Some WG members agree that the RO problem should include multihoming RO > aspects. I do personaly think there is a more immediate need for multihoming (as defined in the NEMO WG i.e. draft-ietf-nemo-multihoming-issues) than for RO. > I personally IMHO think that multihoming aspects have not been > clarified not even for the base NEMO protocol (not that it should have); > I don't think that there's anything in "multihoming" that makes it sound > more appealing to RO than to base NEMO. I don't understand this last bit, but I think that NEMO Basic Support just need a few fixes for multihoming. The problem with multihoming is that most of issues listed in draft-ietf-nemo-multihoming issues are not NEMO-specific issues. So, a full support of the multihoming expectations (see draft-ernst-generic-goals-and-benefits) is relying on progress made in other working groups. > I agree that the multihoming aspects in NEMO are still unclear. I just > wanted to point out that IMHO we should be careful in defining RO > solutions that are compatible with multihoming scenarios. 100% agree. So, that is another qualifier for RO solutions. > Caution: do not understand me wrong. I am not saying that multihoming > is bad or not good. It's good to have two egress interfaces so that if > one goes down the other takes its place. It's just that up to now > it looked so much as a problem w/o a NEMO solution (so we get problem > and classification drafts and joined classification drafts). But it's > not like a problem that we know how to tackle at all, there are so many > ways of addressing "multi-homing". Or, with NEMO base, we knew it was > relying on Mobile IP... No offence intended and IMHO. Thierry. From nemo-bounces@ietf.org Thu Oct 7 04:28:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22951 for ; Thu, 7 Oct 2004 04:28:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTbf-0005oH-Ld; Thu, 07 Oct 2004 04:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTRk-0003AZ-Jl for nemo@megatron.ietf.org; Thu, 07 Oct 2004 04:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21891 for ; Thu, 7 Oct 2004 04:16:18 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTbP-00023n-Gm for nemo@ietf.org; Thu, 07 Oct 2004 04:26:20 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 040004C088 for ; Thu, 7 Oct 2004 17:15:49 +0900 (JST) Date: Thu, 7 Oct 2004 17:18:06 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's Message-Id: <20041007171806.73ed1031.ernst@sfc.wide.ad.jp> In-Reply-To: <41641EBB.3050302@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> <41641EBB.3050302@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit > > One immediate thought is "design so that there's an absolute minimum > > amount of BUs to be sent". > > Yes, that sounds like an Rx requirement (Rx like R1, R2... R3 > requirements in the goals and requirements document). > > IMHO, a problem should sound like this "the problem is that paths are so > long, really long". It should not invite for a solution or a > requirement, just say the problem. > > I'm usually very hesitant to talk about problems because whatever kind > of problem one may imagine then a solution pops up immediately, ending > in an argument that there is no problem, or worse, in a too early > competition of solution drafts (or "war") :-) Agree. Basically, I think we can be careful with the words we use, trying to keep them general. This is hard, so we shouldn't elaborate the description of the problem. Also, we can assume the problems based on NEMO Basic Support, e.g.: - multiple encapsulation when NEMO are nested - disconnected operation between 2 MNNs in the same NEMO Actually, I see the document as being as light as possible. What about such structure: - problem using NEMO Basic Support - types of RO -- MNN to CN in the fixed infrascture -- MNN to MNN (same NEMO) -- MNN to MNN (# NEMOs) -- etc - design goals for RO solutions - list of metrics / qualifier Thierry. From nemo-bounces@ietf.org Thu Oct 7 07:00:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03876 for ; Thu, 7 Oct 2004 07:00:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVvT-0003H0-CH; Thu, 07 Oct 2004 06:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVe8-0000U5-My for nemo@megatron.ietf.org; Thu, 07 Oct 2004 06:37:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01998 for ; Thu, 7 Oct 2004 06:37:12 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVno-0001zv-3D for nemo@ietf.org; Thu, 07 Oct 2004 06:47:16 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C6052CEA6; Thu, 7 Oct 2004 12:36:43 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id C87F62CE8D; Thu, 7 Oct 2004 12:36:42 +0200 (CEST) Subject: Re: [nemo] NEMO RO Problem From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Fan Zhao In-Reply-To: <200410040657.i946vZNX025909@tremex.ucdavis.edu> References: <200410040657.i946vZNX025909@tremex.ucdavis.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6YgL76px4OQETeYFAf/l" Organization: Universidad Carlos III de Madrid Message-Id: <1097145435.2464.74.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 12:37:15 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-6YgL76px4OQETeYFAf/l Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Dear Fan, Here they are some comments/questions (maybe some of them have been already pointed by Alex, I'll try to avoid those, but some duplicates may appear). El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3: > Dear all, >=20 > I wrote a document about NEMO RO problem, please click the=20 > following link to see the details: > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc >=20 > This document benefits from a lot of discussions and drafts. > It is still a preliminary version, so there are still a lot=20 > of questions. For example, Alex said that the charter does > not requires dealing with multi-homing and NEMO RO. IMO, the > requirement that RO solution should function for multi-homing NEMO=20 > networks and should not conflict with multi-homing mechanism seems > OK. We may also take a stepwise approach to solve multi-homing > and RO issues. Thanks for your comments. First, thanks for providing the document. As Alex, I can help you with the edition if you want to submit this input as I-D. "NEMO basic support protocol [...] However, it results in a non-optimal (We will define=20 <93>optimal<94> and <93>non-optimal<94> later.) route (triangle-routing) between =20 VMN/LFN/MR and CN with a non-zero and even very large probability,=20 which causes the significant communication delay." IMHO, with NEMO Basic Support (BTW, I suggest to use capital letters in "NEMO Basic Support"), the route experienced by the traffic is always non-optimal (of course, the severeness of this sub-optimal routing depends on the scenario). I'd use MNN instead of "VMN/LFN/MR". With VMN the problem is even worse than with a LFN, and a MR, when communicating with a CN as a host (i.e. a MN), could perform MIPv6 RO. "[...] VMN/LFN" I suggest to use the term MNN. LMNs experience also non-optimal routes in a NEMO. Or am I missing something? "IP-in-IP or other encapsulation (IPSec) causes the overhead in packet=20 payload. Especially in nested NEMO with multiple levels of mobility,=20 multiple IP-in-IP headers are added to the packet which represent a=20 waste on bandwidth." As I pointed out in a previous e-mail, I think that not only IP-in-IP encapsulation causes overhead. Routing Headers and Home Address DO, for example, are sort-of tunnels. Therefore, I propose to use something like that: "IP-in-IP or other sort-of tunnels (e.g. Routing Headers, HoA DO) causes overhead ...." "MR may choose to perform RO function=20 just with its HA if the number of different CNs is large and all CNs=20 scatter around the Internet." What do you mean with this sentence? I'm not sure, but performing RO just with the HA sounds to me like not performing RO at all. "- Optimal or nearly optimal route between MR and CR, MR and HA as well=20 as VMN/LFN and CN." You refer along the whole document to the CR. IMHO, a general RO analysis document should try to avoid to think is proposed solutions, and face the problem in a more abstract way (I know it is really hard... ) "R2: The solution MUST not require modifications to any node other than=20 MRs, CRs and HAs." I agree that the RO should be transparent to the MNNs. On the other hand MUST may be so strong. I'm also in favour of, at least, studying solutions that, without breaking the transparency to non-NEMO-aware MNNs (e.g. LFNs), may provide some enhanced RO to NEMO-aware MNNs. Thanks a lot. Kind regards, Carlos J. >=20 > Sincerely, > fan --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-6YgL76px4OQETeYFAf/l Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZRxb5vKyPtrWqkARAhJwAJ9Ki1v4FP2iBEaXzeC4p2Qn6M1wPQCghwDv I6mM3gTi9Z2Q+g/tcbWLirw= =uSbs -----END PGP SIGNATURE----- --=-6YgL76px4OQETeYFAf/l-- From nemo-bounces@ietf.org Thu Oct 7 09:22:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14733 for ; Thu, 7 Oct 2004 09:22:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFY5x-0000Bv-PT; Thu, 07 Oct 2004 09:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFY48-000871-Dx for nemo@megatron.ietf.org; Thu, 07 Oct 2004 09:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14051 for ; Thu, 7 Oct 2004 09:12:14 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYDq-0003QF-06 for nemo@ietf.org; Thu, 07 Oct 2004 09:22:18 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i97DDDHa023326; Thu, 7 Oct 2004 06:13:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i97BBf7c014511; Thu, 7 Oct 2004 06:11:41 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C5E1E863819; Thu, 7 Oct 2004 15:11:59 +0200 (CEST) Message-ID: <4165409A.4040004@motorola.com> Date: Thu, 07 Oct 2004 15:11:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] RO Problem snippets References: <41641439.9080902@motorola.com> <1097079977.2425.146.camel@acorde> <416423E5.2060804@motorola.com> <20041007171112.2db23134.ernst@sfc.wide.ad.jp> In-Reply-To: <20041007171112.2db23134.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A160FBBE11ECB492D978DBB" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A160FBBE11ECB492D978DBB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >>>>> NEMO RO problem introduces more challenges and more >>>>> difficulties than MIPv6 RO problem because of nested NEMO >>>>> network >>> >>> IMHO, as I understand the Network Mobility problem (i.e. mobility >>> of a whole network managed by a single entity: the MR, and with >>> the MNNs even unaware of the mobility - at least the LFNs), I >>> think that the requirement of providing such a (optimised) >>> solution that maintains this transparency to the MNNs is also >>> challenging. I'm not saying that the RO solutions based on >>> NEMO-aware MNNs are not valid, but that one of the key >>> differenced between Network Mobility and Terminal Mobility IMHO >>> is that the nodes that are actually moving can be totally unaware >>> of the movement (and that those nodes should profit of some >>> route optimisation if possible). >> >> So it is a requirement Rx that a NEMO RO solution still allows for >> LFN's to not be mobility aware. > > Back to my the last 2 mails, I suggest to list this (call it > "mobility transparency for MNNs" or "NEMO-enabled") as one of the > metric/qualifier to evaluate which proposition qualifies or not for a > solution. We can only decide which is our degree of tolerance for > each qualifier when we have a good view of the potential solutions. Thierry, partially ahree. Let me say just the not part. I don't think we need to metricize/qualify/classify/evaluate solutions. I think the Generic RO Model draft and the taxonomy already have large parts that generalize and qualify the solutions. I think we need to define the problem in the problem statement draft. That could be as short as 5 pages. I think we should turn all explanations of solutions as support of the problem itself, not as precursors of requirements, or as evaluators which decide which RO solution is best. For example, one way that it could be written is: "The problem is that paths are very long. Some NEMO RO mechanisms propose that MR updates the CN's BC not only with its CoA but with its MNP too. This however involves a security risk regarding all hosts with addresses configured from that prefix. To avoid these risks, the MR may use RR tests for each address in the MNP; this behaviour is not feasible due to large number of full 128bit addresses possible out of a 64bit prefix..." This leaves us with a standing problem, and not with a selected solution. Better yet: the problem is that the paths are very long. To find optimal paths, some mechanisms propose to: (1) send route updates to AR but this is not feasible because, (2) send MNP to CN but this is not feasible because, (3) send XYZ to ZYX but this is not feasible because. I do not think that the problem statement draft should contain a reasoning like: RO mechanism 1 offers mobility transparency and no security, while RO mechanism 2 offers security with no secrecy transparency, so we prefer mechanism 1. It is much too early for this. Alex --------------enig4A160FBBE11ECB492D978DBB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZUCfMmC0w56zj54RAn67AKDe9Hh4ZC2fRTivrnz/Vw0xdnm4pACg6+N+ G1dIDtia9AWhsv+OFndcS0g= =9VEx -----END PGP SIGNATURE----- --------------enig4A160FBBE11ECB492D978DBB-- From nemo-bounces@ietf.org Thu Oct 7 09:29:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15084 for ; Thu, 7 Oct 2004 09:29:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYJ0-0002NU-7c; Thu, 07 Oct 2004 09:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFY7X-0000ch-2q for nemo@megatron.ietf.org; Thu, 07 Oct 2004 09:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14370 for ; Thu, 7 Oct 2004 09:15:45 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYHE-0003mT-0m for nemo@ietf.org; Thu, 07 Oct 2004 09:25:49 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i97DFgAt017495; Thu, 7 Oct 2004 06:15:42 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i97D7f1h014862; Thu, 7 Oct 2004 08:07:42 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9DD8A8859B1; Thu, 7 Oct 2004 15:15:39 +0200 (CEST) Message-ID: <41654176.1070500@motorola.com> Date: Thu, 07 Oct 2004 15:15:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's References: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> <41641EBB.3050302@motorola.com> <20041007171806.73ed1031.ernst@sfc.wide.ad.jp> In-Reply-To: <20041007171806.73ed1031.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7558CD32BCC5B06F298D63A" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7558CD32BCC5B06F298D63A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >>>One immediate thought is "design so that there's an absolute minimum >>>amount of BUs to be sent". >> >>Yes, that sounds like an Rx requirement (Rx like R1, R2... R3 >>requirements in the goals and requirements document). >> >>IMHO, a problem should sound like this "the problem is that paths are so >>long, really long". It should not invite for a solution or a >>requirement, just say the problem. >> >>I'm usually very hesitant to talk about problems because whatever kind >>of problem one may imagine then a solution pops up immediately, ending >>in an argument that there is no problem, or worse, in a too early >>competition of solution drafts (or "war") :-) > > > Agree. Basically, I think we can be careful with the words we use, > trying to keep them general. This is hard, so we shouldn't elaborate the > description of the problem. > > Also, we can assume the problems based on NEMO Basic Support, e.g.: > - multiple encapsulation when NEMO are nested > - disconnected operation between 2 MNNs in the same NEMO > > Actually, I see the document as being as light as possible. Yes, let's go for 5 pages no more. > What about such structure: > - problem using NEMO Basic Support Ok. > - types of RO > -- MNN to CN in the fixed infrascture > -- MNN to MNN (same NEMO) > -- MNN to MNN (# NEMOs) > -- etc > - design goals for RO solutions This is "design goals" and no "problem statement". > - list of metrics / qualifier This is too precise. Who's going to use these metrics later? Alex --------------enigA7558CD32BCC5B06F298D63A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZUF7MmC0w56zj54RAqfTAKC5I5WTn5sKupPzkql2DEOTxVp1/ACeNBW8 yyq+N7tJbkWwv1qAtSWgAqQ= =7BIj -----END PGP SIGNATURE----- --------------enigA7558CD32BCC5B06F298D63A-- From nemo-bounces@ietf.org Thu Oct 7 11:22:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26353 for ; Thu, 7 Oct 2004 11:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZzd-0007Lg-5F; Thu, 07 Oct 2004 11:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZpH-0004gl-Bj for nemo@megatron.ietf.org; Thu, 07 Oct 2004 11:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24573 for ; Thu, 7 Oct 2004 11:05:00 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZyz-0002XX-F3 for nemo@ietf.org; Thu, 07 Oct 2004 11:15:06 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i97F6GhZ012546; Thu, 7 Oct 2004 08:06:16 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i97F3m51031718; Thu, 7 Oct 2004 10:03:48 -0500 Message-ID: <41655B13.9040901@motorola.com> Date: Thu, 07 Oct 2004 17:04:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> <1097047017.9783.81.camel@localhost> <4163E9CD.3090106@motorola.com> <1097116354.9209.5.camel@localhost> In-Reply-To: <1097116354.9209.5.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA655988D60FC5B59014D0AA5" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA655988D60FC5B59014D0AA5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >>>> I agree with the DO containing the HoA means no >>>> zero-encapsulation and overhead. I don't see how a NEMO-RO >>>> solution can hope to achieve zero overhead with existing >>>> routing infrastructure, but I see how a NEMO-RO solution can >>>> achieve zero-overhead without the existing (and not any other) >>>> infrastructure. That is, if the aggregatation of moving >>>> networks is disconnected from the infrastructure, then it is >>>> possible to have that zero-overhead, no routing header, no DO. >>> >>> Ah, I see. It means we use a different address space for NEMO-RO >>> so that these address are not routed using aggregation, but rely >>> on the mobile router running some kind of dynamic routing >>> protocol. >> >> No, it means that when you have an aggregation of moving networks >> whose TLMR is disconnected (no infrastructure), there should be a >> way to make those networks talk to each other without RH's nor >> DO's. > > Okay, I see. Isn't that threading a bit too close to MANET? Were it so I'd have posted to the MANET WG. Two moving networks with MR1 and MR2. MR1, MR2 and LFN do not use OSPF. MR1 nested within MR2. LFN's need to communicate, without TLMR connected to AR. The problem is they can't. Alex --------------enigA655988D60FC5B59014D0AA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZVsYMmC0w56zj54RAi9+AKDpUdGg6cUV6+5ZiuOb1JsCONTXwgCfZE4e 1cDX/GMdVmGmZR3xtqgHZ4k= =ohbc -----END PGP SIGNATURE----- --------------enigA655988D60FC5B59014D0AA5-- From nemo-bounces@ietf.org Thu Oct 7 11:38:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27524 for ; Thu, 7 Oct 2004 11:38:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFa1j-0007x2-3f; Thu, 07 Oct 2004 11:17:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZtW-0005cu-EU for nemo@megatron.ietf.org; Thu, 07 Oct 2004 11:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25012 for ; Thu, 7 Oct 2004 11:09:23 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFa3C-0002uo-CY for nemo@ietf.org; Thu, 07 Oct 2004 11:19:29 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i97FA0QH029209; Thu, 7 Oct 2004 08:10:00 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i97F6uNK007248; Thu, 7 Oct 2004 10:06:57 -0500 Message-ID: <41655C14.2090904@motorola.com> Date: Thu, 07 Oct 2004 17:09:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft References: <1095745409.9269.14.camel@localhost> <415C162C.9020202@motorola.com> <1096870913.9192.62.camel@localhost> <416126B0.4000500@motorola.com> <1096956613.5491.92.camel@localhost> <4162D491.5060303@motorola.com> <20041007163942.2bf3ee05.ernst@sfc.wide.ad.jp> In-Reply-To: <20041007163942.2bf3ee05.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2836BBCF956FD08CAB89AEB5" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nemo@ietf.org, cwng@psl.com.sg X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2836BBCF956FD08CAB89AEB5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > In summary, I think a problem statement draft should speak about the > problem, the issues (with no solution in mind, which is hard to > achieve) Hard to achieve, but not impossible. Sometimes it is sufficient to just say "a form of Routing Header" instead of saying RRH. Alex --------------enig2836BBCF956FD08CAB89AEB5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZVwaMmC0w56zj54RAujaAKCDKXmwZJJTXSphYqeBuAddoEmWAQCfVXGy E+gFMxZH8UY9rXtdVp8pHVk= =pvu6 -----END PGP SIGNATURE----- --------------enig2836BBCF956FD08CAB89AEB5-- From nemo-bounces@ietf.org Thu Oct 7 16:34:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22855 for ; Thu, 7 Oct 2004 16:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFeJV-0007GD-9a; Thu, 07 Oct 2004 15:52:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFe2L-0008LN-Dq; Thu, 07 Oct 2004 15:34:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15848; Thu, 7 Oct 2004 15:34:47 -0400 (EDT) Message-Id: <200410071934.PAA15848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 07 Oct 2004 15:34:47 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-01.txt Pages : 20 Date : 2004-10-7 This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft [8]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-home-network-models-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-home-network-models-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-7155457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-7155457.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 7 20:29:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18617 for ; Thu, 7 Oct 2004 20:29:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFiUA-0002PI-3w; Thu, 07 Oct 2004 20:19:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFiCF-0005Rb-2j for nemo@megatron.ietf.org; Thu, 07 Oct 2004 20:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13580 for ; Thu, 7 Oct 2004 20:01:15 -0400 (EDT) Received: from havana.ucdavis.edu ([169.237.104.156]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFiLy-0006qB-1e for nemo@ietf.org; Thu, 07 Oct 2004 20:11:25 -0400 Received: from andrena.ucdavis.edu (andrena.ucdavis.edu [169.237.104.181]) by havana.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i98019Ug024222; Thu, 7 Oct 2004 17:01:10 -0700 (PDT) Received: from andrena.ucdavis.edu (localhost [127.0.0.1]) by andrena.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i98019Mp021951; Thu, 7 Oct 2004 17:01:09 -0700 (PDT) Received: (from www@localhost) by andrena.ucdavis.edu (8.12.10/8.12.9/Submit) id i98019w4021950; Thu, 7 Oct 2004 17:01:09 -0700 (PDT) Date: Thu, 7 Oct 2004 17:01:09 -0700 (PDT) Message-Id: <200410080001.i98019w4021950@andrena.ucdavis.edu> To: Alexandru Petrescu , Thierry Ernst Subject: Re: [nemo] RO Problem snippets From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Alex, I partially agree with you too. :-) Please see the reply below. Best regards, fan > Thierry Ernst wrote: > >>>>> NEMO RO problem introduces more challenges and more > >>>>> difficulties than MIPv6 RO problem because of nested NEMO > >>>>> network > >>> > >>> IMHO, as I understand the Network Mobility problem (i.e. mobility > >>> of a whole network managed by a single entity: the MR, and with > >>> the MNNs even unaware of the mobility - at least the LFNs), I > >>> think that the requirement of providing such a (optimised) > >>> solution that maintains this transparency to the MNNs is also > >>> challenging. I'm not saying that the RO solutions based on > >>> NEMO-aware MNNs are not valid, but that one of the key > >>> differenced between Network Mobility and Terminal Mobility IMHO > >>> is that the nodes that are actually moving can be totally unaware > >>> of the movement (and that those nodes should profit of some > >>> route optimisation if possible). > >> > >> So it is a requirement Rx that a NEMO RO solution still allows for > >> LFN's to not be mobility aware. > > > > Back to my the last 2 mails, I suggest to list this (call it > > "mobility transparency for MNNs" or "NEMO-enabled") as one of the > > metric/qualifier to evaluate which proposition qualifies or not for a > > solution. We can only decide which is our degree of tolerance for > > each qualifier when we have a good view of the potential solutions. > > Thierry, partially ahree. Let me say just the not part. I don't think > we need to metricize/qualify/classify/evaluate solutions. I think the > Generic RO Model draft and the taxonomy already have large parts that > generalize and qualify the solutions. > Whether a solution meets the requirement or not is a high (maybe coarse) level of evaluation while the metrics part provides a way to evaluate how well a solution meets the requirement (Among all the solutions that meets the requirements, one may be better in some aspects but short in others.), which is closer to the requirement draft rather than taxonomy draft. We can also assign the weight/cost to each metric/qualifer. The solution should be overall the best in the different configurations and mobile scenarios. > I think we need to define the problem in the problem statement draft. > That could be as short as 5 pages. > > I think we should turn all explanations of solutions as support of the > problem itself, not as precursors of requirements, or as evaluators > which decide which RO solution is best. > The requirement has to be defined before the solution. > For example, one way that it could be written is: "The problem is that > paths are very long. Some NEMO RO mechanisms propose that MR updates > the CN's BC not only with its CoA but with its MNP too. This however > involves a security risk regarding all hosts with addresses configured > from that prefix. To avoid these risks, the MR may use RR tests for > each address in the MNP; this behaviour is not feasible due to large > number of full 128bit addresses possible out of a 64bit prefix..." This > leaves us with a standing problem, and not with a selected solution. > > Better yet: the problem is that the paths are very long. To find > optimal paths, some mechanisms propose to: (1) send route updates to AR > but this is not feasible because, (2) send MNP to CN but this is not > feasible because, (3) send XYZ to ZYX but this is not feasible because. > > I do not think that the problem statement draft should contain a > reasoning like: RO mechanism 1 offers mobility transparency and no > security, while RO mechanism 2 offers security with no secrecy > transparency, so we prefer mechanism 1. It is much too early for this. > I agree. > Alex > From nemo-bounces@ietf.org Thu Oct 7 23:49:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02986 for ; Thu, 7 Oct 2004 23:49:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFljZ-0000cF-EY; Thu, 07 Oct 2004 23:47:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFljE-0000To-Ls for nemo@megatron.ietf.org; Thu, 07 Oct 2004 23:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02899 for ; Thu, 7 Oct 2004 23:47:33 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFlt1-0004Y2-5K for nemo@ietf.org; Thu, 07 Oct 2004 23:57:46 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CB4214C086 for ; Fri, 8 Oct 2004 12:46:45 +0900 (JST) Date: Fri, 8 Oct 2004 12:49:04 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] Re: BU storms when MR does RO on behalf of LFN's Message-Id: <20041008124904.551d1539.ernst@sfc.wide.ad.jp> In-Reply-To: <41654176.1070500@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC2837B9@xmb-ams-337.emea.cisco.com> <41641EBB.3050302@motorola.com> <20041007171806.73ed1031.ernst@sfc.wide.ad.jp> <41654176.1070500@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, > > What about such structure: > > - problem using NEMO Basic Support > > Ok. > > > - types of RO > > -- MNN to CN in the fixed infrascture > > -- MNN to MNN (same NEMO) > > -- MNN to MNN (# NEMOs) > > -- etc > > - design goals for RO solutions > > This is "design goals" and no "problem statement". > > - list of metrics / qualifier > > This is too precise. Who's going to use these metrics later? The people who will decide which solution may qualify for a WG standard, if the WG decided to update its charter to work on RO solutions. From nemo-bounces@ietf.org Thu Oct 7 23:54:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03309 for ; Thu, 7 Oct 2004 23:54:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFljg-0000f2-3M; Thu, 07 Oct 2004 23:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFljE-0000Tq-Ls for nemo@megatron.ietf.org; Thu, 07 Oct 2004 23:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02901 for ; Thu, 7 Oct 2004 23:47:33 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFlt1-0004Y4-5O for nemo@ietf.org; Thu, 07 Oct 2004 23:57:46 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9AADB4C088 for ; Fri, 8 Oct 2004 12:46:52 +0900 (JST) Date: Fri, 8 Oct 2004 12:49:11 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] RO Problem snippets Message-Id: <20041008124911.2382685a.ernst@sfc.wide.ad.jp> In-Reply-To: <4165409A.4040004@motorola.com> References: <41641439.9080902@motorola.com> <1097079977.2425.146.camel@acorde> <416423E5.2060804@motorola.com> <20041007171112.2db23134.ernst@sfc.wide.ad.jp> <4165409A.4040004@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Alexandru Petrescu wrote: > Thierry Ernst wrote: > > Back to my the last 2 mails, I suggest to list this (call it > > "mobility transparency for MNNs" or "NEMO-enabled") as one of the > > metric/qualifier to evaluate which proposition qualifies or not for a > > solution. We can only decide which is our degree of tolerance for > > each qualifier when we have a good view of the potential solutions. > > Thierry, partially ahree. Let me say just the not part. I don't think > we need to metricize/qualify/classify/evaluate solutions. I think the > Generic RO Model draft and the taxonomy already have large parts that > generalize and qualify the solutions. I propose something more synthetical, but I don't see the motivation of your opposition ("because there is already attempts to do so in drafts"). Well, we are discussing about what the WG document should content, aren't we ? > I think we need to define the problem in the problem statement draft. > That could be as short as 5 pages. > > I think we should turn all explanations of solutions as support of the > problem itself, not as precursors of requirements, or as evaluators > which decide which RO solution is best. > > For example, one way that it could be written is: "The problem is that > paths are very long. Some NEMO RO mechanisms propose that MR updates > the CN's BC not only with its CoA but with its MNP too. This however > involves a security risk regarding all hosts with addresses configured > from that prefix. To avoid these risks, the MR may use RR tests for > each address in the MNP; this behaviour is not feasible due to large > number of full 128bit addresses possible out of a 64bit prefix..." This > leaves us with a standing problem, and not with a selected solution. > > Better yet: the problem is that the paths are very long. To find > optimal paths, some mechanisms propose to: (1) send route updates to AR > but this is not feasible because, (2) send MNP to CN but this is not > feasible because, (3) send XYZ to ZYX but this is not feasible because. I think that's also going too much into the analysis of the solutions. The only way to do this from the perspective of the solutions is to build a (complete) taxonomy of the solutions (what Thubert's draft attempts at doing) but the problem here is that the taxonomy can only include already made solutions. Better solutions may come later, once the problem is well-known for everyone ... So, I think that the analysis of the solution space can only start once we have realized the following 3 steps, in this order: 1. the problem (where routing is not optmized, why, what is the cause and consequence [packet overhead, longer dely, ...] 2. the design goals (mimimal overhead, minimal delay, minimal number of "mobility hops", ...) 3. metrics/qualifiers > I do not think that the problem statement draft should contain a > reasoning like: RO mechanism 1 offers mobility transparency and no > security, while RO mechanism 2 offers security with no secrecy > transparency, so we prefer mechanism 1. It is much too early for this. Definitely agree with this. Thierry. From nemo-bounces@ietf.org Fri Oct 8 00:47:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06578 for ; Fri, 8 Oct 2004 00:47:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmdp-0004jT-1U; Fri, 08 Oct 2004 00:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmbu-0004MH-KW for nemo@megatron.ietf.org; Fri, 08 Oct 2004 00:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06342 for ; Fri, 8 Oct 2004 00:44:00 -0400 (EDT) Received: from havana.ucdavis.edu ([169.237.104.156]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmla-0005fI-Np for nemo@ietf.org; Fri, 08 Oct 2004 00:54:14 -0400 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by havana.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i984gqUg003576; Thu, 7 Oct 2004 21:42:52 -0700 (PDT) Received: from citheronia.ucdavis.edu (localhost [127.0.0.1]) by citheronia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i984gpwL017112; Thu, 7 Oct 2004 21:42:51 -0700 (PDT) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id i984gpab017111; Thu, 7 Oct 2004 21:42:51 -0700 (PDT) Date: Thu, 7 Oct 2004 21:42:51 -0700 (PDT) Message-Id: <200410080442.i984gpab017111@citheronia.ucdavis.edu> To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Subject: Re: [nemo] NEMO RO Problem From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Carlos, Thank you very much for your comments. Please see my reply below. Sincerely, Fan > Dear Fan, > > Here they are some comments/questions (maybe some of them have been > already pointed by Alex, I'll try to avoid those, but some duplicates > may appear). > > El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3: > > Dear all, > >=20 > > I wrote a document about NEMO RO problem, please click the=20 > > following link to see the details: > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > >=20 > > This document benefits from a lot of discussions and drafts. > > It is still a preliminary version, so there are still a lot=20 > > of questions. For example, Alex said that the charter does > > not requires dealing with multi-homing and NEMO RO. IMO, the > > requirement that RO solution should function for multi-homing NEMO=20 > > networks and should not conflict with multi-homing mechanism seems > > OK. We may also take a stepwise approach to solve multi-homing > > and RO issues. Thanks for your comments. > > First, thanks for providing the document. As Alex, I can help you with > the edition if you want to submit this input as I-D. > Thanks a lot. I really appreciate it. > "NEMO basic support protocol [...] However, it results in a non-optimal > (We will define=20 > <93>optimal<94> and <93>non-optimal<94> later.) route (triangle-routing) > between > =20 > VMN/LFN/MR and CN with a non-zero and even very large probability,=20 > which causes the significant communication delay." > > IMHO, with NEMO Basic Support (BTW, I suggest to use capital letters in > "NEMO Basic Support"), Sure. > the route experienced by the traffic is always > non-optimal (of course, the severeness of this sub-optimal routing > depends on the scenario). Not really. In the very extreme case where HA is located on the routing path between the location of CN and the location of MR, the route taken by the traffic in NEMO Basic Support is the same as the “optimal route” according to the definition in the document. > I'd use MNN instead of "VMN/LFN/MR". With VMN the problem is even worse > than with a LFN, and a MR, when communicating with a CN as a host (i.e. > a MN), could perform MIPv6 RO. > Yes, I will correct that. > "[...] VMN/LFN" > > I suggest to use the term MNN. LMNs experience also non-optimal routes > in a NEMO. Or am I missing something? > Yes, you are right. As long as MR performs NEMO Basic support function, the route between LMN and Cn is not optimal. > "IP-in-IP or other encapsulation (IPSec) causes the overhead in packet=20 > payload. Especially in nested NEMO with multiple levels of mobility,=20 > multiple IP-in-IP headers are added to the packet which represent a=20 > waste on bandwidth." > > As I pointed out in a previous e-mail, I think that not only IP-in-IP > encapsulation causes overhead. Routing Headers and Home Address DO, for > example, are sort-of tunnels. Therefore, I propose to use something like > that: "IP-in-IP or other sort-of tunnels (e.g. Routing Headers, HoA DO) > causes overhead ...." > That is correct. Thanks. > "MR may choose to perform RO function=20 > just with its HA if the number of different CNs is large and all CNs=20 > scatter around the Internet." > > What do you mean with this sentence? I'm not sure, but performing RO > just with the HA sounds to me like not performing RO at all. > Assume that there are n CNs scattering around the Internet, which means that there is no one single CR topologically close to all CNs. If MR performs the RO functions with all the CN/CRs, the overhead (the number of tunnels and states) in MR is O(n). By choosing HA as CR for all these n CNs, MR just needs to maintain one tunnel with HA. On the other hand, from the perspective of CR, if there are m MRs belonging to the same home network scattering around the Internet, because of the same reason, CR may also choose to forward the traffic to HA rather than each MR. So HA play dual roles, both CR and HA here, though we may only put emphasis on one over the other before. These are all about the tradeoff. Even though MR has to go though its HA, because the traffic forwarded by this MR is aggregated to one destination, from the parent MR point of view the number of CNs (The child MR acts as one of MNNs.) is reduced, the better route than that in NEMO basic support is still possible because the parent MR could perform RO function. > "- Optimal or nearly optimal route between MR and CR, MR and HA as well=20 > as VMN/LFN and CN." > > You refer along the whole document to the CR. IMHO, a general RO > analysis document should try to avoid to think is proposed solutions, > and face the problem in a more abstract way (I know it is really hard... > ) > That is what I am exactly trying to do in this draft. I apologize for using a confusing term, CR. Actually I should replace CR with Correspondent Agent (CA). CA represents a wider scope than CR used in several drafts. We introduce CA for several reasons: 1. There is no appropriate term for the peer of MR when performing RO. CN is the peer of MNN but not that of MR. CA is introduced to fill this gap. 2. Under the term of CA, NEMO RO solution and NEMO Basic Support Protocol are perfectly united. We use this term to help us describe, compare and contrast between NEMO BSP and NEMO RO. > "R2: The solution MUST not require modifications to any node other than=20 > MRs, CRs and HAs." > > I agree that the RO should be transparent to the MNNs. On the other hand > MUST may be so strong. I'm also in favour of, at least, studying > solutions that, without breaking the transparency to non-NEMO-aware MNNs > (e.g. LFNs), may provide some enhanced RO to NEMO-aware MNNs. > If I understand correctly, you are talking about the sub-optimal route when VMN performs MIP6 RO. Is it right? IMO, NEMO RO solution should not make any change to protocols running on MNN. Maybe it sounds too solution- specific, what NEMO RO can do is to let MR broadcast the information of NEMO RO capability (Not very great, still require the interaction) or even better I see the possibility that NEMO RO can both keep the transparency and remove the sub-optimal route caused by MIP6 RO. So I strongly feel we should introduce the changes only to MR/CA/HA, one level above MNN. Note that CA includes the case of NEMO-aware CN. > Thanks a lot. > > Kind regards, > > Carlos J. > > > >=20 > > Sincerely, > > fan > --=20 > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > From nemo-bounces@ietf.org Fri Oct 8 01:01:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07548 for ; Fri, 8 Oct 2004 01:01:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmoN-0006ke-E1; Fri, 08 Oct 2004 00:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmmQ-0006Tk-Af for nemo@megatron.ietf.org; Fri, 08 Oct 2004 00:54:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07060 for ; Fri, 8 Oct 2004 00:54:54 -0400 (EDT) Received: from losangeles.ucdavis.edu ([169.237.104.159]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmwG-0005tf-Nb for nemo@ietf.org; Fri, 08 Oct 2004 01:05:09 -0400 Received: from andrena.ucdavis.edu (andrena.ucdavis.edu [169.237.104.181]) by losangeles.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i984sqfr022710; Thu, 7 Oct 2004 21:54:52 -0700 (PDT) Received: from andrena.ucdavis.edu (localhost [127.0.0.1]) by andrena.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i984sqMp001140; Thu, 7 Oct 2004 21:54:52 -0700 (PDT) Received: (from www@localhost) by andrena.ucdavis.edu (8.12.10/8.12.9/Submit) id i984sp0P001139; Thu, 7 Oct 2004 21:54:51 -0700 (PDT) Date: Thu, 7 Oct 2004 21:54:51 -0700 (PDT) Message-Id: <200410080454.i984sp0P001139@andrena.ucdavis.edu> To: Thierry Ernst , nemo Subject: Re: [nemo] RO Problem snippets From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Thierry, I completely agree with you. BTW should all three topics be included in one draft or in different drafts? Best regrads, fan > > Hi, > > Alexandru Petrescu wrote: > > Thierry Ernst wrote: > > > Back to my the last 2 mails, I suggest to list this (call it > > > "mobility transparency for MNNs" or "NEMO-enabled") as one of the > > > metric/qualifier to evaluate which proposition qualifies or not for a > > > solution. We can only decide which is our degree of tolerance for > > > each qualifier when we have a good view of the potential solutions. > > > > Thierry, partially ahree. Let me say just the not part. I don't think > > we need to metricize/qualify/classify/evaluate solutions. I think the > > Generic RO Model draft and the taxonomy already have large parts that > > generalize and qualify the solutions. > > I propose something more synthetical, but I don't see the motivation of > your opposition ("because there is already attempts to do so in > drafts"). Well, we are discussing about what the WG document should > content, aren't we ? > > > I think we need to define the problem in the problem statement draft. > > That could be as short as 5 pages. > > > > I think we should turn all explanations of solutions as support of the > > problem itself, not as precursors of requirements, or as evaluators > > which decide which RO solution is best. > > > > For example, one way that it could be written is: "The problem is that > > paths are very long. Some NEMO RO mechanisms propose that MR updates > > the CN's BC not only with its CoA but with its MNP too. This however > > involves a security risk regarding all hosts with addresses configured > > from that prefix. To avoid these risks, the MR may use RR tests for > > each address in the MNP; this behaviour is not feasible due to large > > number of full 128bit addresses possible out of a 64bit prefix..." This > > leaves us with a standing problem, and not with a selected solution. > > > > Better yet: the problem is that the paths are very long. To find > > optimal paths, some mechanisms propose to: (1) send route updates to AR > > but this is not feasible because, (2) send MNP to CN but this is not > > feasible because, (3) send XYZ to ZYX but this is not feasible because. > > I think that's also going too much into the analysis of the solutions. > The only way to do this from the perspective of the solutions is to > build a (complete) taxonomy of the solutions (what Thubert's draft > attempts at doing) but the problem here is that the taxonomy can only > include already made solutions. Better solutions may come later, once > the problem is well-known for everyone ... > > So, I think that the analysis of the solution space can only start once > we have realized the following 3 steps, in this order: > > 1. the problem (where routing is not optmized, why, what is the cause > and consequence [packet overhead, longer dely, ...] > > 2. the design goals (mimimal overhead, minimal delay, minimal number of > "mobility hops", ...) > > 3. metrics/qualifiers > > > > I do not think that the problem statement draft should contain a > > reasoning like: RO mechanism 1 offers mobility transparency and no > > security, while RO mechanism 2 offers security with no secrecy > > transparency, so we prefer mechanism 1. It is much too early for this. > > Definitely agree with this. > > Thierry. > > From nemo-bounces@ietf.org Fri Oct 8 02:23:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26923 for ; Fri, 8 Oct 2004 02:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFo46-0003FH-5n; Fri, 08 Oct 2004 02:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnxD-000812-Ps for nemo@megatron.ietf.org; Fri, 08 Oct 2004 02:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21454 for ; Fri, 8 Oct 2004 02:10:11 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFo74-000753-10 for nemo@ietf.org; Fri, 08 Oct 2004 02:20:23 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2004 08:21:06 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9869YV8028219; Fri, 8 Oct 2004 08:09:35 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 08:09:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO Problem snippets X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 8 Oct 2004 08:09:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2BFCD4@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO Problem snippets Thread-Index: AcSs8/zBSbVgHrEbQVCkAQPzn7tK8wAB7VHg From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 08 Oct 2004 06:09:34.0103 (UTC) FILETIME=[61D15A70:01C4ACFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > > > > So, I think that the analysis of the solution space can only start once > > we have realized the following 3 steps, in this order: > > > > 1. the problem (where routing is not optmized, why, what is the cause > > and consequence [packet overhead, longer dely, ...] > > > > 2. the design goals (mimimal overhead, minimal delay, minimal number of > > "mobility hops", ...) > > > > 3. metrics/qualifiers > > >=20 > I completely agree with you. > BTW should all three topics be included in > one draft or in different drafts? Agreed too. My view of this: In terms of papers, we do not necessarily have to decide right now. I understand that 1 comes first anyway. 2 and 3 seem to come together, but later. So let's focus on 1 for the time being. The taxonomy draft aimed at helping the thought process for this by making categories. Alex made a constructive summary (his snippets, sorry I still need to respond to that) from various drafts including the taxonomy one, proving that the drafts were useful for the problem statement. I hope that the drafts will be useful again when it comes to goals and finally when we elaborate solutions. I do agree that the problem part (your 1) must be concise and should not qualify the problems but just list them (like one liners again). Then the goals should order the needs for fixing the problems (relative importance, which ones are mandatory etc... a form of qualification actually). Then the metrics would be defined for each problem to help quantify the solutions and define what's acceptable, what's not. Pascal Pascal From nemo-bounces@ietf.org Fri Oct 8 03:26:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00643 for ; Fri, 8 Oct 2004 03:26:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFp4u-00023i-5o; Fri, 08 Oct 2004 03:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFozN-000143-Ph for nemo@megatron.ietf.org; Fri, 08 Oct 2004 03:16:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00054 for ; Fri, 8 Oct 2004 03:16:28 -0400 (EDT) Received: from lisbon.ucdavis.edu ([169.237.104.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFp9E-0008Hx-V1 for nemo@ietf.org; Fri, 08 Oct 2004 03:26:41 -0400 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by lisbon.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i987ErAP023270; Fri, 8 Oct 2004 00:15:01 -0700 (PDT) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i987EmtV010482; Fri, 8 Oct 2004 00:14:53 -0700 (PDT) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id i987EaHc010481; Fri, 8 Oct 2004 00:14:36 -0700 (PDT) Date: Fri, 8 Oct 2004 00:14:36 -0700 (PDT) Message-Id: <200410080714.i987EaHc010481@lymeon.ucdavis.edu> To: "Pascal Thubert (pthubert)" , Thierry Ernst , nemo Subject: RE: [nemo] RO Problem snippets From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Psacal, Thanks for your reply. Please see my reply below. Best regards, fan > I do agree that the problem part (your 1) must be concise IMO, "concise" is definitely not the most important requirement of "problem" part if it is one of requirements. The problem part intends to analysis the NEMO RO problem in depth, inspires and provides guidence to design a good NEMO RO soltuion. The problem part must not be solution-specific; instead, it should be in a general and abstract way. Why concise is important? > and should not qualify the problems > but just list them (like one liners again). Then > the goals should order the needs for fixing the problems (relative > importance, which ones are mandatory etc... a form of qualification > actually). > Then the metrics would be defined for each problem to help > quantify the solutions and define what's acceptable, what's not. > Why are the metrics defined for each problem? Do you mean that some metrics are only specific to a certain kind of problem? > Pascal > > Pascal > > From nemo-bounces@ietf.org Fri Oct 8 03:48:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01460 for ; Fri, 8 Oct 2004 03:48:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFpMY-000591-Mf; Fri, 08 Oct 2004 03:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFpIE-0004PO-KT for nemo@megatron.ietf.org; Fri, 08 Oct 2004 03:35:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01041 for ; Fri, 8 Oct 2004 03:35:57 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFpS5-0000Ca-Cx for nemo@ietf.org; Fri, 08 Oct 2004 03:46:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2004 09:46:54 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i987YnVc010951; Fri, 8 Oct 2004 09:35:23 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 09:35:21 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO Problem snippets X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 8 Oct 2004 09:35:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2BFD0C@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO Problem snippets Thread-Index: AcStBsHJCwYG3nX2QAGqynOfJ76xgQAAIC1g From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 08 Oct 2004 07:35:21.0020 (UTC) FILETIME=[5D9E8FC0:01C4AD09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Fan:) >=20 > > I do agree that the problem part (your 1) must be concise > IMO, "concise" is definitely not the most important requirement > of "problem" part if it is one of requirements. The problem part > intends to analysis the NEMO RO problem in depth, inspires and provides > guidence to design a good NEMO RO soltuion. The problem part must > not be solution-specific; instead, it should be in a general and > abstract way. Why concise is important? I think the problems must be clear cut and if they are well understood, then we should be able to present them in one line. Just like Thierry did so well for the requirements. Then it's the role of the ML to debate how each problem should be approached, taking them per order of importance, and rating the solutions per the metrics we define to finally make a decision. Note that we'll need re-chartering in between. The archives of the ML can contain all that debate. But the paper making RFC must be factual: even saying that the solution should be like this or like that would cause endless discussions and the draft would never make it through. =20 > > and should not qualify the problems > > but just list them (like one liners again). Then > > the goals should order the needs for fixing the problems (relative > > importance, which ones are mandatory etc... a form of qualification > > actually). >=20 > > Then the metrics would be defined for each problem to help > > quantify the solutions and define what's acceptable, what's not. > > > Why are the metrics defined for each problem? Do you mean that > some metrics are only specific to a certain kind of problem? Not all the problems have the same nature, so the same metric does not necessarily apply. You can not mesure security problems (like a degree of privacy, how many people know where I am, every body, just my HA?) and packet overhead for instance. Pascal From nemo-bounces@ietf.org Fri Oct 8 07:19:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15100 for ; Fri, 8 Oct 2004 07:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsZs-0005Sm-Gx; Fri, 08 Oct 2004 07:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsX5-0004mn-Kz for nemo@megatron.ietf.org; Fri, 08 Oct 2004 07:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14134 for ; Fri, 8 Oct 2004 07:03:28 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsgy-0003wk-Ec for nemo@ietf.org; Fri, 08 Oct 2004 07:13:45 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 973AA40233; Fri, 8 Oct 2004 13:02:55 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 46C8140255; Fri, 8 Oct 2004 13:02:55 +0200 (CEST) Subject: Re: [nemo] NEMO RO Problem From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Fan Zhao In-Reply-To: <200410080442.i984gpab017111@citheronia.ucdavis.edu> References: <200410080442.i984gpab017111@citheronia.ucdavis.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1WcRkqfuZKa/Ahaku0yY" Organization: Universidad Carlos III de Madrid Message-Id: <1097233408.3115.41.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 08 Oct 2004 13:03:28 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-1WcRkqfuZKa/Ahaku0yY Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Dear Fan, Thanks for your reply. Please see, some comments in-line El vie, 08-10-2004 a las 06:42, Fan Zhao escribi=F3: > Dear Carlos, >=20 > Thank you very much for your comments.=20 > Please see my reply below. >=20 > Sincerely, > Fan >=20 > > Dear Fan, > >=20 > > Here they are some comments/questions (maybe some of them have=20 > been > > already pointed by Alex, I'll try to avoid those, but some duplicates > > may appear). > >=20 > > El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=3DF3: > > > Dear all, > > >=3D20 > > > I wrote a document about NEMO RO problem, please click the=3D20 > > > following link to see the details: > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > > >=3D20 > > > This document benefits from a lot of discussions and drafts. > > > It is still a preliminary version, so there are still a lot=3D20 > > > of questions. For example, Alex said that the charter does > > > not requires dealing with multi-homing and NEMO RO. IMO, the > > > requirement that RO solution should function for multi-homing NEMO=3D= 20 > > > networks and should not conflict with multi-homing mechanism seems > > > OK. We may also take a stepwise approach to solve multi-homing > > > and RO issues. Thanks for your comments. > >=20 > > First, thanks for providing the document. As Alex, I can help you=20 > with > > the edition if you want to submit this input as I-D. > > > Thanks a lot. I really appreciate it. > =20 > > "NEMO basic support protocol [...] However, it results in a non-optimal > > (We will define=3D20 > > <93>optimal<94> and <93>non-optimal<94> later.) route (triangle-routing= ) > > between > > =3D20 > > VMN/LFN/MR and CN with a non-zero and even very large probability,=3D20 > > which causes the significant communication delay." > >=20 > > IMHO, with NEMO Basic Support (BTW, I suggest to use capital letters in > > "NEMO Basic Support"),=20 > Sure. >=20 > > the route experienced by the traffic is always > > non-optimal (of course, the severeness of this sub-optimal routing > > depends on the scenario). > Not really. In the very extreme case where HA is located on the routing > path between the location of CN and the location of MR, the route taken > by the traffic in NEMO Basic Support is the same as the =93optimal route= =94 > according to the definition in the document. OK, you are right. I was thinking in terms of overhead too ... >=20 > > I'd use MNN instead of "VMN/LFN/MR". With VMN the problem is even worse > > than with a LFN, and a MR, when communicating with a CN as a host (i.e. > > a MN), could perform MIPv6 RO. > > > Yes, I will correct that.=20 > =20 > > "[...] VMN/LFN" > >=20 > > I suggest to use the term MNN. LMNs experience also non-optimal routes > > in a NEMO. Or am I missing something? > > > Yes, you are right. As long as MR performs NEMO Basic support function, > the route between LMN and Cn is not optimal. > =20 > > "IP-in-IP or other encapsulation (IPSec) causes the overhead in=20 > packet=3D20 > > payload. Especially in nested NEMO with multiple levels of mobility,=3D= 20 > > multiple IP-in-IP headers are added to the packet which represent a=3D2= 0 > > waste on bandwidth." > >=20 > > As I pointed out in a previous e-mail, I think that not only IP-in-IP > > encapsulation causes overhead. Routing Headers and Home Address DO, for > > example, are sort-of tunnels. Therefore, I propose to use something lik= e > > that: "IP-in-IP or other sort-of tunnels (e.g. Routing Headers, HoA DO) > > causes overhead ...." > > > That is correct. Thanks. > =20 > > "MR may choose to perform RO function=3D20 > > just with its HA if the number of different CNs is large and all CNs=3D= 20 > > scatter around the Internet." > >=20 > > What do you mean with this sentence? I'm not sure, but performing RO > > just with the HA sounds to me like not performing RO at all. > > > Assume that there are n CNs scattering around the Internet, which means > that there is no one single CR topologically close to all CNs. If MR > performs the RO functions with all the CN/CRs, the overhead (the number > of tunnels and states) in MR is O(n). By choosing HA as CR for all these > n CNs, MR just needs to maintain one tunnel with HA.=20 >=20 > On the other hand, from the perspective of CR, if there are m MRs > belonging to the same home network scattering around the Internet, > because of the same reason, CR may also choose to forward the traffic to > HA rather than each MR. So HA play dual roles, both CR and HA here,=20 > though we may only put emphasis on one over the other before.=20 Yes, but if the traffic is sent to the HA, that's the operation of the NEMO Basic Support protocol, without RO, isn't it? I agree that there may be scenarios in which performing RO would be worse than not performing it, so there is a tradeoff. >=20 > These are all about the tradeoff. Even though MR has to go though its HA,= =20 > because the traffic forwarded by this MR is aggregated to one=20 > destination, from the parent MR point of view the number of CNs (The=20 > child MR acts as one of MNNs.) is reduced, the better route than that in=20 > NEMO basic support is still possible because the parent MR could perform=20 > RO function.=20 I don't understand this sentence (sorry about me poor understanding ;->). Do you mean, in a nested NEMO, going only through a single HA, as a kind of RO? > =20 > > "- Optimal or nearly optimal route between MR and CR, MR and HA as=20 > well=3D20 > > as VMN/LFN and CN." > >=20 > > You refer along the whole document to the CR. IMHO, a general RO > > analysis document should try to avoid to think is proposed solutions, > > and face the problem in a more abstract way (I know it is really hard..= . > > ) > > > That is what I am exactly trying to do in this draft. I apologize for=20 > using a confusing term, CR. Actually I should replace CR with=20 > Correspondent Agent (CA). CA represents a wider scope than CR used in=20 > several drafts. We introduce CA for several reasons: >=20 > 1. There is no appropriate term for the peer of MR when performing RO. CN= =20 > is the peer of MNN but not that of MR. CA is introduced to fill this=20 > gap. =20 >=20 > 2. Under the term of CA, NEMO RO solution and NEMO Basic Support Protocol= =20 > are perfectly united. We use this term to help us describe, compare and=20 > contrast between NEMO BSP and NEMO RO. > =20 > > "R2: The solution MUST not require modifications to any node other=20 > than=3D20 > > MRs, CRs and HAs." > >=20 > > I agree that the RO should be transparent to the MNNs. On the other han= d > > MUST may be so strong. I'm also in favour of, at least, studying > > solutions that, without breaking the transparency to non-NEMO-aware MNN= s > > (e.g. LFNs), may provide some enhanced RO to NEMO-aware MNNs. > > > If I understand correctly, you are talking about the sub-optimal route=20 > when VMN performs MIP6 RO. Is it right? IMO, NEMO RO solution should not=20 > make any change to protocols running on MNN. Maybe it sounds too solution= - I completely agree that a general and global NEMO RO solution should not (if possible) change the protocols running on MNNs. But, OTOH, I think that besides having such a solution, perhaps it will be worth also to study some additional mechanisms, fully compatible with the "NEMO global RO solution", that may enhance the performance for some MNNs. Thanks a lot. Kind Regards, Carlos J. > specific, what NEMO RO can do is to let MR broadcast the information of=20 > NEMO RO capability (Not very great, still require the interaction) or=20 > even better I see the possibility that NEMO RO can both keep the=20 > transparency and remove the sub-optimal route caused by MIP6 RO. So I=20 > strongly feel we should introduce the changes only to MR/CA/HA, one level= =20 > above MNN. Note that CA includes the case of NEMO-aware CN.=20 > =20 > > Thanks a lot. > >=20 > > Kind regards, > >=20 > > Carlos J. > >=20 > >=20 > > >=3D20 > > > Sincerely, > > > fan > > --=3D20 > > Carlos Jes=3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > >=20 --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-1WcRkqfuZKa/Ahaku0yY Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBZnQA5vKyPtrWqkARAvzJAJ9t9egagXr1z/+ecES7WapijSRtJgCgnnvo 22i4Hz9nQrNMVqGNPKUnNrM= =BfTG -----END PGP SIGNATURE----- --=-1WcRkqfuZKa/Ahaku0yY-- From nemo-bounces@ietf.org Mon Oct 11 04:47:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14266 for ; Mon, 11 Oct 2004 04:47:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGvka-0003cF-A2; Mon, 11 Oct 2004 04:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGvgp-00039G-Co for nemo@megatron.ietf.org; Mon, 11 Oct 2004 04:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13721 for ; Mon, 11 Oct 2004 04:37:52 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGvrI-0002Mr-MT for nemo@ietf.org; Mon, 11 Oct 2004 04:48:46 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2004 10:49:46 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9B8aiSx027562; Mon, 11 Oct 2004 10:37:13 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 10:37:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2004 10:37:09 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2C017F@xmb-ams-337.emea.cisco.com> Thread-Topic: Announcing the Global HAHA draft Thread-Index: AcSvbX6+v05xk+qZQQypTDE+NEAcpQ== From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 11 Oct 2004 08:37:12.0065 (UTC) FILETIME=[80D05710:01C4AF6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: nemo Subject: [nemo] Announcing the Global HAHA draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable As a result of the discussions at the previous IETF and in the ML, we decided to split the HAHA draft in a local part that covers intra-site load balancing and high availability, and a global part that enables the geographical distribution of Home over the Internet.=20 The version 00 of the global HAHA draft is now available at: http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.tx t Pascal From nemo-bounces@ietf.org Mon Oct 11 05:22:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16904 for ; Mon, 11 Oct 2004 05:22:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwMX-00047V-Me; Mon, 11 Oct 2004 05:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwLd-0003rx-PX for nemo@megatron.ietf.org; Mon, 11 Oct 2004 05:20:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16620 for ; Mon, 11 Oct 2004 05:20:03 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwW9-0003EF-2q for nemo@ietf.org; Mon, 11 Oct 2004 05:30:57 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9B9LLh2022385; Mon, 11 Oct 2004 02:21:22 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i9B9Iq51024810; Mon, 11 Oct 2004 04:18:52 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 201B788CF7C; Mon, 11 Oct 2004 11:20:01 +0200 (CEST) Message-ID: <416A503B.40903@motorola.com> Date: Mon, 11 Oct 2004 11:19:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: [nemo] NEMO RO Problem References: <200410080442.i984gpab017111@citheronia.ucdavis.edu> In-Reply-To: <200410080442.i984gpab017111@citheronia.ucdavis.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA4945791A6EFB27D8188FF6" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nemo@ietf.org, =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEA4945791A6EFB27D8188FF6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fan Zhao wrote: > That is what I am exactly trying to do in this draft. I apologize for > using a confusing term, CR. Actually I should replace CR with > Correspondent Agent (CA). Just a note to say that CA is widely known as Certificate Authority. Alex --------------enigEA4945791A6EFB27D8188FF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBalBAMmC0w56zj54RAmQsAJ9216f7QxSxnV89Hlmg9tUjd6jZVQCgolQc hOQsDE9Jgrc3pVu4/uJVFbs= =AKcL -----END PGP SIGNATURE----- --------------enigEA4945791A6EFB27D8188FF6-- From nemo-bounces@ietf.org Mon Oct 11 13:20:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24155 for ; Mon, 11 Oct 2004 13:20:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3ms-0007wd-0v; Mon, 11 Oct 2004 13:16:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3iz-0006pT-QF for nemo@megatron.ietf.org; Mon, 11 Oct 2004 13:12:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23143 for ; Mon, 11 Oct 2004 13:12:38 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3tY-0003e7-9O for nemo@ietf.org; Mon, 11 Oct 2004 13:23:37 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BHCbh27195 for ; Mon, 11 Oct 2004 20:12:37 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 20:12:28 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9BHCSJv013425 for ; Mon, 11 Oct 2004 20:12:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00j54Xe2; Mon, 11 Oct 2004 20:12:27 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BHCPa06995 for ; Mon, 11 Oct 2004 20:12:26 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 12:12:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2004 10:12:22 -0700 Message-ID: <95C69691E3067248918990C7214854B55506B5@mvebe001.americas.nokia.com> Thread-Topic: RFC-to-be: Thread-Index: AcSu75LzSJuFXMvgSrCGCBPuxjWM1gAxYM/A To: X-OriginalArrivalTime: 11 Oct 2004 17:12:25.0062 (UTC) FILETIME=[7A655860:01C4AFB5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: RFC-to-be: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello all, IANA assignments have been done for the Basic Support protocol. we can start using these values in implementations. Vijay > -----Original Message----- > From: ext Michelle S. Cotton [mailto:cotton@icann.org] > Sent: Sunday, October 10, 2004 10:29 AM > To: Devarapalli Vijay (Nokia-NRC/MtView); ryuji@sfc.wide.ad.jp; > Alexandru.Petrescu@motorola.com; pthubert@cisco.com > Cc: tj@kniveton.com; ernst@sfc.wide.ad.jp; Thomas Narten; Margaret > Wasserman; iana@iana.org > Subject: RFC-to-be: >=20 >=20 > Authors: >=20 > We have completed the IANA Actions for RFC-to-be:=20 > . >=20 > We have registered the Mobile Network Prefix Option with value 6: >=20 > 6 Mobile Network Prefix Option [RFC-ietf-nemo-basic-support-03.txt] >=20 > We have also registered the following status codes: >=20 > 140 Mobile Router Operation not permitted = [RFC-ietf-nemo-basic-support-03.txt] > 141 Invalid Prefix = [RFC-ietf-nemo-basic-support-03.txt] > 142 Not Authorized for Prefix = [RFC-ietf-nemo-basic-support-03.txt] > 143 Forwarding Setup failed = [RFC-ietf-nemo-basic-support-03.txt] >=20 > See: >=20 > Please let us know if all looks OK. As soon as we=20 > receive your confirmation we will send a message to=20 > the RFC-Editor indicating the IANA Actions are complete. >=20 > Thank you, >=20 > Michelle Cotton > IANA >=20 >=20 From nemo-bounces@ietf.org Tue Oct 12 03:07:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23916 for ; Tue, 12 Oct 2004 03:07:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGb5-0001lO-KZ; Tue, 12 Oct 2004 02:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGWk-0000Tv-UX for nemo@megatron.ietf.org; Tue, 12 Oct 2004 02:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23120 for ; Tue, 12 Oct 2004 02:52:53 -0400 (EDT) Received: from berlin.ucdavis.edu ([169.237.104.158]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGhR-0006kn-6u for nemo@ietf.org; Tue, 12 Oct 2004 03:03:57 -0400 Received: from syrphus.ucdavis.edu (syrphus.ucdavis.edu [169.237.104.152]) by berlin.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9C6qjEK022433; Mon, 11 Oct 2004 23:52:46 -0700 (PDT) Received: from syrphus.ucdavis.edu (localhost [127.0.0.1]) by syrphus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9C6qjZf010459; Mon, 11 Oct 2004 23:52:45 -0700 (PDT) Received: (from www@localhost) by syrphus.ucdavis.edu (8.12.10/8.12.9/Submit) id i9C6qjMA010457; Mon, 11 Oct 2004 23:52:45 -0700 (PDT) Date: Mon, 11 Oct 2004 23:52:45 -0700 (PDT) Message-Id: <200410120652.i9C6qjMA010457@syrphus.ucdavis.edu> To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Subject: Re: [nemo] NEMO RO Problem From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Carlos, Sorry about the delay. Please see my reply in line. Best regards, fan > Dear Fan, > > Thanks for your reply. Please see, some comments in-line > > El vie, 08-10-2004 a las 06:42, Fan Zhao escribi=F3: > > Not really. In the very extreme case where HA is located on the routing > > path between the location of CN and the location of MR, the route taken > > by the traffic in NEMO Basic Support is the same as the =93optimal route= > =94 > > according to the definition in the document. > > OK, you are right. I was thinking in terms of overhead too ... > That is right. I agree. > > Assume that there are n CNs scattering around the Internet, which means > > that there is no one single CR topologically close to all CNs. If MR > > performs the RO functions with all the CN/CRs, the overhead (the number > > of tunnels and states) in MR is O(n). By choosing HA as CR for all these > > n CNs, MR just needs to maintain one tunnel with HA.=20 > >=20 > > On the other hand, from the perspective of CR, if there are m MRs > > belonging to the same home network scattering around the Internet, > > because of the same reason, CR may also choose to forward the traffic to > > HA rather than each MR. So HA play dual roles, both CR and HA here,=20 > > though we may only put emphasis on one over the other before.=20 > > Yes, but if the traffic is sent to the HA, that's the operation of the > NEMO Basic Support protocol, without RO, isn't it? I agree that there > may be scenarios in which performing RO would be worse than not > performing it, so there is a tradeoff. > Yes, you are right. > >=20 > > These are all about the tradeoff. Even though MR has to go though its HA,= > =20 > > because the traffic forwarded by this MR is aggregated to one=20 > > destination, from the parent MR point of view the number of CNs (The=20 > > child MR acts as one of MNNs.) is reduced, the better route than that in=20 > > NEMO basic support is still possible because the parent MR could perform=20 > > RO function.=20 > > I don't understand this sentence (sorry about me poor understanding > ;->). Do you mean, in a nested NEMO, going only through a single HA, as > a kind of RO? > The RO solution should allow each MR to decide whether it performs RO or not independently. When all MRs perform RO, the best route is formed. I will address it more in the next version. > > If I understand correctly, you are talking about the sub-optimal route=20 > > when VMN performs MIP6 RO. Is it right? IMO, NEMO RO solution should not=20 > > make any change to protocols running on MNN. Maybe it sounds too solution= > - > > I completely agree that a general and global NEMO RO solution should > not (if possible) change the protocols running on MNNs. But, OTOH, I > think that besides having such a solution, perhaps it will be worth also > to study some additional mechanisms, fully compatible with the "NEMO > global RO solution", that may enhance the performance for some MNNs. That will be very interesting. Any thoughts? > > Thanks a lot. > > Kind Regards, > > Carlos J. > > > specific, what NEMO RO can do is to let MR broadcast the information of=20 > > NEMO RO capability (Not very great, still require the interaction) or=20 > > even better I see the possibility that NEMO RO can both keep the=20 > > transparency and remove the sub-optimal route caused by MIP6 RO. So I=20 > > strongly feel we should introduce the changes only to MR/CA/HA, one level= > =20 > > above MNN. Note that CA includes the case of NEMO-aware CN.=20 > > =20 > > > Thanks a lot. > > >=20 > > > Kind regards, > > >=20 > > > Carlos J. > > >=20 > > >=20 > > > >=3D20 > > > > Sincerely, > > > > fan > > > --=3D20 > > > Carlos Jes=3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > > >=20 > --=20 > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > From nemo-bounces@ietf.org Tue Oct 12 05:57:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04417 for ; Tue, 12 Oct 2004 05:57:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJIZ-00036J-2Z; Tue, 12 Oct 2004 05:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJBy-0007CF-BM for nemo@megatron.ietf.org; Tue, 12 Oct 2004 05:43:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03686 for ; Tue, 12 Oct 2004 05:43:36 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHJMf-00014V-Da for nemo@ietf.org; Tue, 12 Oct 2004 05:54:42 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2004 11:55:49 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9C9gYT7019310; Tue, 12 Oct 2004 11:43:01 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 11:42:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO RO Problem Date: Tue, 12 Oct 2004 11:42:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2C0540@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NEMO RO Problem Thread-Index: AcSwKi0GlcC/1cfbRjmCE6Da/JKVoAAFJ2pw From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 12 Oct 2004 09:42:59.0425 (UTC) FILETIME=[DC096D10:01C4B03F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > > > > I completely agree that a general and global NEMO RO solution > should > > not (if possible) change the protocols running on MNNs. But, OTOH, I > > think that besides having such a solution, perhaps it will be worth = also > > to study some additional mechanisms, fully compatible with the "NEMO > > global RO solution", that may enhance the performance for some MNNs. >=20 > That will be very interesting. Any thoughts? >=20 One specific angle on that is provided by the global HAHA protocol. I'm = not sure if we can make (should) the proxy registration full transparent = to the MNN. But if the proxy can act for both the MR and the MNN, it = does not make a lot of difference. Interesting :) Should we make the = proxies multiSP? http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt= Pascal From nemo-bounces@ietf.org Tue Oct 12 07:28:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09480 for ; Tue, 12 Oct 2004 07:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKl8-00015G-H3; Tue, 12 Oct 2004 07:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKfj-0008O3-Vi for nemo@megatron.ietf.org; Tue, 12 Oct 2004 07:18:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08981 for ; Tue, 12 Oct 2004 07:18:25 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHKqS-0002VZ-CF for nemo@ietf.org; Tue, 12 Oct 2004 07:29:32 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 56E2440299; Tue, 12 Oct 2004 13:17:54 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 115164029A; Tue, 12 Oct 2004 13:17:54 +0200 (CEST) Subject: Re: [nemo] NEMO RO Problem From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Fan Zhao In-Reply-To: <200410120652.i9C6qjMA010457@syrphus.ucdavis.edu> References: <200410120652.i9C6qjMA010457@syrphus.ucdavis.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SgqLRFFuyJrbA1YORbZn" Organization: Universidad Carlos III de Madrid Message-Id: <1097579907.2407.65.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 12 Oct 2004 13:18:27 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-SgqLRFFuyJrbA1YORbZn Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Dear Fan, El mar, 12-10-2004 a las 08:52, Fan Zhao escribi=F3: > > I completely agree that a general and global NEMO RO solution=20 > should > > not (if possible) change the protocols running on MNNs. But, OTOH, I > > think that besides having such a solution, perhaps it will be worth als= o > > to study some additional mechanisms, fully compatible with the "NEMO > > global RO solution", that may enhance the performance for some MNNs. >=20 > That will be very interesting. Any thoughts? =20 Well, maybe now it's too soon to address this issue, but the point is that there will be likely some interesting solutions that will be worth to look at. One example is what Pascal has pointed out, but there can be many others, e.g. based on prefix delegation, MIPv6, etc... Regards, Carlos J. =09 >=20 >=20 > >=20 > > Thanks a lot. > >=20 > > Kind Regards, > >=20 > > Carlos J. > >=20 > > > specific, what NEMO RO can do is to let MR broadcast the information=20 > of=3D20 > > > NEMO RO capability (Not very great, still require the interaction)=20 > or=3D20 > > > even better I see the possibility that NEMO RO can both keep the=3D20 > > > transparency and remove the sub-optimal route caused by MIP6 RO. So=20 > I=3D20 > > > strongly feel we should introduce the changes only to MR/CA/HA, one=20 > level=3D > > =3D20 > > > above MNN. Note that CA includes the case of NEMO-aware CN.=3D20 > > > =3D20 > > > > Thanks a lot. > > > >=3D20 > > > > Kind regards, > > > >=3D20 > > > > Carlos J. > > > >=3D20 > > > >=3D20 > > > > >=3D3D20 > > > > > Sincerely, > > > > > fan > > > > --=3D3D20 > > > > Carlos Jes=3D3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > > > >=3D20 > > --=3D20 > > Carlos Jes=3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > >=20 --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-SgqLRFFuyJrbA1YORbZn Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBa72D5vKyPtrWqkARAopTAJ9ED2fbFcSlv9M6RehPqTxQ4l+m+wCg30zt lHqrHYYc/9HNagMDj2qDNhk= =xbRt -----END PGP SIGNATURE----- --=-SgqLRFFuyJrbA1YORbZn-- From nemo-bounces@ietf.org Wed Oct 13 07:45:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17438 for ; Wed, 13 Oct 2004 07:45:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhYE-0006Ym-5B; Wed, 13 Oct 2004 07:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhPC-00047v-AM for nemo@megatron.ietf.org; Wed, 13 Oct 2004 07:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16292 for ; Wed, 13 Oct 2004 07:34:50 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhZz-0002YY-W1 for nemo@ietf.org; Wed, 13 Oct 2004 07:46:08 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2004 13:47:17 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9DBXYTB000225; Wed, 13 Oct 2004 13:34:11 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 13:34:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 13:34:06 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com> Thread-Topic: RO between MR and CN Thread-Index: AcSxFgjeV7NBR02LRcyLDmAOXQGd0QAAdRYw From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 13 Oct 2004 11:34:08.0276 (UTC) FILETIME=[8D651540:01C4B118] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: RO between MR and CN X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Tania I was thinking things like of snooping. MR might intercept all packets = to LFN, recognize a HoT and keep it. I remember discussing that with = Alex long ago... Anyway, we try to say "don't take that path" as opposed = to describe a solution in details. It seems preferable, for instance, to establish a MR-CR tunnel and = exchange fine grained routes for MNPs over the tunnel (route = projection). Pascal > -----Original Message----- > From: T=E2nia Pinto Cal=E7ada [mailto:tcalcada@inescporto.pt] > Sent: mercredi 13 octobre 2004 13:16 > To: nemo@ietf.org > Cc: Pascal Thubert (pthubert) > Subject: RO between MR and CN >=20 > Hello, >=20 >=20 >=20 > I am interested in route optimization between the MR and the CN. I = read the taxonomy draft > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents = related to RO: >=20 > draft-jeong-nemo-ro-ndproxy-02.txt >=20 > draft-leekj-nemo-ro-pd-02.txt >=20 > draft-na-nemo-gen-ro-model-00.txt >=20 > draft-na-nemo-path-control-header-00.txt >=20 > draft-wakikawa-nemo-orc-00.txt >=20 > ROProblem.txt >=20 >=20 >=20 > I also read some threads of the NEMO mailing list = http://www1.ietf.org/mail- > archive/web/nemo/current/index.html archive/web/nemo/current/index.html> , however I am still looking for = a document that > describes a solution for the RO between the MR and the CN. >=20 >=20 >=20 > The taxonomy draft says at section 2: >=20 > "A major issue with this form of optimization is that the end-to-end >=20 > principle of the MIPv6 Reverse Routability (RR) test is broken. = The >=20 > RR test is meant to ensure the care-of address (CoA) and the home >=20 > address (HoA) are collocated. With a mobile network, when the MR >=20 > performs RO on behalf of the MNNs, the CoA in BU will be the MR's >=20 > CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. >=20 >=20 >=20 > Some tricks may be performed on the fly by the MRs but it seems = that >=20 > a clean MR-to-CN optimization for Nemo will impact the CN = function." >=20 >=20 >=20 > Can somebody point the "tricks" that may be performed, or indicate a = document that explores > this subject? >=20 >=20 >=20 > Regards, >=20 > Tania Calcada From nemo-bounces@ietf.org Wed Oct 13 08:08:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18876 for ; Wed, 13 Oct 2004 08:08:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhlr-0001i6-S1; Wed, 13 Oct 2004 07:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHh6y-0007YG-SR for nemo@megatron.ietf.org; Wed, 13 Oct 2004 07:16:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14147 for ; Wed, 13 Oct 2004 07:15:59 -0400 (EDT) Received: from animal.inescn.pt ([192.35.246.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhHo-000235-PA for nemo@ietf.org; Wed, 13 Oct 2004 07:27:18 -0400 Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.12.10/8.12.11/19) with ESMTP id i9DBFjMI011186; Wed, 13 Oct 2004 12:15:45 +0100 (WEST) Received: from yang.inescn.pt (yang.inescn.pt [194.117.24.169]) by animal.inescn.pt (8.12.10/8.12.10/7) with ESMTP id i9DBFbd1011165; Wed, 13 Oct 2004 12:15:38 +0100 (WEST) Received: from nicles (nicles.inescn.pt [194.117.24.79]) by yang.inescn.pt (Postfix) with ESMTP id 4AEB570168; Wed, 13 Oct 2004 12:15:37 +0100 (WEST) From: =?iso-8859-1?Q?T=E2nia_Pinto_Cal=E7ada?= To: Date: Wed, 13 Oct 2004 12:15:38 +0100 Organization: INESC Porto Message-ID: <000d01c4b115$f7d57e90$451975c2@inescn.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C4B11E.5999E690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by amavisd-new at inescporto.pt X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 X-Mailman-Approved-At: Wed, 13 Oct 2004 07:58:17 -0400 Cc: pthubert@cisco.com Subject: [nemo] RO between MR and CN X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcalcada@inescporto.pt List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C4B11E.5999E690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I am interested in route optimization between the MR and the CN. I read the taxonomy draft (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents related to RO: draft-jeong-nemo-ro-ndproxy-02.txt draft-leekj-nemo-ro-pd-02.txt draft-na-nemo-gen-ro-model-00.txt draft-na-nemo-path-control-header-00.txt draft-wakikawa-nemo-orc-00.txt ROProblem.txt =20 I also read some threads of the NEMO mailing list http://www1.ietf.org/mail-archive/web/nemo/current/index.html, however I am still looking for a document that describes a solution for the RO between the MR and the CN.=20 =20 The taxonomy draft says at section 2: =93A major issue with this form of optimization is that the end-to-end principle of the MIPv6 Reverse Routability (RR) test is broken. The RR test is meant to ensure the care-of address (CoA) and the home address (HoA) are collocated. With a mobile network, when the MR performs RO on behalf of the MNNs, the CoA in BU will be the MR's CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. =20 Some tricks may be performed on the fly by the MRs but it seems that a clean MR-to-CN optimization for Nemo will impact the CN = function.=94 =20 Can somebody point the =93tricks=94 that may be performed, or indicate a document that explores this subject? =20 Regards, Tania Calcada ------=_NextPart_000_000E_01C4B11E.5999E690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mensagem

Hello,

 

I am=20 interested in route optimization between the MR and the CN. I read the = taxonomy=20 draft (draft-thubert-nemo-ro-taxonomy-02.txt), and several other = documents=20 related to RO:

draft-jeong-nemo-ro-ndproxy-02.txt=

draft-leekj-nemo-ro-pd-02.txt

draft-na-nemo-gen-ro-model-00.txt<= /P>

draft-na-nemo-path-control-header-00.txt<= /SPAN>

draft-wakikawa-nemo-orc-00.txt

=

ROProblem.txt

 

I also read=20 some threads of the NEMO = mailing list=20 http://www1.ietf.org/mail-archive/web/nemo/current/index.html, however I am still looking for = a document=20 that describes a solution for the RO between the MR and the CN.=20

 

The=20 taxonomy draft says at section 2:

“A=20 major issue with this form of optimization is that the=20 end-to-end

   principle of the MIPv6 = Reverse=20 Routability (RR) test is broken.  = The

   RR test is meant to = ensure the=20 care-of address (CoA) and the home

   address (HoA) are = collocated. With=20 a mobile network, when the MR

   performs RO on behalf of = the MNNs,=20 the CoA in BU will be the MR's

   CoA.  Thus, a MNN is reachable via = the CoA,=20 but not at the CoA.

 

   Some tricks may be = performed on=20 the fly by the MRs but it seems that

   a clean MR-to-CN = optimization for=20 Nemo will impact the CN = function.”

 

Can=20 somebody point the “tricks” that may be performed, or = indicate a document that=20 explores this subject?

 

Regards,

Tania=20 Calcada

------=_NextPart_000_000E_01C4B11E.5999E690-- From nemo-bounces@ietf.org Wed Oct 13 08:38:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22452 for ; Wed, 13 Oct 2004 08:38:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHiEW-0000nN-En; Wed, 13 Oct 2004 08:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHiDb-0000Wu-9b for nemo@megatron.ietf.org; Wed, 13 Oct 2004 08:26:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21362 for ; Wed, 13 Oct 2004 08:26:54 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHiOS-0003v6-S4 for nemo@ietf.org; Wed, 13 Oct 2004 08:38:13 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9DCS9G2028231; Wed, 13 Oct 2004 05:28:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i9DCPeJv006632; Wed, 13 Oct 2004 07:25:40 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 478C088CF7B; Wed, 13 Oct 2004 14:26:49 +0200 (CEST) Message-ID: <416D1F03.5010007@motorola.com> Date: Wed, 13 Oct 2004 14:26:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcalcada@inescporto.pt Subject: Re: [nemo] RO between MR and CN References: <000d01c4b115$f7d57e90$451975c2@inescn.pt> In-Reply-To: <000d01c4b115$f7d57e90$451975c2@inescn.pt> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAEBA3E2AA762CF1A37D35540" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAEBA3E2AA762CF1A37D35540 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Tania, how are you. Tânia Pinto Calçada wrote: > Some tricks may be performed on the fly by the MRs but it seems that > a clean MR-to-CN optimization for Nemo will impact the CN function.” > > > Can somebody point the “tricks” that may be performed, or indicate a > document that explores this subject? Tania, do you know about the RR tests performed by Mobile IPv6 for hosts? It is a Mobile Node and the Correspondent Node that perform such "pings" to each other, sort of confirming their identity (the CoA and the HoA are checked for being reachable). Since NEMO uses a Mobile Router instead of a Mobile Host, and since the LFN (fixed node within the moving network) does not perform Mobile IPv6 functions, then some "tricks" may be needed on MR in order to extend RR. RR would be performed by MR "on behalf" of LFN. This has security aspects in that MR should "be sure" it does the RR tests for LFN (and not for an attacker), "delegation of security between LFN and MR" mechanisms were suggested some time ago, check the old old monet NEMO mmailing lists archives, I'll prepare a URL for that soon. Otherwise I'm not aware of other documents extending RR to support MR. Alex --------------enigAEBA3E2AA762CF1A37D35540 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBbR8JMmC0w56zj54RAqnaAJ9dYWZQozj98oPHE/lNsy5Noe/mGgCg+KH+ Rcp8AdEKJmuDp1YMVsgGwes= =eLcN -----END PGP SIGNATURE----- --------------enigAEBA3E2AA762CF1A37D35540-- From nemo-bounces@ietf.org Wed Oct 13 10:27:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01481 for ; Wed, 13 Oct 2004 10:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHk1D-0002Yt-CJ; Wed, 13 Oct 2004 10:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjue-0000AI-EB for nemo@megatron.ietf.org; Wed, 13 Oct 2004 10:15:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29914 for ; Wed, 13 Oct 2004 10:15:26 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHk5T-0005xP-Tp for nemo@ietf.org; Wed, 13 Oct 2004 10:26:46 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9DEGbG2028800; Wed, 13 Oct 2004 07:16:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9DEFGXO006395; Wed, 13 Oct 2004 09:15:17 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F157688CF7C; Wed, 13 Oct 2004 16:15:15 +0200 (CEST) Message-ID: <416D386E.2030507@motorola.com> Date: Wed, 13 Oct 2004 16:15:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: archives about RO and mobile networks (was: [nemo] RO between MR and CN) References: <000d01c4b115$f7d57e90$451975c2@inescn.pt> <416D1F03.5010007@motorola.com> In-Reply-To: <416D1F03.5010007@motorola.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5710668102279BD4818041C" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5710668102279BD4818041C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Alexandru Petrescu wrote: >> Can somebody point the “tricks” that may be performed, or indicate >> a document that explores this subject? > > This has security aspects in that MR should "be sure" it does the RR > tests for LFN (and not for an attacker), "delegation of security > between LFN and MR" mechanisms were suggested some time ago, check > the old old monet NEMO mmailing lists archives, I'll prepare a URL > for that soon. Hi, I wanted to mention that much RO discussion at the beginning of the monet BoF (cca December 2001) was captured on archives: http://www.mobilenetworks.org/nemo/archives/monet-arch-dec01-feb02.txt http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt http://www.mobilenetworks.org/nemo/archives/nemo-arch-nov02-may03.txt Browsing txt files is difficult, but sometimes rewarding. For example, if interested about initial discussions about Mobile Routers see cca 1994 for Mobile IPv4 predecessors: http://www.citi.umich.edu/projects/mobile/mobile-ip-mail/502 I also take this opportunity to say that the NEMO Base DT mails are archived but I'm not sure about the policy of making them public. That archive does not contain RO discussion IIRC. Also take this opportunity to say that the idea of BGP with mobile networks and no NEMO was recently presented at NANOG too: http://www.nanog.org/mtg-0405/pdf/abarbanel.pdf Alex --------------enigC5710668102279BD4818041C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBbThzMmC0w56zj54RAvFcAKDIQzwoJfvbRqzQm+DKF0X3O+KtlQCgnBMu MFdmX7O5Lc/AuXxAER9hqpw= =0Tff -----END PGP SIGNATURE----- --------------enigC5710668102279BD4818041C-- From nemo-bounces@ietf.org Wed Oct 13 10:42:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03946 for ; Wed, 13 Oct 2004 10:42:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkDH-00074C-9E; Wed, 13 Oct 2004 10:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkA2-0005S7-JK for nemo@megatron.ietf.org; Wed, 13 Oct 2004 10:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02246 for ; Wed, 13 Oct 2004 10:31:20 -0400 (EDT) Received: from animal.inescn.pt ([192.35.246.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkKr-0006IT-RH for nemo@ietf.org; Wed, 13 Oct 2004 10:42:40 -0400 Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.12.10/8.12.11/19) with ESMTP id i9DEV7MI001561; Wed, 13 Oct 2004 15:31:07 +0100 (WEST) Received: from yang.inescn.pt (yang.inescn.pt [194.117.24.169]) by animal.inescn.pt (8.12.10/8.12.10/7) with ESMTP id i9DEUtd1001538; Wed, 13 Oct 2004 15:30:59 +0100 (WEST) Received: from nicles.inescn.pt (nicles.inescn.pt [194.117.24.79]) by yang.inescn.pt (Postfix) with ESMTP id 2ECD870168; Wed, 13 Oct 2004 15:30:55 +0100 (WEST) From: Tania Pinto Calcada To: Alexandru Petrescu Subject: Re: [nemo] RO between MR and CN Date: Wed, 13 Oct 2004 15:30:55 +0100 User-Agent: KMail/1.6.1 References: <000d01c4b115$f7d57e90$451975c2@inescn.pt> <416D1F03.5010007@motorola.com> In-Reply-To: <416D1F03.5010007@motorola.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200410131530.55646.tcalcada@inescporto.pt> X-Virus-Scanned: by amavisd-new at inescporto.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcalcada@inescporto.pt List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Alex, comments in-line On Wednesday 13 October 2004 13:26, Alexandru Petrescu wrote: > Tania, do you know about the RR tests performed by Mobile IPv6 for > hosts? It is a Mobile Node and the Correspondent Node that perform such > "pings" to each other, sort of confirming their identity (the CoA and > the HoA are checked for being reachable). > Yes I know how this Return Routability Procedure works. > Since NEMO uses a Mobile Router instead of a Mobile Host, and since the > LFN (fixed node within the moving network) does not perform Mobile IPv6 > functions, then some "tricks" may be needed on MR in order to extend RR. > RR would be performed by MR "on behalf" of LFN. > > This has security aspects in that MR should "be sure" it does the RR > tests for LFN (and not for an attacker), "delegation of security between > LFN and MR" mechanisms were suggested some time ago, check the old old > monet NEMO mmailing lists archives, I'll prepare a URL for that soon. > I don't find these archives you mentioned, can you send an URL (a generic one, at least). What about these aspects that were described in the taxonomy draft, are there any solutions? " A major issue with this form of optimization is that the end-to-end principle of the MIPv6 Reverse Routability (RR) test is broken. ... With a mobile network, when the MR performs RO on behalf of the MNNs, the CoA in BU will be the MR's CoA. Thus, a MNN is reachable via the CoA, but not at the CoA." Tania From nemo-bounces@ietf.org Wed Oct 13 10:54:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05084 for ; Wed, 13 Oct 2004 10:54:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkT2-0002m4-AE; Wed, 13 Oct 2004 10:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkIF-0008II-6o for nemo@megatron.ietf.org; Wed, 13 Oct 2004 10:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03636 for ; Wed, 13 Oct 2004 10:39:48 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkT5-0006Rz-Nb for nemo@ietf.org; Wed, 13 Oct 2004 10:51:09 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 316AE40696; Wed, 13 Oct 2004 16:39:15 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id CC98E40690; Wed, 13 Oct 2004 16:39:14 +0200 (CEST) Subject: Re: [nemo] RO between MR and CN From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <416D1F03.5010007@motorola.com> References: <000d01c4b115$f7d57e90$451975c2@inescn.pt> <416D1F03.5010007@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L0xiASdNc8ALH84F4lL0" Organization: Universidad Carlos III de Madrid Message-Id: <1097678389.2611.27.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 13 Oct 2004 16:39:49 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-L0xiASdNc8ALH84F4lL0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tania, Alex, Within the FP6 Daidalos European project, we are defining and implementing a NEMO RO solution. One part of this solution consists in performing RO between the MR (on behalf of the LFNs) and the CN. The solution was presented last August in the ASWN 2004 workshop. It is available at: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf Kind regards, Carlos J. El mi=C3=A9, 13-10-2004 a las 14:26, Alexandru Petrescu escribi=C3=B3: > Hello Tania, how are you. >=20 > T=C3=A2nia Pinto Cal=C3=A7ada wrote: > > Some tricks may be performed on the fly by the MRs but it seems that > > a clean MR-to-CN optimization for Nemo will impact the CN function.=E2= =80=9D > >=20 > >=20 > > Can somebody point the =E2=80=9Ctricks=E2=80=9D that may be performed, = or indicate a > > document that explores this subject? >=20 > Tania, do you know about the RR tests performed by Mobile IPv6 for > hosts? It is a Mobile Node and the Correspondent Node that perform such > "pings" to each other, sort of confirming their identity (the CoA and > the HoA are checked for being reachable). >=20 > Since NEMO uses a Mobile Router instead of a Mobile Host, and since the > LFN (fixed node within the moving network) does not perform Mobile IPv6 > functions, then some "tricks" may be needed on MR in order to extend RR. > RR would be performed by MR "on behalf" of LFN. >=20 > This has security aspects in that MR should "be sure" it does the RR > tests for LFN (and not for an attacker), "delegation of security between > LFN and MR" mechanisms were suggested some time ago, check the old old > monet NEMO mmailing lists archives, I'll prepare a URL for that soon. >=20 > Otherwise I'm not aware of other documents extending RR to support MR. >=20 > Alex --=20 Carlos Jes=C3=BAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-L0xiASdNc8ALH84F4lL0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBbT405vKyPtrWqkARAs+1AJ98fbIpUjU6GO3eTak0GtEsy9QJxgCgowDc dXgeP2iOUXv7hUvTSCs8k9Y= =Zodp -----END PGP SIGNATURE----- --=-L0xiASdNc8ALH84F4lL0-- From nemo-bounces@ietf.org Wed Oct 13 13:28:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17656 for ; Wed, 13 Oct 2004 13:28:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmmY-0005dJ-Mf; Wed, 13 Oct 2004 13:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmey-0003jQ-VP for nemo@megatron.ietf.org; Wed, 13 Oct 2004 13:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16454 for ; Wed, 13 Oct 2004 13:11:31 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmpx-0000qz-Ku for nemo@ietf.org; Wed, 13 Oct 2004 13:22:54 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 575DC5D09C; Thu, 14 Oct 2004 02:10:56 +0900 (JST) Date: Thu, 14 Oct 2004 02:08:45 +0900 (JST) Message-Id: <20041014.020845.21897134.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Subject: Re: [nemo] RE: RO between MR and CN From: Masafumi Watari In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, On Wed, 13 Oct 2004 13:34:06 +0200, "Pascal Thubert (pthubert)" wrote: > Hi Tania > = > I was thinking things like of snooping. MR might intercept all packet= s to LFN, recognize a HoT and keep it. I remember discussing that with = Alex long ago... Anyway, we try to say "don't take that path" as oppose= d to describe a solution in details. I don't think its possible to provide RO while keeping the RR function of MIPv6 untouched. It would probably require modification of the packet at MR to use the HoA opt and the routing header for every packet, if we want to keep the MIPv6 spec as is. > It seems preferable, for instance, to establish a MR-CR tunnel and ex= change fine grained routes for MNPs over the tunnel (route projection).= I think I agree on this. Masafumi Watari > Pascal > = > > -----Original Message----- > > From: T=E2nia Pinto Cal=E7ada [mailto:tcalcada@inescporto.pt] > > Sent: mercredi 13 octobre 2004 13:16 > > To: nemo@ietf.org > > Cc: Pascal Thubert (pthubert) > > Subject: RO between MR and CN > > = > > Hello, > > = > > = > > = > > I am interested in route optimization between the MR and the CN. I = read the taxonomy draft > > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other document= s related to RO: > > = > > draft-jeong-nemo-ro-ndproxy-02.txt > > = > > draft-leekj-nemo-ro-pd-02.txt > > = > > draft-na-nemo-gen-ro-model-00.txt > > = > > draft-na-nemo-path-control-header-00.txt > > = > > draft-wakikawa-nemo-orc-00.txt > > = > > ROProblem.txt > > = > > = > > = > > I also read some threads of the NEMO mailing list http://www1.ietf.= org/mail- > > archive/web/nemo/current/index.html > archive/web/nemo/current/index.html> , however I am still looking f= or a document that > > describes a solution for the RO between the MR and the CN. > > = > > = > > = > > The taxonomy draft says at section 2: > > = > > "A major issue with this form of optimization is that the end-to-en= d > > = > > principle of the MIPv6 Reverse Routability (RR) test is broken. = The > > = > > RR test is meant to ensure the care-of address (CoA) and the hom= e > > = > > address (HoA) are collocated. With a mobile network, when the MR= > > = > > performs RO on behalf of the MNNs, the CoA in BU will be the MR'= s > > = > > CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. > > = > > = > > = > > Some tricks may be performed on the fly by the MRs but it seems = that > > = > > a clean MR-to-CN optimization for Nemo will impact the CN functi= on." > > = > > = > > = > > Can somebody point the "tricks" that may be performed, or indicate = a document that explores > > this subject? > > = > > = > > = > > Regards, > > = > > Tania Calcada > = > = > = From nemo-bounces@ietf.org Wed Oct 13 15:50:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29315 for ; Wed, 13 Oct 2004 15:50:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoxc-0007Uk-6S; Wed, 13 Oct 2004 15:38:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHonq-000664-Ci for nemo@megatron.ietf.org; Wed, 13 Oct 2004 15:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27514 for ; Wed, 13 Oct 2004 15:28:49 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHoub-0003jI-Cd for nemo@ietf.org; Wed, 13 Oct 2004 15:35:50 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 29C1D623D; Wed, 13 Oct 2004 12:23:26 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94107-10; Wed, 13 Oct 2004 12:23:25 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 3EDAD6227; Wed, 13 Oct 2004 12:23:25 -0700 (PDT) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 8E9B660E1; Wed, 13 Oct 2004 12:23:21 -0700 (PDT) In-Reply-To: <416D386E.2030507@motorola.com> References: <000d01c4b115$f7d57e90$451975c2@inescn.pt> <416D1F03.5010007@motorola.com> <416D386E.2030507@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <6C59D548-1D4D-11D9-9947-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: quoted-printable From: "T.J.Kniveton" Subject: How to read the NEMO archives (was Re: archives about RO and mobile networks (was: [nemo] RO between MR and CN)) Date: Wed, 13 Oct 2004 12:23:55 -0700 To: IETF NEMO WG X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I have (more or less) all of the MONET/NEMO list mails, and all of the=20= design team mails (which we all agreed to make public a while ago) on=20 my personal mail server, which I am making public. Set your incoming IMAP mail server to deimos.multihop.net You can use TLS/SSL, or not. But you must use password authentication,=20= because anonymous doesn't work with DIGEST/MD5 or CRAM/MD5 =20 authentication (for obvious reasons, if you think about it). userid: anonymous password: just use "anonymous" as your userid and your e-mail address as your=20 password, like anonymous ftp). The server is deimos.multihop.net, and -TJ On Oct 13, 2004, at 7:15 AM, Alexandru Petrescu wrote: > Alexandru Petrescu wrote: >>> Can somebody point the =93tricks=94 that may be performed, or = indicate >>> a document that explores this subject? >> This has security aspects in that MR should "be sure" it does the RR >> tests for LFN (and not for an attacker), "delegation of security=20 >> between LFN and MR" mechanisms were suggested some time ago, check=20 >> the old old monet NEMO mmailing lists archives, I'll prepare a URL=20 >> for that soon. > > Hi, I wanted to mention that much RO discussion at the beginning of = the > monet BoF (cca December 2001) was captured on archives: > > http://www.mobilenetworks.org/nemo/archives/monet-arch-dec01-feb02.txt > http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt > http://www.mobilenetworks.org/nemo/archives/nemo-arch-nov02-may03.txt > > Browsing txt files is difficult, but sometimes rewarding. For = example, > if interested about initial discussions about Mobile Routers see cca > 1994 for Mobile IPv4 predecessors: > http://www.citi.umich.edu/projects/mobile/mobile-ip-mail/502 > > I also take this opportunity to say that the NEMO Base DT mails are > archived but I'm not sure about the policy of making them public. = That > archive does not contain RO discussion IIRC. > > Also take this opportunity to say that the idea of BGP with mobile > networks and no NEMO was recently presented at NANOG too: > http://www.nanog.org/mtg-0405/pdf/abarbanel.pdf > > Alex From nemo-bounces@ietf.org Thu Oct 14 06:11:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25710 for ; Thu, 14 Oct 2004 06:11:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI2Xg-00037z-2C; Thu, 14 Oct 2004 06:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI2WL-0002bI-Rp for nemo@megatron.ietf.org; Thu, 14 Oct 2004 06:07:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25425 for ; Thu, 14 Oct 2004 06:07:39 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI2hQ-0006Ax-Vb for nemo@ietf.org; Thu, 14 Oct 2004 06:19:12 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id DC2D12EFEC; Thu, 14 Oct 2004 12:07:05 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 522D92EFA1; Thu, 14 Oct 2004 12:06:57 +0200 (CEST) Subject: Re: [nemo] RE: RO between MR and CN From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <20041014.020845.21897134.watari@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com> <20041014.020845.21897134.watari@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qHmakYyv6gKNF72Ex0Dt" Organization: Universidad Carlos III de Madrid Message-Id: <1097748452.2464.42.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 14 Oct 2004 12:07:32 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nemo@ietf.org, =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-qHmakYyv6gKNF72Ex0Dt Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Pascal, Masafumi, El mi=E9, 13-10-2004 a las 19:08, Masafumi Watari escribi=F3: > Hi, >=20 > On Wed, 13 Oct 2004 13:34:06 +0200, > "Pascal Thubert (pthubert)" wrote: >=20 > > Hi Tania > >=20 > > I was thinking things like of snooping. MR might intercept all packets = to LFN, recognize a HoT and keep it. I remember discussing that with Alex l= ong ago... Anyway, we try to say "don't take that path" as opposed to descr= ibe a solution in details. >=20 > I don't think its possible to provide RO while keeping the RR function > of MIPv6 untouched. It would probably require modification of the > packet at MR to use the HoA opt and the routing header for every > packet, if we want to keep the MIPv6 spec as is. Yes, one possible solution is the MR performing all the RR and RO signalling on behalf of the LFNs of the NEMO, in order to provide RO for LFNs that are communicating to CNs outside the NEMO. This is actually the solution we have proposed in MIRON (see my previous e-mail if you want a pointer to it), so the MR, as you said, has to process the packets sent/received by a LFN in order to insert HoA DO/remove RH. I agree that it could have some performance concerns if the process is performed to every LFN-CN "flow", but as we have already discussed in a previous thread, some mechanism should be used to perform the RO in a reasonable way. >=20 > > It seems preferable, for instance, to establish a MR-CR tunnel and exch= ange fine grained routes for MNPs over the tunnel (route projection). >=20 > I think I agree on this. This is, IMHO, a different approach, in which the RO requires some support from the routing infrastructure, and that present some advantages. But, OTOH, solutions based on MR-CN RO are also interesting IMHO, as an approach that does not require support in the routing infrastructure and puts the RO support functionality only in the edges, i.e. the CN and the MR (if the transparency to the MNNs is required, the MR is the other edge in which RO mechanisms can be added). What do you think? Kind Regards, Carlos J. >=20 > Masafumi Watari >=20 > > Pascal > >=20 > > > -----Original Message----- > > > From: T=E2nia Pinto Cal=E7ada [mailto:tcalcada@inescporto.pt] > > > Sent: mercredi 13 octobre 2004 13:16 > > > To: nemo@ietf.org > > > Cc: Pascal Thubert (pthubert) > > > Subject: RO between MR and CN > > >=20 > > > Hello, > > >=20 > > >=20 > > >=20 > > > I am interested in route optimization between the MR and the CN. I re= ad the taxonomy draft > > > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents = related to RO: > > >=20 > > > draft-jeong-nemo-ro-ndproxy-02.txt > > >=20 > > > draft-leekj-nemo-ro-pd-02.txt > > >=20 > > > draft-na-nemo-gen-ro-model-00.txt > > >=20 > > > draft-na-nemo-path-control-header-00.txt > > >=20 > > > draft-wakikawa-nemo-orc-00.txt > > >=20 > > > ROProblem.txt > > >=20 > > >=20 > > >=20 > > > I also read some threads of the NEMO mailing list http://www1.ietf.or= g/mail- > > > archive/web/nemo/current/index.html > > archive/web/nemo/current/index.html> , however I am still looking for= a document that > > > describes a solution for the RO between the MR and the CN. > > >=20 > > >=20 > > >=20 > > > The taxonomy draft says at section 2: > > >=20 > > > "A major issue with this form of optimization is that the end-to-end > > >=20 > > > principle of the MIPv6 Reverse Routability (RR) test is broken. T= he > > >=20 > > > RR test is meant to ensure the care-of address (CoA) and the home > > >=20 > > > address (HoA) are collocated. With a mobile network, when the MR > > >=20 > > > performs RO on behalf of the MNNs, the CoA in BU will be the MR's > > >=20 > > > CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. > > >=20 > > >=20 > > >=20 > > > Some tricks may be performed on the fly by the MRs but it seems th= at > > >=20 > > > a clean MR-to-CN optimization for Nemo will impact the CN function= ." > > >=20 > > >=20 > > >=20 > > > Can somebody point the "tricks" that may be performed, or indicate a = document that explores > > > this subject? > > >=20 > > >=20 > > >=20 > > > Regards, > > >=20 > > > Tania Calcada > >=20 > >=20 > >=20 --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-qHmakYyv6gKNF72Ex0Dt Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBbk/k5vKyPtrWqkARAhtTAKDFT8B013TOxN0Sv1kx9I1blrBgPwCcDSkt ELw4+nqjxvX8vdd7MuNgREY= =4Rbg -----END PGP SIGNATURE----- --=-qHmakYyv6gKNF72Ex0Dt-- From nemo-bounces@ietf.org Thu Oct 14 18:19:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13939 for ; Thu, 14 Oct 2004 18:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDvR-0000H4-MD; Thu, 14 Oct 2004 18:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDnP-00049a-5Z for nemo@megatron.ietf.org; Thu, 14 Oct 2004 18:10:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12462 for ; Thu, 14 Oct 2004 18:09:59 -0400 (EDT) Received: from havana.ucdavis.edu ([169.237.104.156]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDyd-0007PX-IG for nemo@ietf.org; Thu, 14 Oct 2004 18:21:40 -0400 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by havana.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9EM9vQf027417; Thu, 14 Oct 2004 15:09:58 -0700 (PDT) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9EM9vHL002371; Thu, 14 Oct 2004 15:09:57 -0700 (PDT) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id i9EM9vV8002370; Thu, 14 Oct 2004 15:09:57 -0700 (PDT) Date: Thu, 14 Oct 2004 15:09:57 -0700 (PDT) Message-Id: <200410142209.i9EM9vV8002370@celerio.ucdavis.edu> To: nemo@ietf.org Subject: Re: [nemo] NEMO RO Problem From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Alexandru.Petrescu@motorola.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >Fan Zhao wrote: >> That is what I am exactly trying to do in this draft. I apologize for >> using a confusing term, CR. Actually I should replace CR with >> Correspondent Agent (CA). > Just a note to say that CA is widely known as Certificate Authority. That is true, unfortunately. Is there any better term for it? Thanks. > Alex From nemo-bounces@ietf.org Fri Oct 15 03:14:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00852 for ; Fri, 15 Oct 2004 03:14:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMFp-0003oG-06; Fri, 15 Oct 2004 03:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMAL-0002fW-W4 for nemo@megatron.ietf.org; Fri, 15 Oct 2004 03:06:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00146 for ; Fri, 15 Oct 2004 03:06:16 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIMLb-0007jk-M6 for nemo@ietf.org; Fri, 15 Oct 2004 03:18:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2004 09:19:19 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9F757T5008665; Fri, 15 Oct 2004 09:05:38 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 09:05:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2004 09:05:33 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC307D5F@xmb-ams-337.emea.cisco.com> Thread-Topic: competition to Tree Discovery Thread-Index: AcSyhVuzER0aoC3IRcyawqnYIwVcHg== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 15 Oct 2004 07:05:37.0540 (UTC) FILETIME=[5F795C40:01C4B285] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [nemo] competition to Tree Discovery X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Just to show you that some ideas, very similar to Tree Discovery, are already being deployed. Mesh networking is a very new very competitive world that will need to settle down, as usual.=20 The edge we have at NEMO is that we can show something that integrates the mesh and the IP mobility (ie the metro last mile and the mobile device). So NEMO is a cool place to standardize this kind of technology, making sure that the end to end picture stays focussed. http://www.tropos.com/pdf/tropos_metro-scale.pdf=20 Pascal From nemo-bounces@ietf.org Fri Oct 15 03:19:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01275 for ; Fri, 15 Oct 2004 03:19:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMH5-0004En-UN; Fri, 15 Oct 2004 03:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMFg-0003mx-8R for nemo@megatron.ietf.org; Fri, 15 Oct 2004 03:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00680 for ; Fri, 15 Oct 2004 03:11:46 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27] helo=jazz.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIMQp-0007pj-B0 for nemo@ietf.org; Fri, 15 Oct 2004 03:23:30 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id i9F7AvOb026877 for ; Fri, 15 Oct 2004 16:10:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id i9F7Awx12587 for ; Fri, 15 Oct 2004 16:10:58 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id i9F7Awn16594 for ; Fri, 15 Oct 2004 16:10:58 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml22) id i9F7AwB02370 for nemo@ietf.org; Fri, 15 Oct 2004 16:10:58 +0900 (JST) Received: from nancy (localhost [127.0.0.1]) by soml22.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i9F7Av302365 for ; Fri, 15 Oct 2004 16:10:57 +0900 (JST) Message-Id: <200410150710.i9F7Av302365@soml22.jp.panasonic.com> Date: Fri, 15 Oct 2004 16:10:57 +0900 From: Masayuki Kumazawa To: nemo@ietf.org X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [nemo] Fw: I-D ACTION:draft-kumazawa-nemo-tbdnd-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi All, I would like to inform you that we have submitted the -01 of the duplicate network detection for split mobile network. We extended it to support multiple NEMO prefixes in a NEMO ( (n,1,1) and (n,1,n) described in the multihoming analysis draft). We think split mobile network would be a problem in a NEMO with multiple Mobile Routers. In a mobile network such as Wireless PAN, Mobile Routers might change their location, which will cause split mobile network problem. In a vehicle or plane network, the sharing of prefix will also provide redundancy or other benefits of multihoming. However, Home Agent has no way to know whether Mobile Routers claiming the same prefix are in the same NEMO. And a Mobile Router should be able to know whether prefixes configured on it are used in another NEMO. The objective of this document is to precipitate discussions in issues regarding multihomed NEMO with multiple Mobile Routers. Hence all comments are welcomed and greatly appreciated. ---------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Token based Duplicate Network Detection for split mobile network (Token based DND) Author(s) : M. Kumazawa, et al. Filename : draft-kumazawa-nemo-tbdnd-01.txt Pages : 20 Date : 2004-10-13 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-01.txt ---------------------------------------------------------------------- Best regards, Masayuki From nemo-bounces@ietf.org Fri Oct 15 03:23:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01468 for ; Fri, 15 Oct 2004 03:23:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMMw-0005S3-6S; Fri, 15 Oct 2004 03:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMJk-0004uD-I0 for nemo@megatron.ietf.org; Fri, 15 Oct 2004 03:16:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01020 for ; Fri, 15 Oct 2004 03:15:58 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIMV2-0007tu-Eh for nemo@ietf.org; Fri, 15 Oct 2004 03:27:41 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2004 09:29:04 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9F7ErSp010270; Fri, 15 Oct 2004 09:15:20 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 09:15:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: RO between MR and CN Date: Fri, 15 Oct 2004 09:15:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC307D69@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: RO between MR and CN Thread-Index: AcSx1cHh2NOj3oehSGS7VOJ+78792QAr7ZNw From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "Masafumi Watari" X-OriginalArrivalTime: 15 Oct 2004 07:15:12.0182 (UTC) FILETIME=[B5FCC560:01C4B286] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Carlos: I need to give you my review on MIRON. Note that your text is being unfair with RRH about the security issues. = Security is debated in the draft, if you care to read that part. There = have been a number of drafts that tried to propose more secure solutions = based on misunderstanding of what the threats might be. They all died. = Then there was Fan's very good study, (Fan, we need the update), but = still, most of the issues were moot. The point is that to date, there is no specific attack against RRH that = was identified to make any good sense, compared to, say, scramble the = radio wave or anything else a MITM might do. You understand that = propagating ideas like 'there are security issues' without being = specific is prejudicial... For instance, you might want to take a = specific attack and show how MIRON handles it better or something.=20 Pascal > -----Original Message----- > From: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Sent: jeudi 14 octobre 2004 12:08 > To: Masafumi Watari > Cc: Pascal Thubert (pthubert); nemo@ietf.org; Mar=EDa Calder=F3n > Subject: Re: [nemo] RE: RO between MR and CN >=20 > Hi Pascal, Masafumi, >=20 > El mi=E9, 13-10-2004 a las 19:08, Masafumi Watari escribi=F3: > > Hi, > > > > On Wed, 13 Oct 2004 13:34:06 +0200, > > "Pascal Thubert (pthubert)" wrote: > > > > > Hi Tania > > > > > > I was thinking things like of snooping. MR might intercept all = packets to LFN, recognize > a HoT and keep it. I remember discussing that with Alex long ago... = Anyway, we try to say > "don't take that path" as opposed to describe a solution in details. > > > > I don't think its possible to provide RO while keeping the RR = function > > of MIPv6 untouched. It would probably require modification of the > > packet at MR to use the HoA opt and the routing header for every > > packet, if we want to keep the MIPv6 spec as is. >=20 > Yes, one possible solution is the MR performing all the RR and RO > signalling on behalf of the LFNs of the NEMO, in order to provide RO = for > LFNs that are communicating to CNs outside the NEMO. This is actually > the solution we have proposed in MIRON (see my previous e-mail if you > want a pointer to it), so the MR, as you said, has to process the > packets sent/received by a LFN in order to insert HoA DO/remove RH. I > agree that it could have some performance concerns if the process is > performed to every LFN-CN "flow", but as we have already discussed in = a > previous thread, some mechanism should be used to perform the RO in a > reasonable way. >=20 > > > > > It seems preferable, for instance, to establish a MR-CR tunnel and = exchange fine grained > routes for MNPs over the tunnel (route projection). > > > > I think I agree on this. >=20 > This is, IMHO, a different approach, in which the RO requires some > support from the routing infrastructure, and that present some > advantages. But, OTOH, solutions based on MR-CN RO are also = interesting > IMHO, as an approach that does not require support in the routing > infrastructure and puts the RO support functionality only in the = edges, > i.e. the CN and the MR (if the transparency to the MNNs is required, = the > MR is the other edge in which RO mechanisms can be added). >=20 > What do you think? >=20 > Kind Regards, >=20 > Carlos J. > > > > Masafumi Watari > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: T=E2nia Pinto Cal=E7ada [mailto:tcalcada@inescporto.pt] > > > > Sent: mercredi 13 octobre 2004 13:16 > > > > To: nemo@ietf.org > > > > Cc: Pascal Thubert (pthubert) > > > > Subject: RO between MR and CN > > > > > > > > Hello, > > > > > > > > > > > > > > > > I am interested in route optimization between the MR and the CN. = I read the taxonomy > draft > > > > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other = documents related to RO: > > > > > > > > draft-jeong-nemo-ro-ndproxy-02.txt > > > > > > > > draft-leekj-nemo-ro-pd-02.txt > > > > > > > > draft-na-nemo-gen-ro-model-00.txt > > > > > > > > draft-na-nemo-path-control-header-00.txt > > > > > > > > draft-wakikawa-nemo-orc-00.txt > > > > > > > > ROProblem.txt > > > > > > > > > > > > > > > > I also read some threads of the NEMO mailing list = http://www1.ietf.org/mail- > > > > archive/web/nemo/current/index.html > > > archive/web/nemo/current/index.html> , however I am still = looking for a document that > > > > describes a solution for the RO between the MR and the CN. > > > > > > > > > > > > > > > > The taxonomy draft says at section 2: > > > > > > > > "A major issue with this form of optimization is that the = end-to-end > > > > > > > > principle of the MIPv6 Reverse Routability (RR) test is = broken. The > > > > > > > > RR test is meant to ensure the care-of address (CoA) and the = home > > > > > > > > address (HoA) are collocated. With a mobile network, when the = MR > > > > > > > > performs RO on behalf of the MNNs, the CoA in BU will be the = MR's > > > > > > > > CoA. Thus, a MNN is reachable via the CoA, but not at the = CoA. > > > > > > > > > > > > > > > > Some tricks may be performed on the fly by the MRs but it = seems that > > > > > > > > a clean MR-to-CN optimization for Nemo will impact the CN = function." > > > > > > > > > > > > > > > > Can somebody point the "tricks" that may be performed, or = indicate a document that > explores > > > > this subject? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Tania Calcada > > > > > > > > > > -- > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Fri Oct 15 11:00:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10968 for ; Fri, 15 Oct 2004 11:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITR1-0005sX-0n; Fri, 15 Oct 2004 10:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITJU-0003KL-4s for nemo@megatron.ietf.org; Fri, 15 Oct 2004 10:44:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08982 for ; Fri, 15 Oct 2004 10:44:09 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITUo-0000yP-Om for nemo@ietf.org; Fri, 15 Oct 2004 10:55:58 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7C1B85D135 for ; Fri, 15 Oct 2004 23:43:06 +0900 (JST) Date: Fri, 15 Oct 2004 23:40:51 +0900 (JST) Message-Id: <20041015.234051.48485883.watari@sfc.wide.ad.jp> To: nemo@ietf.org From: Masafumi Watari Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Oct_15_23_40_51_2004_694)--" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ----Next_Part(Fri_Oct_15_23_40_51_2004_694)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I've submitted a draft based on the presentation I made during the SD meeting. Please find the document in the URL below. http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt I hope that the draft helps the problem statement of Neste NEMO, and that the solution for RO considers the differenent cases metioned in the draft. Thanks, Masafumi Watari ----Next_Part(Fri_Oct_15_23_40_51_2004_694)-- Content-Type: Message/Rfc822 Content-Disposition: inline Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by style.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id i9EKoeMq047078 for ; Fri, 15 Oct 2004 05:50:41 +0900 (JST) Received: by shonan.sfc.wide.ad.jp (Postfix) id C18695D1E3; Fri, 15 Oct 2004 05:52:48 +0900 (JST) Delivered-To: watari@sfc.wide.ad.jp Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.143.33]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A90505D012; Fri, 15 Oct 2004 05:52:48 +0900 (JST) Received: from megatron.ietf.org (132.151.6.71) by ironport1.sfc.wide.ad.jp with ESMTP; 15 Oct 2004 05:52:37 +0900 X-BrightmailFiltered: true X-Ironport-AV: i="3.85,143,1094396400"; d="scan'208"; a="3013981:sNHT33560336" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICNA-0006az-56; Thu, 14 Oct 2004 16:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC4P-0008MI-Sh for i-d-announce@megatron.ietf.org; Thu, 14 Oct 2004 16:19:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25503 for ; Thu, 14 Oct 2004 16:19:27 -0400 (EDT) Message-Id: <200410142019.QAA25503@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 14 Oct 2004 16:19:27 -0400 Subject: I-D ACTION:draft-watari-nemo-nested-cn-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on style.sfc.wide.ad.jp X-Spam-Status: No, hits=-4.2 required=4.5 tests=BAYES_00, MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization with Nested Correspondent Nodes Author(s) : M. Watari, T. Ernst Filename : draft-watari-nemo-nested-cn-00.txt Pages : 18 Date : 2004-10-14 This document aims at assisting the problem statement of route optimization in nested mobile networks. We describe the paths packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms when one or both end nodes of a communication flow are located in a nested NEMO. One of both of the end nodes may themselves be either mobile nodes performing Mobile IPv6, or standard IPv6 nodes performing no mobility function at all. The path can become extremely suboptimal if no optimization is provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-watari-nemo-nested-cn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-watari-nemo-nested-cn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-14164528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-watari-nemo-nested-cn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-watari-nemo-nested-cn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-14164528.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- ----Next_Part(Fri_Oct_15_23_40_51_2004_694)---- From nemo-bounces@ietf.org Fri Oct 15 11:18:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12133 for ; Fri, 15 Oct 2004 11:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITkU-0001d5-W6; Fri, 15 Oct 2004 11:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIThn-00010Z-AT for nemo@megatron.ietf.org; Fri, 15 Oct 2004 11:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11513 for ; Fri, 15 Oct 2004 11:09:16 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITtB-0001bw-2j for nemo@ietf.org; Fri, 15 Oct 2004 11:21:05 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 087495D03A; Sat, 16 Oct 2004 00:08:47 +0900 (JST) Date: Sat, 16 Oct 2004 00:06:31 +0900 (JST) Message-Id: <20041016.000631.102532482.watari@sfc.wide.ad.jp> To: cjbc@it.uc3m.es Subject: Re: [nemo] NEMO RO Problem From: Masafumi Watari In-Reply-To: <1097145435.2464.74.camel@acorde> References: <200410040657.i946vZNX025909@tremex.ucdavis.edu> <1097145435.2464.74.camel@acorde> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Carlos, One quick question I had regarding your comment: On Thu, 07 Oct 2004 12:37:15 +0200, Carlos Jes=FAs Bernardos Cano wrote: > El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3: > > Dear all, > > = > > I wrote a document about NEMO RO problem, please click the = > > following link to see the details: > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > > = > > This document benefits from a lot of discussions and drafts. > > It is still a preliminary version, so there are still a lot = > > of questions. For example, Alex said that the charter does > > not requires dealing with multi-homing and NEMO RO. IMO, the > > requirement that RO solution should function for multi-homing NEMO = > > networks and should not conflict with multi-homing mechanism seems > > OK. We may also take a stepwise approach to solve multi-homing > > and RO issues. Thanks for your comments. > = > First, thanks for providing the document. As Alex, I can help you wi= th > the edition if you want to submit this input as I-D. > "MR may choose to perform RO function = > just with its HA if the number of different CNs is large and all CNs = > scatter around the Internet." > = > What do you mean with this sentence? I'm not sure, but performing RO > just with the HA sounds to me like not performing RO at all. Are you suggesting that bypassing of all HAs on the way as a requirement for the solution in RO? For example, RRH always uses the HA of the sub-MR, while bypassing the HA of the root-MR. Masafumi Watari From nemo-bounces@ietf.org Fri Oct 15 12:23:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17436 for ; Fri, 15 Oct 2004 12:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUpH-0000lW-VM; Fri, 15 Oct 2004 12:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUWb-0003sY-62 for nemo@megatron.ietf.org; Fri, 15 Oct 2004 12:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15986 for ; Fri, 15 Oct 2004 12:01:46 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUhz-000302-Dl for nemo@ietf.org; Fri, 15 Oct 2004 12:13:36 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0E17D2EFF4; Fri, 15 Oct 2004 18:01:15 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id B2C6B2EFED; Fri, 15 Oct 2004 18:01:14 +0200 (CEST) Subject: Re: [nemo] NEMO RO Problem From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <20041016.000631.102532482.watari@sfc.wide.ad.jp> References: <200410040657.i946vZNX025909@tremex.ucdavis.edu> <1097145435.2464.74.camel@acorde> <20041016.000631.102532482.watari@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uLx7CIID4ppjLDyis/My" Organization: Universidad Carlos III de Madrid Message-Id: <1097856109.2435.128.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Oct 2004 18:01:49 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-uLx7CIID4ppjLDyis/My Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Masafumi, Please, see my reply inline. El vie, 15-10-2004 a las 17:06, Masafumi Watari escribi=F3: > Hello Carlos, >=20 > One quick question I had regarding your comment: >=20 > On Thu, 07 Oct 2004 12:37:15 +0200, > Carlos Jes=FAs Bernardos Cano wrote: >=20 > > El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3: > > > Dear all, > > >=20 > > > I wrote a document about NEMO RO problem, please click the=20 > > > following link to see the details: > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > > >=20 > > > This document benefits from a lot of discussions and drafts. > > > It is still a preliminary version, so there are still a lot=20 > > > of questions. For example, Alex said that the charter does > > > not requires dealing with multi-homing and NEMO RO. IMO, the > > > requirement that RO solution should function for multi-homing NEMO=20 > > > networks and should not conflict with multi-homing mechanism seems > > > OK. We may also take a stepwise approach to solve multi-homing > > > and RO issues. Thanks for your comments. > >=20 > > First, thanks for providing the document. As Alex, I can help you with > > the edition if you want to submit this input as I-D. >=20 > >=20 > > "MR may choose to perform RO function=20 > > just with its HA if the number of different CNs is large and all CNs=20 > > scatter around the Internet." > >=20 > > What do you mean with this sentence? I'm not sure, but performing RO > > just with the HA sounds to me like not performing RO at all. >=20 > Are you suggesting that bypassing of all HAs on the way as a > requirement for the solution in RO? For example, RRH always uses the > HA of the sub-MR, while bypassing the HA of the root-MR. No, I'm not suggesting that. I made that comment thinking in a non-nested NEMO. It sounded to me that if MR decides to perform some RO function just with its HA, it is like not performing RO at all, because packets follow the same path than when NEMO Basic Support is used (i.e. CN<->HA<->MR<->MNN). Of course, in a nested NEMO scenario, if packets only traverse one HA instead of every MR's HA, these packets are experiencing some RO. BTW, IMHO the ideal solution would be bypassing all the HAs, but I don't know if such solution would be feasible or not while maintaining the transparency to the MNNs. Therefore, I wasn't suggesting that requirement. Kind regards, Carlos J. >=20 > Masafumi Watari --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-uLx7CIID4ppjLDyis/My Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBb/Rt5vKyPtrWqkARAhbiAKDgId4afij/3DxHwDVnTOgr3vJcNACeOLPy FTJdhUGETkqtuxM5zu2cWOs= =gJS7 -----END PGP SIGNATURE----- --=-uLx7CIID4ppjLDyis/My-- From nemo-bounces@ietf.org Mon Oct 18 02:59:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20241 for ; Mon, 18 Oct 2004 02:59:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRPJ-0000pf-J6; Mon, 18 Oct 2004 02:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRKt-0000Tk-MK for nemo@megatron.ietf.org; Mon, 18 Oct 2004 02:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19683 for ; Mon, 18 Oct 2004 02:49:38 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJRWq-0001AR-8z for nemo@ietf.org; Mon, 18 Oct 2004 03:02:00 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2004 00:06:21 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9I6n6k2006083 for ; Sun, 17 Oct 2004 23:49:06 -0700 (PDT) Received: from cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id ATF25116; Sun, 17 Oct 2004 23:49:05 -0700 (PDT) Message-ID: <41736760.9000809@cisco.com> Date: Sun, 17 Oct 2004 23:49:04 -0700 From: Sri Gundavelli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Management Information Base - draft-ietf-nemo-mib-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Attached is the link to the NEMO MIB document. This is a working doc. Please let us know your comments. ftp://ftp-eng.cisco.com/ftp/mobileip/sgundave/draft-ietf-nemo-mib-00.txt Abstract: This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. Authors: Sri Gundavelli Cisco Systems Glenn Mansfield Keeni Cyber Solutions Kenichi Nagami INTEC NetCore Kazuhide Koide Tohoku University Regards ! Sri From nemo-bounces@ietf.org Mon Oct 18 03:20:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22213 for ; Mon, 18 Oct 2004 03:20:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRmj-0003SJ-Fa; Mon, 18 Oct 2004 03:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJRlU-0003BG-TE for nemo@megatron.ietf.org; Mon, 18 Oct 2004 03:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21821 for ; Mon, 18 Oct 2004 03:17:07 -0400 (EDT) Received: from frankfurt.ucdavis.edu ([169.237.104.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJRxQ-0001fU-D7 for nemo@ietf.org; Mon, 18 Oct 2004 03:29:29 -0400 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by frankfurt.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9I7H28Q013372; Mon, 18 Oct 2004 00:17:02 -0700 (PDT) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9I7H2YZ001537; Mon, 18 Oct 2004 00:17:02 -0700 (PDT) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id i9I7H1pY001536; Mon, 18 Oct 2004 00:17:01 -0700 (PDT) Date: Mon, 18 Oct 2004 00:17:01 -0700 (PDT) Message-Id: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [nemo] NEMO RO problem draft submit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted a NEMO RO problem draft. In case that it has not been up in the I-D list, you can access it at: http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/draft-zhao-nemo-ro-ps-00.txt or http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/draft-zhao-nemo-ro-ps- 00.html. Your comments are greatly appreciated. Thanks. Sincerely, fan From nemo-bounces@ietf.org Mon Oct 18 05:49:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02318 for ; Mon, 18 Oct 2004 05:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJU26-0008A6-1Q; Mon, 18 Oct 2004 05:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJU14-000851-U9 for nemo@megatron.ietf.org; Mon, 18 Oct 2004 05:41:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02056 for ; Mon, 18 Oct 2004 05:41:20 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJUD1-0004S0-JE for nemo@ietf.org; Mon, 18 Oct 2004 05:53:44 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9I9gbG2026713; Mon, 18 Oct 2004 02:42:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i9I9e1Ik018996; Mon, 18 Oct 2004 04:40:02 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1FEEB88CF7E; Mon, 18 Oct 2004 11:41:15 +0200 (CEST) Message-ID: <41738FB6.40501@motorola.com> Date: Mon, 18 Oct 2004 11:41:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: [nemo] NEMO RO Problem References: <200410142209.i9EM9vV8002370@celerio.ucdavis.edu> In-Reply-To: <200410142209.i9EM9vV8002370@celerio.ucdavis.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4847B3E6D5A4D8070888EFB4" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4847B3E6D5A4D8070888EFB4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fan Zhao wrote: >> Fan Zhao wrote: >> >>> That is what I am exactly trying to do in this draft. I apologize >>> for using a confusing term, CR. Actually I should replace CR with >>> Correspondent Agent (CA). >> >> Just a note to say that CA is widely known as Certificate >> Authority. > > That is true, unfortunately. Is there any better term for it? That is an Edge Router, or a default router for CN, or an Access Router for CN, or an OSPF Border Router, or a Gateway. Alex --------------enig4847B3E6D5A4D8070888EFB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBc4+6MmC0w56zj54RAmpQAKD4AOoG1FHxu9BEuoC/nFKVaWEiYQCgpq5I vs9n/WT0G2RXzkV4kLgyuXU= =ZLW5 -----END PGP SIGNATURE----- --------------enig4847B3E6D5A4D8070888EFB4-- From nemo-bounces@ietf.org Mon Oct 18 08:32:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11456 for ; Mon, 18 Oct 2004 08:32:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWc5-00019k-Mj; Mon, 18 Oct 2004 08:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJQqw-000394-C4 for nemo@megatron.ietf.org; Mon, 18 Oct 2004 02:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17300 for ; Mon, 18 Oct 2004 02:18:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJR2q-0000ep-Rm for nemo@ietf.org; Mon, 18 Oct 2004 02:31:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2004 23:25:24 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9I6I2YJ022224; Sun, 17 Oct 2004 23:18:02 -0700 (PDT) Received: from cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id ATF23999; Sun, 17 Oct 2004 23:18:02 -0700 (PDT) Message-ID: <4173601A.8060200@cisco.com> Date: Sun, 17 Oct 2004 23:18:02 -0700 From: Sri Gundavelli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: multipart/mixed; boundary="------------000104070008060602050808" X-Spam-Score: 0.0 (/) X-Scan-Signature: 498b0a9a6d6f59a7e3c7bcb46cde6053 X-Mailman-Approved-At: Mon, 18 Oct 2004 08:27:44 -0400 Cc: Glenn Mansfield Keeni Subject: [nemo] NEMO Management Information Base - draft-ietf-nemo-mib-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --------------000104070008060602050808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please review the attached NEMO MIB draft. This is a working group document. Please send your comments on the draft to the mailing list. Abstract: This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. Authors: Sri Gundavelli Cisco Systems Glenn Mansfield Keeni Cyber Solutions Kenichi Nagami INTEC NetCore Kazuhide Koide Tohoku University Regards ! Sri Thierry Ernst wrote: > Dear all, > > I've sent a mail to internet-draft to approve it as a NEMO WG > document. --------------000104070008060602050808 Content-Type: text/plain; name="draft-ietf-nemo-mib-00.txt" Content-Disposition: inline; filename="draft-ietf-nemo-mib-00.txt" Content-Transfer-Encoding: 7bit NEMO Working Group Sri Gundavelli INTERNET-DRAFT Cisco Systems Expires: April 15, 2005 Glenn M. Keeni Cyber Solutions Kazuhide Koide Tohoku University Kenichi Nagami INTEC NetCore October 16, 2004 NEMO Management Information Base Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This document is a product of the mip6 Working Group. Comments should be addressed to the authors or the mailing list at mip6@ietf.org This Internet-Draft will expire on April 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Expires: April 15, 2005 [Page 1] Internet Draft October 16, 2004 Abstract This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. Table of Contents 1. The Internet-Standard Management Framework .................... 3 2. Overview ...................................................... 3 3. MIB Design .................................................... 4 4. The NEMO MIB .................................................. 5 5. Security Considerations .......................................29 6. IANA Considerations ...........................................29 7. Acknowledgments ...............................................29 8. References ....................................................30 9. Authors' Addresses ............................................32 10. Full Copyright Statement ......................................33 Expires: April 15, 2005 [Page 2] Internet Draft October 16, 2004 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview 2.1 The Mobile IPv6 Protocol and NEMO entities. Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Network Mobility Basic Support (NEMO) [NEMOBASIC] is an extension to the Mobile IPv6 protocol which facilitates the movement of an entire network. The goals of Network Mobility support and related terminology are discussed in [NEMOGOAL] and [NEMOTERM], respectively. Typically mobile routers implement NEMO functionality for achieving network mobility. However, a mobile router may also function as a mobile node. In the context of this document, an entity that implements the NEMO protocol is a NEMO entity. This document defines a set of managed objects (MOs) that can be used to monitor and control entities that support NEMO function. 2.2 Implementation Guidance This document focuses on the management of a NEMO entity. The MIPv6MIB [10] defines the managed objects for a mobile node. Implementations supporting both the mobile node and NEMO functionality SHOULD implement the managed objects defined for the NEMO entities and mobile nodes from both the MIPv6MIB and NEMOMIB. 2.3 Terminology. Expires: April 15, 2005 [Page 3] Internet Draft October 16, 2004 The terminology used in this document is consistent with the definitions used in the Mobile IPv6 protocol specification[RFC3775] and the NEMO Basic Support specification [NEMO]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. MIB Design The NEMO MIB comprises of the following primary groups: - nemoSystem - nemoConfiguration - nemoStats - nemoNotifications - nemoConformance The nemoSystem group provides the general information of the NEMO entity. The objects in this group cover the current home registration state. The nemoConfiguration group contains information relevant to the implementation and operation of the NEMO protocol. The nemoStats group defines the statistics related to the NEMO protocol operations. The nemoNotifications group defines the notifications generated by the NEMO entity in response to the operationally interesting state chanages in the NEMO protocol. The nemoConformance group identifies the managed objects that needs to be implemented for conforming to this draft. Expires: April 15, 2005 [Page 4] Internet Draft October 16, 2004 4. The NEMO MIB NEMO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Unsigned32, Counter32, Gauge32, Counter64, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, DateAndTime FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB InterfaceIndex FROM IF-MIB -- mip6Mn -- FROM MOBILEIPV6-MIB ; nemoMIB MODULE-IDENTITY LAST-UPDATED "200410070000Z" -- 7th October, 2004 ORGANIZATION "IETF NEMO Working Group" CONTACT-INFO " Sri Gundavelli Postal: Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Tel: +1-408-527-6109 Email: sgundave@cisco.com Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Expires: April 15, 2005 [Page 5] Internet Draft October 16, 2004 Kenichi Nagami Postal: INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Tel: +81-3-5665-5069 E-mail: nagami@inetcore.com Kazuhide Koide Postal: Tohoku University Katahira Campus Sendai Japan Tel: +81-22-217-5454 E-mail: koide@shiratori.riec.tohoku.ac.jp Support Group E-mail: nemo@ietf.org" DESCRIPTION "The MIB module for monitoring NEMO entity. Copyright (C) The Internet Society 2004. This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. " -- RFC Ed.: replace XXXX with actual RFC number & remove this note REVISION "200410160000Z" -- 16th October 2004 DESCRIPTION "Initial version, published as RFC XXXX." -- RFC Ed.: replace XXXX with actual RFC number & remove this note ::= { mib-2 XXX } -- will be assigned by IANA -- IANA Reg.: Please assign a value for "XXX" under the 'mip6Mn' -- subtree and record the assignment in the SMI Numbers registry. -- RFC Ed.: When the above assignment has been made, please -- remove the above note -- replace "XXX" here with the assigned value and -- remove this note. Expires: April 15, 2005 [Page 6] Internet Draft October 16, 2004 -- The NEMO MIB has the following 5 primary groups nemoNotifications OBJECT IDENTIFIER ::= { nemoMIB 0 } nemoSystem OBJECT IDENTIFIER ::= { nemoMIB 1 } nemoConfiguration OBJECT IDENTIFIER ::= { nemoMIB 2 } nemoStats OBJECT IDENTIFIER ::= { nemoMIB 3 } nemoConformance OBJECT IDENTIFIER ::= { nemoMIB 4 } -- The nemoConfiguration group has the following sub groups nemoRegistration OBJECT IDENTIFIER ::= { nemoConfiguration 1 } --nemoNetworksTable OBJECT IDENTIFIER ::= { nemoConfiguration 2 } --nemoRoamingIfTable OBJECT IDENTIFIER ::= { nemoConfiguration 3 } -- The nemoStats group has the following sub groups nemoHomeAgentDiscovery OBJECT IDENTIFIER ::= { nemoStats 1 } nemoTotalTraffic OBJECT IDENTIFIER ::= { nemoStats 2 } nemoBindingRegCounters OBJECT IDENTIFIER ::= { nemoStats 3 } nemoRoamingCounters OBJECT IDENTIFIER ::= { nemoStats 4 } -- Textual Conventions NemoStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object represents the state of the NEMO entity. The entity could be at home, isolated, roaming or in unknown state. " SYNTAX INTEGER { isolated (1), roaming (2), home (3), unknown (4) } -- -- -- nemoSystem group -- -- Expires: April 15, 2005 [Page 7] Internet Draft October 16, 2004 nemoRoamingStatus OBJECT-TYPE SYNTAX NemoStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current status of the NEMO entity. The status indicates if the NEMO entity is at home, roaming isolated or in unknown state. " ::= { nemoSystem 1 } nemoRegisteredUpTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in seconds) for which the NEMO entity up and registered with its home agent. " ::= { nemoSystem 2 } nemoLastAcceptedRegTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when the last registration was accepted with its home agent. " ::= { nemoSystem 3 } nemoLastRejectedRegTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when the last registration was rejected with its home agent. " ::= { nemoSystem 4 } nemoRegHomeAgentAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION Expires: April 15, 2005 [Page 8] Internet Draft October 16, 2004 "The address type of the nemoRegHomeAgentAddress that follows. " ::= { nemoSystem 5 } nemoRegHomeAgentAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The home address of the mobile router which is used in the last accepted registration. " ::= { nemoSystem 6 } nemoRegHomeNetworkAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the nemoRegHomeNetworkAddress that follows. " ::= { nemoSystem 7 } nemoRegHomeNetworkAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The prefix of the home network for which the mobile router is registered at last. " ::= { nemoSystem 8 } nemoRegHomeNetworkPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The prefix length of the home network for which the mobile router is registered at last. " ::= { nemoSystem 9 } nemoRegCareofAddressType OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only Expires: April 15, 2005 [Page 9] Internet Draft October 16, 2004 STATUS current DESCRIPTION "The care-of address of the mobile router which is used in the last accepted registration. " ::= { nemoSystem 10 } nemoRegCareofAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The care-of address of the mobile router which is used in the last accepted registration. " ::= { nemoSystem 11 } nemoActiveRoamingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of the current active roaming interface. " ::= { nemoSystem 12 } nemoEstablishedHomeTunnelIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of the tunnel interface in the mobile router which is established between the mobile router and the home agent for NEMO traffic. " ::= { nemoSystem 13 } -- -- -- nemoConfiguration group -- -- -- -- nemoRegistration sub group Expires: April 15, 2005 [Page 10] Internet Draft October 16, 2004 -- nemoHomeRegLifeTime OBJECT-TYPE SYNTAX Gauge32 (4..262143) MAX-ACCESS read-write STATUS current DESCRIPTION "The lifetime requested by the mobile router (in seconds) in the Binding registration. It is between 4 and 262143 secs. " ::= { nemoRegistration 1 } nemoHomeRegRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of registration attempts allowed for the mobile router. " ::= { nemoRegistration 2 } nemoHomeRegRetryDelay OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The delay time between successive registration attempts by the mobile router(in seconds). " ::= { nemoRegistration 3 } nemoHomeRegExtendBeforeExpiry OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The time before the registration extension is attempted (in seconds) by the mobile router. " ::= { nemoRegistration 4 } nemoDynamicHAAddressDiscovery OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION Expires: April 15, 2005 [Page 11] Internet Draft October 16, 2004 "This object indicates whether or not the mobile router should attempt to make dynamic home agent address discovery(DHAAD). " ::= { nemoRegistration 5 } nemoHomeNetworkPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The InetAddressType of the nemoHomeNetworkPrefix that follows. " ::= { nemoRegistration 6 } nemoHomeNetworkPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The prefix of the home network which is configured for the mobile router. " ::= { nemoRegistration 7 } nemoHomeNetworkPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "The length of the home network prefix which is configured for the mobile router. " ::= { nemoRegistration 8 } nemoHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The InetAddressType of the nemoHomeAddress that follows. " ::= { nemoRegistration 9 } nemoHomeAddress OBJECT-TYPE SYNTAX InetAddress Expires: April 15, 2005 [Page 12] Internet Draft October 16, 2004 MAX-ACCESS read-write STATUS current DESCRIPTION "The unicast routable address assigned to the mobile router. This is used as the 'permanent address' of the mobile router in the sense that it remains unchanged regardless of the mobile router's current point ofattachment. The type of the address represented by this object is specified by the corresponding nemoHomeAddressType object. " ::= { nemoRegistration 10 } nemoPrefixRegMode OBJECT-TYPE SYNTAX BITS { implicitMode (0), explicitMode (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Two modes to instruct the Home Agent to determine the prefixes that belong to the mobile router. " ::= { nemoRegistration 11 } nemoRegisterConnectedPrefixes OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the mobile router will register all connected prefixes or not. " ::= { nemoRegistration 12 } -- -- nemoPrefixTable -- nemoPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table representing the NEMO prefixes. " Expires: April 15, 2005 [Page 13] Internet Draft October 16, 2004 ::= { nemoConfiguration 2 } nemoPrefixEntry OBJECT-TYPE SYNTAX NemoPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the binding cache table. It represents a single Binding Update. " INDEX { nemoPrefixType, nemoPrefix, nemoPrefixLength } ::= { nemoPrefixTable 1 } NemoPrefixEntry ::= SEQUENCE { nemoPrefixType InetAddressType, nemoPrefix InetAddress, nemoPrefixLength InetAddressPrefixLength, nemoPrefixLifeTime Gauge32 } nemoPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the nemoPrefix that follows. " ::= { nemoPrefixEntry 1 } nemoPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mobile network prefix that is delegated to the mobile router and advertised in the mobile network. The type of the address represented by this object is specified by the corresponding nemoPrefixType object. " ::= { nemoPrefixEntry 2 } Expires: April 15, 2005 [Page 14] Internet Draft October 16, 2004 nemoPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The prefix length of the mobile network prefix. " ::= { nemoPrefixEntry 3 } nemoPrefixLifeTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime (in seconds) granted to the mobile router for this registration. " ::= { nemoPrefixEntry 4 } -- -- nemoRoamingIfTable -- nemoRoamingIfTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoRoamingIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table representing the roaming interfaces. Each entry represents a configured roaming interface with the roaming characterstics. " ::= { nemoConfiguration 3 } nemoRoamingIfEntry OBJECT-TYPE SYNTAX NemoRoamingIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the roaming interface table. It represents a single roaming interface entry. " INDEX { nemoRoamingIfIndex, nemoRoamingIfPriority } ::= { nemoRoamingIfTable 1 } Expires: April 15, 2005 [Page 15] Internet Draft October 16, 2004 NemoRoamingIfEntry ::= SEQUENCE { nemoRoamingIfIndex InterfaceIndex, nemoRoamingIfDescription SnmpAdminString, nemoRoamingIfPriority Unsigned32, nemoRoamingIfRoamHoldDownTime Gauge32 } nemoRoamingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the interface that will be used for roaming to foreign networks in the mobile router. " ::= { nemoRoamingIfEntry 1 } nemoRoamingIfPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority configured to the interface. This value will be configured between 0 and 255. " ::= { nemoRoamingIfEntry 2 } nemoRoamingIfDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The description of the interface that will be used for roaming to foreign networks in the mobile router. " ::= { nemoRoamingIfEntry 3 } nemoRoamingIfRoamHoldDownTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the time for which hold on to the interface. This value is configured to avoid interface flapping. Expires: April 15, 2005 [Page 16] Internet Draft October 16, 2004 " ::= { nemoRoamingIfEntry 4 } --- --- --- nemoStats group --- --- -- -- Dynamic Home Agent discovery protocol related counters -- nemoDHAADRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of dynamic home agent address discovery requests sent by the mobile router. " ::= { nemoHomeAgentDiscovery 1 } nemoDHAADRepliesWNemoSupport OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of dynamic home agent address discovery replies sent by the home agent with NEMO support. " ::= { nemoHomeAgentDiscovery 2 } nemoDHAADRepliesWONemoSupport OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of dynamic home agent address discovery replies sent by the home agent without NEMO support. " ::= { nemoHomeAgentDiscovery 3 } Expires: April 15, 2005 [Page 17] Internet Draft October 16, 2004 nemoDHAADDiscoveryTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of dynamic home agent address discovery requested by the mobile router and that was timeout. " ::= { nemoHomeAgentDiscovery 4 } -- -- nemoStats:nemoTotalTraffic -- nemoInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams received by the nodes in the NEMO networks. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 1 } nemoHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams received by the NEMO networks. This object is a 64-bit version of nemoInOctets. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 2 } nemoInPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams Expires: April 15, 2005 [Page 18] Internet Draft October 16, 2004 received by the nodes in the NEMO networks. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 3 } nemoHCInPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IPv6 packets received by the nodes in the NEMO networks. This object is a 64-bit version of nemoInOctets. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 4 } nemoOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams sent by the nodes in the NEMO networks. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 5 } nemoHCOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams sent by the NEMO networks. This object is a 64-bit version of nemoInOctets. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 6 } Expires: April 15, 2005 [Page 19] Internet Draft October 16, 2004 nemoOutPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the IPv6 datagrams sent by the nodes in the NEMO networks. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 7 } nemoHCOutPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IPv6 packets sent by the nodes in the NEMO networks. This object is a 64-bit version of nemoInOctets. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoTotalTraffic 8 } -- -- nemoStats:nemoBindingRegcounters -- nemoBindingUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Updates sent by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 1 } nemoBindingAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Expires: April 15, 2005 [Page 20] Internet Draft October 16, 2004 DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 2 } nemoBindingAcksWONemoSupport OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acks without the NEMO support received by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 3 } nemoBindingAckNotHomeRegn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with the status code in the Binding Acknowledgment indicating 'Not Home Registration' Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 4 } nemoBindingRegTypeChanged OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 5 } Expires: April 15, 2005 [Page 21] Internet Draft October 16, 2004 nemoOpNotSupported OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Mobile Router Operation not permitted' (Code 140). Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 6 } nemoInvalidPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Invalid Prefix' (Code 141). Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 7 } nemoNotAuthorizedForPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Not Authorized for Prefix' (Code 142). Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 8 } nemoForwardingSetupFailed OBJECT-TYPE SYNTAX Counter32 Expires: April 15, 2005 [Page 22] Internet Draft October 16, 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Forwarding Setup failed' (Code 143). Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoBindingRegCounters 9 } -- -- nemoStats:nemoRoamingCounters -- nemoMovedHome OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement from a foreign network to its home network. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoRoamingCounters 1 } nemoMovedOutofHome OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement from to a foreign network from the home network, has reconstructed its care-of address and has initiated the care-of address registration process. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoRoamingCounters 2 } nemoMovedFNtoFN OBJECT-TYPE Expires: April 15, 2005 [Page 23] Internet Draft October 16, 2004 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement from to a foreign network from the home network, has reconstructed its care-of address and has initiated the care-of address registration process. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoRoamingCounters 3 } nemoBetterIfDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the NEMO entity has found roaming interface with better priority. Discontinuities in the value of this counter can occur at re-initialization of the mobile router. " ::= { nemoRoamingCounters 4 } -- -- -- nemoNotifications -- -- nemoHomeTunnelEstablished NOTIFICATION-TYPE OBJECTS { nemoActiveRoamingIfIndex, nemoEstablishedHomeTunnelIfIndex, nemoRegCareofAddressType, nemoRegCareofAddress } STATUS current DESCRIPTION "This notification is sent by the HA every time the NEMO entity establishes a MR-HA tunnel. " ::= { nemoNotifications 1 } nemoHomeTunnelReleased NOTIFICATION-TYPE Expires: April 15, 2005 [Page 24] Internet Draft October 16, 2004 OBJECTS { nemoActiveRoamingIfIndex, nemoEstablishedHomeTunnelIfIndex, nemoRegCareofAddressType, nemoRegCareofAddress } STATUS current DESCRIPTION "This notification is sent by the HA every time the NEMO entity releases a MR-HA tunnel. " ::= { nemoNotifications 2} Expires: April 15, 2005 [Page 25] Internet Draft October 16, 2004 -- Conformance information nemoGroups OBJECT IDENTIFIER ::= { nemoConformance 1 } nemoCompliances OBJECT IDENTIFIER ::= { nemoConformance 2 } -- Units of conformance nemoSystemGroup OBJECT-GROUP OBJECTS { nemoRoamingStatus, nemoRegisteredUpTime, nemoLastAcceptedRegTime, nemoLastRejectedRegTime, nemoRegHomeAgentAddressType, nemoRegHomeAgentAddress, nemoRegHomeNetworkAddressType, nemoRegHomeNetworkAddress, nemoRegHomeNetworkPrefixLength, nemoRegCareofAddressType, nemoRegCareofAddress, nemoActiveRoamingIfIndex, nemoEstablishedHomeTunnelIfIndex } STATUS current DESCRIPTION " A collection of objects for basic NEMO monitoring." ::= { nemoGroups 1 } nemoConfigurationGroup OBJECT-GROUP OBJECTS { nemoHomeRegLifeTime, nemoHomeRegRetryCount, nemoHomeRegRetryDelay, nemoHomeRegExtendBeforeExpiry, nemoDynamicHAAddressDiscovery, nemoHomeNetworkPrefixType, nemoHomeNetworkPrefix, nemoHomeNetworkPrefixLength, nemoHomeAddressType, nemoHomeAddress, nemoPrefixRegMode, nemoRegisterConnectedPrefixes, -- nemoPrefixType, -- nemoPrefix, -- nemoPrefixLength, nemoPrefixLifeTime, -- nemoRoamingIfIndex, -- nemoRoamingIfPriority, nemoRoamingIfDescription, Expires: April 15, 2005 [Page 26] Internet Draft October 16, 2004 nemoRoamingIfRoamHoldDownTime, nemoDHAADRequests, nemoDHAADRepliesWNemoSupport, nemoDHAADRepliesWONemoSupport, nemoDHAADDiscoveryTimeouts } STATUS current DESCRIPTION " A collection of objects for basic NEMO configuration monitoring." ::= { nemoGroups 2 } nemoStatsGroup OBJECT-GROUP OBJECTS { nemoInOctets, nemoHCInOctets, nemoInPackets, nemoHCInPackets, nemoOutOctets, nemoHCOutOctets, nemoOutPackets, nemoHCOutPackets, nemoBindingUpdates, nemoBindingAcks, nemoBindingAcksWONemoSupport, nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged, nemoOpNotSupported, nemoInvalidPrefix, nemoNotAuthorizedForPrefix, nemoForwardingSetupFailed, nemoMovedHome, nemoMovedOutofHome, nemoMovedFNtoFN, nemoBetterIfDetected } STATUS current DESCRIPTION " A collection of objects for basic NEMO monitoring. " ::= { nemoGroups 3 } nemoNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { nemoHomeTunnelEstablished, nemoHomeTunnelReleased } Expires: April 15, 2005 [Page 27] Internet Draft October 16, 2004 STATUS current DESCRIPTION "A collection of notifications from a home agent or correspondent node to the Manager about the tunnel status of the mobile router. " ::= { nemoGroups 4 } -- Compliance statements nemoCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILEIPV6-MIB. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT nemoBindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the nemoBindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoSystemGroup, nemoConfigurationGroup, nemoStatsGroup, nemoNotificationGroup } ::= { nemoCompliances 1 } END Expires: April 15, 2005 [Page 28] Internet Draft October 16, 2004 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations IANA should assign a base arc in the mip6Mn group of the 'mipv6MIB' (standards track) OID tree for the 'nemoMIB' MODULE-IDENTITY defined in the NEMO MIB. 7. Acknowledgments The authors would like to thank T.J Kniveton and Thierry Ernst for Expires: April 15, 2005 [Page 29] Internet Draft October 16, 2004 their inputs to the document and also would like to thank Kent Leung and Pascal Thubert for their insight into Mobile Router v4 and v6 implementations. Expires: April 15, 2005 [Page 30] Internet Draft October 16, 2004 8. References 8.1 Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirements Levels, BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Structure of Management Information Version 2 (SMIv2), STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Textual Conventions for SMIv2, STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Conformance Statements for SMIv2, STD 58, RFC 2580, April 1999. [RFC3775] Johnson, D., Perkins, C. and Arkko J., Mobility Support in IPv6q RFC 3775, June 2004. [RFC2011bis] Routhier, S., Management Information Base for the Internet Protocol (IP), work in progress (currently ). [RFC3291bis] Daniele, M., Haberman, B., Routhier, S. and Schoenwaelder, J., Textual Conventions for Internet Network Addresses, work in progress (currently ). [NEMOBASIC] Thubert, P., Petrescu, A., Wakikawa, R. and V. Devarapalli, Network Mobility (NEMO) Basic Support Protocol, work in progress (currently . [MIPv6MIB] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, The Mobile IPv6 MIB, work in progress (currently ). 8.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, Introduction and Applicability Statements for Internet-Standard Management Framework, RFC 3410, December 2002. Expires: April 15, 2005 [Page 31] Internet Draft October 16, 2004 [NEMOTERM] T. Ernst and H.-Y. Lach., Network Mobility Support Terminology, work in progress (currently ). [NEMOGOAL] T. Ernst. Network Mobility Support Goals and Requirements, work in progress (currently ). Expires: April 15, 2005 [Page 32] Internet Draft October 16, 2004 9. Authors' Addresses Sri Gundavelli Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Phone: +1-408-527-6109 Email: sgundave@cisco.com Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Phone: +81-3-5665-5069 E-mail: nagami@inetcore.com Kazuhide Koide Tohoku University Katahira Campus Sendai Japan Phone: +81-22-217-5454 E-mail: koide@shiratori.riec.tohoku.ac.jp Expires: April 15, 2005 [Page 33] Internet Draft October 16, 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: April 15, 2005 [Page 34] Internet Draft October 16, 2004 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires: April 15, 2005 [Page 35] Internet Draft October 16, 2004 Expires: April 15, 2005 [Page 36] --------------000104070008060602050808-- From nemo-bounces@ietf.org Mon Oct 18 08:52:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12644 for ; Mon, 18 Oct 2004 08:52:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWrS-0002ma-I1; Mon, 18 Oct 2004 08:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWkK-0002Dg-US for nemo@megatron.ietf.org; Mon, 18 Oct 2004 08:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11630 for ; Mon, 18 Oct 2004 08:36:15 -0400 (EDT) Received: from [203.252.134.6] (helo=cclab.konkuk.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWw4-0007Vl-LL for nemo@ietf.org; Mon, 18 Oct 2004 08:48:40 -0400 Received: from nbclearsky (linus.konkuk.ac.kr [203.252.134.164]) by cclab.konkuk.ac.kr (8.12.8/8.12.8) with ESMTP id i9ICZOiK000905; Mon, 18 Oct 2004 21:35:24 +0900 Message-ID: <001e01c4b50e$f230cab0$a486fccb@nbclearsky> From: =?ks_c_5601-1987?B?udqx4r/rX7DHsbm06w==?= To: "Fan Zhao" References: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> Subject: Re: [nemo] NEMO RO problem draft submit Date: Mon, 18 Oct 2004 21:35:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.181 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: base64 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYWxyZWFkeSByZWFkIGEgZHJhZnQgYWJvdXQgdGhlIHNvbHV0aW9uIG9m IE5FTU8gUk8gcHJvYmxlbSB1c2luZyBQcmVmaXggRGVsZWdhdGlvbiBNZWNoYW5pc20gaW4gSVB2 Ng0KWW91IGNhbiBhY2Nlc3MgaXQgYXQgOg0KaHR0cDovL3d3dy11c2Vycy5jcy51bW4uZWR1L35q amVvbmcvcHVibGljYXRpb25zL2lldGYtaW50ZXJuZXQtZHJhZnQvZHJhZnQtbGVla2otbmVtby1y by1wZC0wMS50eHQNCg0KSSB0aGluayBpdCBpcyBhYm9sdXRlbHkgY29ycmVjdCBzb2x1dGlvbiBv ZiBORU1PIFJPIHByb2JsZW0uDQpBbnkgb3RoZXIgb3BpbmlvbiwgaXQgd2lsbCBiZSBncmVhdCB0 byBtZS4NCg0KQmVzdCByZWdhcmQNCktpeW9uZyBQYXJrLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIkZhbiBaaGFvIiA8ZmFuemhhb0B1Y2RhdmlzLmVkdT4NClRvOiA8 bmVtb0BpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOCwgMjAwNCA0OjE3IFBNDQpT dWJqZWN0OiBbbmVtb10gTkVNTyBSTyBwcm9ibGVtIGRyYWZ0IHN1Ym1pdA0KDQoNCj4gDQo+IERl YXIgYWxsLA0KPiANCj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBORU1PIFJPIHByb2JsZW0gZHJhZnQu DQo+IEluIGNhc2UgdGhhdCBpdCBoYXMgbm90IGJlZW4gdXAgaW4gdGhlIEktRCBsaXN0LA0KPiB5 b3UgY2FuIGFjY2VzcyBpdCBhdDoNCj4gaHR0cDovL3d3d2NzaWYuY3MudWNkYXZpcy5lZHUvfnpo YW9mYS9ORU1PUk8vZHJhZnQtemhhby1uZW1vLXJvLXBzLTAwLnR4dA0KPiBvciBodHRwOi8vd3d3 Y3NpZi5jcy51Y2RhdmlzLmVkdS9+emhhb2ZhL05FTU9STy9kcmFmdC16aGFvLW5lbW8tcm8tcHMt DQo+IDAwLmh0bWwuDQo+IFlvdXIgY29tbWVudHMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIFRo YW5rcy4NCj4gDQo+IFNpbmNlcmVseSwNCj4gZmFu From nemo-bounces@ietf.org Mon Oct 18 13:35:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04885 for ; Mon, 18 Oct 2004 13:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb0j-0000na-FI; Mon, 18 Oct 2004 13:09:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJabi-0005tl-Vk for nemo@megatron.ietf.org; Mon, 18 Oct 2004 12:43:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26371 for ; Mon, 18 Oct 2004 11:44:27 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJZsT-0002wm-SR for nemo@ietf.org; Mon, 18 Oct 2004 11:56:55 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i9IFiAMO023237; Mon, 18 Oct 2004 08:44:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i9IFhp6I022475; Mon, 18 Oct 2004 10:43:52 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C243388CF7E; Mon, 18 Oct 2004 17:44:07 +0200 (CEST) Message-ID: <4173E4C2.2090609@motorola.com> Date: Mon, 18 Oct 2004 17:44:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?EUC-KR?B?udqx4r/rX7DHsbm06w==?= Subject: Re: [nemo] NEMO RO problem draft submit References: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> <001e01c4b50e$f230cab0$a486fccb@nbclearsky> In-Reply-To: <001e01c4b50e$f230cab0$a486fccb@nbclearsky> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADB408C39E59F79F4FB3DA5F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADB408C39E59F79F4FB3DA5F Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit ¹Ú±â¿ë_°Ç±¹´ë wrote: > I already read a draft about the solution of NEMO RO problem using > Prefix Delegation Mechanism in IPv6 You can access it at : > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-leekj-nemo-ro-pd-01.txt > > I think it is abolutely correct solution of NEMO RO problem. Any > other opinion, it will be great to me. Hello Kiyong Park. IMHO it is debatable whether that PD with Neighbour Discovery solution is a correct solution for the NEMO RO problem since we don't know exactly what the RO problem is. If the RO problem is that MN-behind-MR communication to CN goes through HA (instead of directly) then yes, that PD solution is solving it. If on the other hand the problem is that LFN-behind-MR communication to CN goes through HA (instead of directly) then no, that PD solution is not solving it, because that draft does not describe how MR performs RO on behalf of LFN (LFN does not do Mobile IPv6). In my understanding. Alex --------------enigADB408C39E59F79F4FB3DA5F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBc+THMmC0w56zj54RAuKSAJ9TgczQHKmz7ue/sMCrgNF2ZKIUKACg5PVb cndRJ3wfUY5lh4phDxS5C+Y= =s7GY -----END PGP SIGNATURE----- --------------enigADB408C39E59F79F4FB3DA5F-- From nemo-bounces@ietf.org Mon Oct 18 14:06:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07657 for ; Mon, 18 Oct 2004 14:06:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbaX-0005vC-2H; Mon, 18 Oct 2004 13:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbD6-0002eJ-SV for nemo@megatron.ietf.org; Mon, 18 Oct 2004 13:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03703 for ; Mon, 18 Oct 2004 13:22:08 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbP3-0004wd-48 for nemo@ietf.org; Mon, 18 Oct 2004 13:34:38 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 420242F305; Mon, 18 Oct 2004 19:21:38 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id A661D2F382; Mon, 18 Oct 2004 19:21:32 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC307D69@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC307D69@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2A7F6B38-212A-11D9-AF09-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] RE: RO between MR and CN Date: Mon, 18 Oct 2004 19:21:36 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Masafumi Watari , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Pascal, sorry for the delay, but as you may notice, the 18th has arrived :-) As a co-author of the paper, let me give you p.o.v. of this issue. El 15/10/2004, a las 9:15, Pascal Thubert (pthubert) escribi=F3: > Hi Carlos: > > I need to give you my review on MIRON. > > Note that your text is being unfair with RRH about the security=20 > issues. Security is debated in the draft, if you care to read that=20 > part. The content of the paper is the result of the analysis of the different=20= proposals. Yes, we have read the RRH draft and its security=20 considerations section. In particular, we have read the part that=20 states: "This section is not complete; further work is needed to analyze and solve the security problems of record and source route." Pay particular attention to the "solve" part. This seems perfectly coherent with the comment presented in the paper=20 stating that: "It has been identified that this approach [RRH] has security=20 concerns." Note that we only say concerns while in the draft it is stated=20 "problems" > There have been a number of drafts that tried to propose more secure=20= > solutions based on misunderstanding of what the threats might be. They=20= > all died. Then there was Fan's very good study, (Fan, we need the=20 > update), but still, most of the issues were moot. > > The point is that to date, there is no specific attack against RRH=20 > that was identified to make any good sense, compared to, say, scramble=20= > the radio wave or anything else a MITM might do. You understand that=20= > propagating ideas like 'there are security issues' without being=20 > specific is prejudicial... IMHO the paper propagates less this kind of ideas that the draft=20 itself. As i mentioned, it is the draft that states that the RRH has=20 "security problems" that need to be solved. I guess that if you do not want to propagate this type of ideas, i=20 would suggest you to remove this type of statements from the draft. > For instance, you might want to take a specific attack and show how=20= > MIRON handles it better or something. > As you may notice, the MIRON paper is not about RRH security but about=20= the MIRON proposal (moreover is not even about MIRON security), and=20 considering the length restrictions on a paper, i guess that it isn't=20 possible to include examples about all the statements provided. Regards, marcelo PS: I would like to apologize to the list about this mail, since it is=20= clearly out of scope for the list. I won't sent any other mails about=20 this specific issue. OTOH, i will be sending a constructive mail=20 containing some security analysis about RRH, hoping to contribute with=20= that effort > Pascal > >> -----Original Message----- >> From: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] >> Sent: jeudi 14 octobre 2004 12:08 >> To: Masafumi Watari >> Cc: Pascal Thubert (pthubert); nemo@ietf.org; Mar=EDa Calder=F3n >> Subject: Re: [nemo] RE: RO between MR and CN >> >> Hi Pascal, Masafumi, >> >> El mi=E9, 13-10-2004 a las 19:08, Masafumi Watari escribi=F3: >>> Hi, >>> >>> On Wed, 13 Oct 2004 13:34:06 +0200, >>> "Pascal Thubert (pthubert)" wrote: >>> >>>> Hi Tania >>>> >>>> I was thinking things like of snooping. MR might intercept all=20 >>>> packets to LFN, recognize >> a HoT and keep it. I remember discussing that with Alex long ago...=20= >> Anyway, we try to say >> "don't take that path" as opposed to describe a solution in details. >>> >>> I don't think its possible to provide RO while keeping the RR=20 >>> function >>> of MIPv6 untouched. It would probably require modification of the >>> packet at MR to use the HoA opt and the routing header for every >>> packet, if we want to keep the MIPv6 spec as is. >> >> Yes, one possible solution is the MR performing all the RR and = RO >> signalling on behalf of the LFNs of the NEMO, in order to provide RO=20= >> for >> LFNs that are communicating to CNs outside the NEMO. This is actually >> the solution we have proposed in MIRON (see my previous e-mail if you >> want a pointer to it), so the MR, as you said, has to process the >> packets sent/received by a LFN in order to insert HoA DO/remove RH. I >> agree that it could have some performance concerns if the process is >> performed to every LFN-CN "flow", but as we have already discussed in=20= >> a >> previous thread, some mechanism should be used to perform the RO in a >> reasonable way. >> >>> >>>> It seems preferable, for instance, to establish a MR-CR tunnel and=20= >>>> exchange fine grained >> routes for MNPs over the tunnel (route projection). >>> >>> I think I agree on this. >> >> This is, IMHO, a different approach, in which the RO requires = some >> support from the routing infrastructure, and that present some >> advantages. But, OTOH, solutions based on MR-CN RO are also=20 >> interesting >> IMHO, as an approach that does not require support in the routing >> infrastructure and puts the RO support functionality only in the=20 >> edges, >> i.e. the CN and the MR (if the transparency to the MNNs is required,=20= >> the >> MR is the other edge in which RO mechanisms can be added). >> >> What do you think? >> >> Kind Regards, >> >> Carlos J. >>> >>> Masafumi Watari >>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: T=E2nia Pinto Cal=E7ada [mailto:tcalcada@inescporto.pt] >>>>> Sent: mercredi 13 octobre 2004 13:16 >>>>> To: nemo@ietf.org >>>>> Cc: Pascal Thubert (pthubert) >>>>> Subject: RO between MR and CN >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I am interested in route optimization between the MR and the CN. I=20= >>>>> read the taxonomy >> draft >>>>> (draft-thubert-nemo-ro-taxonomy-02.txt), and several other=20 >>>>> documents related to RO: >>>>> >>>>> draft-jeong-nemo-ro-ndproxy-02.txt >>>>> >>>>> draft-leekj-nemo-ro-pd-02.txt >>>>> >>>>> draft-na-nemo-gen-ro-model-00.txt >>>>> >>>>> draft-na-nemo-path-control-header-00.txt >>>>> >>>>> draft-wakikawa-nemo-orc-00.txt >>>>> >>>>> ROProblem.txt >>>>> >>>>> >>>>> >>>>> I also read some threads of the NEMO mailing list=20 >>>>> http://www1.ietf.org/mail- >>>>> archive/web/nemo/current/index.html >>>> archive/web/nemo/current/index.html> , however I am still looking=20= >>>>> for a document that >>>>> describes a solution for the RO between the MR and the CN. >>>>> >>>>> >>>>> >>>>> The taxonomy draft says at section 2: >>>>> >>>>> "A major issue with this form of optimization is that the=20 >>>>> end-to-end >>>>> >>>>> principle of the MIPv6 Reverse Routability (RR) test is broken.=20= >>>>> The >>>>> >>>>> RR test is meant to ensure the care-of address (CoA) and the=20 >>>>> home >>>>> >>>>> address (HoA) are collocated. With a mobile network, when the = MR >>>>> >>>>> performs RO on behalf of the MNNs, the CoA in BU will be the=20 >>>>> MR's >>>>> >>>>> CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. >>>>> >>>>> >>>>> >>>>> Some tricks may be performed on the fly by the MRs but it seems=20= >>>>> that >>>>> >>>>> a clean MR-to-CN optimization for Nemo will impact the CN=20 >>>>> function." >>>>> >>>>> >>>>> >>>>> Can somebody point the "tricks" that may be performed, or indicate=20= >>>>> a document that >> explores >>>>> this subject? >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Tania Calcada >>>> >>>> >>>> >> -- >> Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ >> GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Mon Oct 18 14:42:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11167 for ; Mon, 18 Oct 2004 14:42:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbzI-0001Xz-Jm; Mon, 18 Oct 2004 14:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbgo-0007C0-Ak for nemo@megatron.ietf.org; Mon, 18 Oct 2004 13:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06394 for ; Mon, 18 Oct 2004 13:52:52 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbsl-0005eS-5K for nemo@ietf.org; Mon, 18 Oct 2004 14:05:19 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 3309F2F3EC; Mon, 18 Oct 2004 19:52:21 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 8ED482F3EA; Mon, 18 Oct 2004 19:52:20 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC307D69@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC307D69@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <780D39BC-212E-11D9-AF09-000D93ACD0FE@it> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: About RRH security (was Re: [nemo] RE: RO between MR and CN Date: Mon, 18 Oct 2004 19:52:25 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: nemo WG , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi all, This is part of the security analysis that we have performed about the RRH. I guess that we could summarize it as follows: - The RRH security issues that we identified are more related to lack of specification rather than fundamental ones. Meaning that IMHO, the current draft doesn't take into account some issues, in particular time-shifted attacks, when performing the RRH. - The identified issues can be solved through proper host behaviour. The main security problem of RRH imho is related with the fact that the signaling channel between the MR and the HA is protected through a IPSec SA that may be manually configured, for instance. This means that the resulting level of trust may be relatively high. However, the information contained in the RRH, is not protected with this SA, and its protection relies on that the presence of the attacker along the path, so the information obtained through RRH has a different level of trust than the information obtained through a BU sent from the MR to the HA. However, both informations are stored in the same BCE, with the same parameters, in particular with the same lifetime. This is a security problem since the lifetime of the BCE is closely related with the level of trust of the information within the BCE, in particular, the BCE lifetime defines the level of protection against the time shifted attacks. Now, the information protected with IPSec SA between the MR and the HA is not vulnerable against time shifted attacks, while the information contained in the RRH may be vulnerable to time shifted attacks, as presented next. The key elements when preventing time shifting attacks, imho, are: - the BCE lifetime - the frequency of the RRH Now let me put an example of how a time shifted attack would be imho: - suppose that the MR is configured to send a RRH only with a relatively low frequency once that the first RRH is sent i.e. it doesn't sends RRH in all data packets, only in one in a time T (suppose time T long for efficiency). I guess this makes a lot of sense since we don't want to introduce the RRH overhead in all packets. This means, that upon the reception of the RRH, the information contained in the RRH will be stored in the HA BCE for the BCE lifetime (which may be very long) and will not be refreshed for a period T. Now suppose that an attacker, that is on the path, modifies the content of the RRH, including its own address on the RRH. This means that for the time T, the HA will be sending packet to the attacker. Now MIPv6 prevents this type of attacks by limiting BCE lifetime to 7 minutes. The problem here is that the BCE lifetime may be higher because the BU that has created it was protected with an IPSec SA. The result of this attack is that an attacker may be on the path for just a moment and launch an attack that last for a period T (which may be very long) AFAICT the draft does not consider this explicitely, in particular it doesn't defines values for T. Please note that sending the RRH in every packet doesn't really protects against this attacks, since for instance unidirectional flows comming from the HA to the MR would still be susceptible to this type of attacks. My suggestion would be to limit the lifetime of the information obtained from the RRH to 7 minutes, the same that the BCE information obtained through the RR procedure. Comments? Regards, marcelo From nemo-bounces@ietf.org Mon Oct 18 14:49:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11939 for ; Mon, 18 Oct 2004 14:49:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcBR-00035j-JW; Mon, 18 Oct 2004 14:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbxh-0001Jc-QA for nemo@megatron.ietf.org; Mon, 18 Oct 2004 14:10:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08069 for ; Mon, 18 Oct 2004 14:10:14 -0400 (EDT) Received: from [203.252.134.6] (helo=cclab.konkuk.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJc9F-00063Z-CN for nemo@ietf.org; Mon, 18 Oct 2004 14:22:42 -0400 Received: from cclab.konkuk.ac.kr (cclab.konkuk.ac.kr [127.0.0.1]) by cclab.konkuk.ac.kr (8.12.8/8.12.8) with ESMTP id i9II9GiK003941; Tue, 19 Oct 2004 03:09:16 +0900 Received: (from apache@localhost) by cclab.konkuk.ac.kr (8.12.8/8.12.8/Submit) id i9II9FIB003939; Tue, 19 Oct 2004 03:09:15 +0900 From: Park KiYong X-Authentication-Warning: cclab.konkuk.ac.kr: apache set sender to kypark@cclab.konkuk.ac.kr using -f Received: from 220.72.200.15 ([220.72.200.15]) by cclab.konkuk.ac.kr (IMP) with HTTP for ; Tue, 19 Oct 2004 03:09:15 +0900 Message-ID: <1098122955.417406cb46cde@cclab.konkuk.ac.kr> Date: Tue, 19 Oct 2004 03:09:15 +0900 To: Alexandru Petrescu Subject: Re: [nemo] NEMO RO problem draft submit References: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> <001e01c4b50e$f230cab0$a486fccb@nbclearsky> <4173E4C2.2090609@motorola.com> In-Reply-To: <4173E4C2.2090609@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 220.72.200.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 8bit Dear Alex, I have different opinion If the case is MN behind MR, it is right as you said. If the case is LFN behind MR, it can be solved by existing IPv6 techniques the case of LFN behind MR must be routed through HA. I think that the MR keeps home network prefixes it received from Home Network's Router. And CN to LFN will be routed through CN-HA-LFN, because the MR did registration request with its home network prefixes to its HA. Although the network prefixes was changed and LFN's address was changed in new network, the communication will be kept by 'Address renumbering mechanism in IPv6'. Because of that, the communication will not be lost. Please, reply me with your opinion. Best regard. Kiyong Park. Alexandru Petrescu wrote: > Kiyong Park wrote: > > I already read a draft about the solution of NEMO RO problem using > > Prefix Delegation Mechanism in IPv6 You can access it at : > > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-leekj- nemo-ro-pd-01.txt > > > > I think it is abolutely correct solution of NEMO RO problem. Any > > other opinion, it will be great to me. > > Hello Kiyong Park. > > IMHO it is debatable whether that PD with Neighbour Discovery solution > is a correct solution for the NEMO RO problem since we don't know > exactly what the RO problem is. > > If the RO problem is that MN-behind-MR communication to CN goes through > HA (instead of directly) then yes, that PD solution is solving it. If > on the other hand the problem is that LFN-behind-MR communication to CN > goes through HA (instead of directly) then no, that PD solution is not > solving it, because that draft does not describe how MR performs RO on > behalf of LFN (LFN does not do Mobile IPv6). In my understanding. > > Alex > -------------------------------------------- This mail sent through CCLab web mail server From nemo-bounces@ietf.org Mon Oct 18 15:42:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17001 for ; Mon, 18 Oct 2004 15:42:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJd2N-00066G-Ii; Mon, 18 Oct 2004 15:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcXc-0007ye-GR for nemo@megatron.ietf.org; Mon, 18 Oct 2004 14:47:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11781 for ; Mon, 18 Oct 2004 14:47:24 -0400 (EDT) Received: from [203.252.134.6] (helo=cclab.konkuk.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJcjI-0006um-7D for nemo@ietf.org; Mon, 18 Oct 2004 14:59:53 -0400 Received: from cclab.konkuk.ac.kr (cclab.konkuk.ac.kr [127.0.0.1]) by cclab.konkuk.ac.kr (8.12.8/8.12.8) with ESMTP id i9IIkRiK004243; Tue, 19 Oct 2004 03:46:27 +0900 Received: (from apache@localhost) by cclab.konkuk.ac.kr (8.12.8/8.12.8/Submit) id i9IIkRcl004241; Tue, 19 Oct 2004 03:46:27 +0900 From: Park KiYong X-Authentication-Warning: cclab.konkuk.ac.kr: apache set sender to kypark@cclab.konkuk.ac.kr using -f Received: from 220.72.200.15 ([220.72.200.15]) by cclab.konkuk.ac.kr (IMP) with HTTP for ; Tue, 19 Oct 2004 03:46:27 +0900 Message-ID: <1098125187.41740f8394f40@cclab.konkuk.ac.kr> Date: Tue, 19 Oct 2004 03:46:27 +0900 To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] NEMO RO problem draft submit References: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> <001e01c4b50e$f230cab0$a486fccb@nbclearsky> <4173E4C2.2090609@motorola.com> <1098122955.417406cb46cde@cclab.konkuk.ac.kr> In-Reply-To: <1098122955.417406cb46cde@cclab.konkuk.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 220.72.200.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 8bit Dear Alex. Please, ignore my opinion. I didn't think about the case that the MR moves from old Foreign Network to new Foreign Network. I'll think over the solution. Best regard. Kiyong Park. kypark@cclab.konkuk.ac.kr wrote: > Dear Alex, > > I have different opinion > > If the case is MN behind MR, it is right as you said. > > If the case is LFN behind MR, it can be solved by existing IPv6 techniques > > the case of LFN behind MR must be routed through HA. > > I think that the MR keeps home network prefixes it received from Home > Network's Router. > > And CN to LFN will be routed through CN-HA-LFN, because the MR did > registration > request with its home network prefixes to its HA. > > Although the network prefixes was changed and LFN's address was changed in > new > network, the communication will be kept by 'Address renumbering mechanism in > IPv6'. > > Because of that, the communication will not be lost. > > Please, reply me with your opinion. > > Best regard. > Kiyong Park. > > Alexandru Petrescu wrote: > > > Kiyong Park wrote: > > > I already read a draft about the solution of NEMO RO problem using > > > Prefix Delegation Mechanism in IPv6 You can access it at : > > > > > > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-leekj- > nemo-ro-pd-01.txt > > > > > > I think it is abolutely correct solution of NEMO RO problem. Any > > > other opinion, it will be great to me. > > > > Hello Kiyong Park. > > > > IMHO it is debatable whether that PD with Neighbour Discovery solution > > is a correct solution for the NEMO RO problem since we don't know > > exactly what the RO problem is. > > > > If the RO problem is that MN-behind-MR communication to CN goes through > > HA (instead of directly) then yes, that PD solution is solving it. If > > on the other hand the problem is that LFN-behind-MR communication to CN > > goes through HA (instead of directly) then no, that PD solution is not > > solving it, because that draft does not describe how MR performs RO on > > behalf of LFN (LFN does not do Mobile IPv6). In my understanding. > > > > Alex > > > > > > > -------------------------------------------- > This mail sent through CCLab web mail server > -------------------------------------------- This mail sent through CCLab web mail server From nemo-bounces@ietf.org Tue Oct 19 04:53:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02444 for ; Tue, 19 Oct 2004 04:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpJk-0000DO-PI; Tue, 19 Oct 2004 04:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJoxL-0005xo-7Y for nemo@megatron.ietf.org; Tue, 19 Oct 2004 04:02:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29355 for ; Tue, 19 Oct 2004 04:02:48 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJp9P-0006sP-Mk for nemo@ietf.org; Tue, 19 Oct 2004 04:15:24 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 10:17:10 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9J81wSt005764; Tue, 19 Oct 2004 10:02:14 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 10:02:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: About RRH security (was Re: [nemo] RE: RO between MR and CN Date: Tue, 19 Oct 2004 10:02:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC30859B@xmb-ams-337.emea.cisco.com> Thread-Topic: About RRH security (was Re: [nemo] RE: RO between MR and CN Thread-Index: AcS1O0hClVOd4IlPTFKwvCyZcq1kHAAcJlEw From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 19 Oct 2004 08:02:13.0023 (UTC) FILETIME=[F0FDF2F0:01C4B5B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: nemo WG , =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: lundi 18 octobre 2004 19:52 > To: Pascal Thubert (pthubert) > Cc: nemo WG; Mar=EDa Calder=F3n; Carlos Jes=FAs Bernardos Cano > Subject: About RRH security (was Re: [nemo] RE: RO between MR and CN >=20 > Hi all, >=20 > This is part of the security analysis that we have performed about the > RRH. >=20 > I guess that we could summarize it as follows: > - The RRH security issues that we identified are more related to lack > of specification rather than fundamental ones. Meaning that IMHO, the > current draft doesn't take into account some issues, in particular > time-shifted attacks, when performing the RRH. > - The identified issues can be solved through proper host behaviour. >=20 > The main security problem of RRH imho is related with the fact that = the > signaling channel between the MR and the HA is protected through a > IPSec SA that may be manually configured, for instance. This means = that > the resulting level of trust may be relatively high. However, the > information contained in the RRH, is not protected with this SA, and > its protection relies on that the presence of the attacker along the > path, so the information obtained through RRH has a different level of > trust than the information obtained through a BU sent from the MR to > the HA. However, both informations are stored in the same BCE, with = the > same parameters, in particular with the same lifetime. This is a > security problem since the lifetime of the BCE is closely related with > the level of trust of the information within the BCE, in particular, > the BCE lifetime defines the level of protection against the time > shifted attacks. > Now, the information protected with IPSec SA between the MR and the HA > is not vulnerable against time shifted attacks, while the information > contained in the RRH may be vulnerable to time shifted attacks, as > presented next. >=20 > The key elements when preventing time shifting attacks, imho, are: > - the BCE lifetime > - the frequency of the RRH >=20 > Now let me put an example of how a time shifted attack would be imho: > - suppose that the MR is configured to send a RRH only with a > relatively low frequency once that the first RRH is sent i.e. it > doesn't sends RRH in all data packets, only in one in a time T = (suppose > time T long for efficiency). I guess this makes a lot of sense since = we > don't want to introduce the RRH overhead in all packets. > This means, that upon the reception of the RRH, the information > contained in the RRH will be stored in the HA BCE for the BCE lifetime > (which may be very long) and will not be refreshed for a period T. > Now suppose that an attacker, that is on the path, modifies the = content > of the RRH, including its own address on the RRH. > This means that for the time T, the HA will be sending packet to the > attacker. If I understand your point, the problem is the time shifting attack has = consequences even when the attacker is gone, at least till the next RRH. = The draft does not mention how often RRH are sent and what triggers = them.=20 Note that in this case, and as opposed to MIP RO, the L4 ACKs are still = protected because there is an SA. So redirecting packets like this would = be equivalent to destroying them, and then the flows tarish. But you can = not make that a bombing attack. Since the guy in on the path, it's = easier for him to just destroy the packets. And once he's gone, he can = not reuse any token he got while he was in to maintain the attack. Our implementation has a number of heuristics to decide when to roam and = when to send RRH. And I guess there could be many more that could make a = difference on the marketplace while still maintaining interoperability. = MIP does not tell you when to roam. The RRH draft does not tell you when = to send RH4's as opposed to RH3's. But as you suggest, explaining that = issue and giving directions could be very useful. The lack of traffic back might be a trigger, to, like, send RRH first, = and if it's still no good, move to another AR. The bandwidth you get = (back and forth) is more often then not the key to movement. When you = have IPSEC, an unknown access with a lot of bandwidth might be a better = choice then a safe access that's very benevolent and very slow ... like = a modem. >=20 > Now MIPv6 prevents this type of attacks by limiting BCE lifetime to 7 > minutes. The problem here is that the BCE lifetime may be higher > because the BU that has created it was protected with an IPSec SA. >=20 > The result of this attack is that an attacker may be on the path for > just a moment and launch an attack that last for a period T (which may > be very long) >=20 > AFAICT the draft does not consider this explicitely, in particular it > doesn't defines values for T. > Please note that sending the RRH in every packet doesn't really > protects against this attacks, since for instance unidirectional flows > comming from the HA to the MR would still be susceptible to this type > of attacks. Again, the lack of incoming traffic can trigger a RRH. A BU can be used = to convey it in the absence of traffic. The question is when you have a = malevolent guy on your path, he can easily kill your traffic by just = scrambling the radio waves of dropping packets. The problem you raise, = as I understand it, is to avoid lasting effects when the bad guy is = gone. Again, this is not MIP RO where the bad guy is an intruder close = to the CN that attacks and goes. Here, the "bad guy" might stay there. = You might even be visiting him. It's not only a question of adding a RRH = but also a question of detecting a situation and moving away. > My suggestion would be to limit the lifetime of the information > obtained from the RRH to 7 minutes, the same that the BCE information > obtained through the RR procedure. >=20 >=20 > Comments? Thanks a lot for you point. I'll try some text and submit it to you, = unless you wish to propose something? In our implementation, RRH is sent much more often then every 7mn and = it's configurable by the user. We also have an exponential backoff. And like I said, there's more to it. Maybe we should start a reflection = on roaming heuristics when you're in un-trusted territories, what = happens if there's r rogue on the way, how MR/MNs react to fluctuating = bandwidth (back and forth) etc... Obviously this is beyond the RRH = draft... Pascal From nemo-bounces@ietf.org Tue Oct 19 06:14:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07518 for ; Tue, 19 Oct 2004 06:14:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqTp-00022e-5I; Tue, 19 Oct 2004 05:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqDu-00080w-Cl for nemo@megatron.ietf.org; Tue, 19 Oct 2004 05:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04404 for ; Tue, 19 Oct 2004 05:23:59 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqPz-0008JD-Ok for nemo@ietf.org; Tue, 19 Oct 2004 05:36:36 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A438E2D68C; Tue, 19 Oct 2004 11:23:28 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id 460082D6B5; Tue, 19 Oct 2004 11:23:28 +0200 (CEST) Subject: Re: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <20041015.234051.48485883.watari@sfc.wide.ad.jp> References: <20041015.234051.48485883.watari@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ichDH/DT6BWWldq9o5MN" Organization: Universidad Carlos III de Madrid Message-Id: <1098177846.2468.33.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 19 Oct 2004 11:24:06 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-ichDH/DT6BWWldq9o5MN Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Dear Masafumi, I think that the draft is useful and helps in the description of the problem statement in nested NEMOs, so thanks for providing it. I have a couple of comments. First, in the case A (LFN and standard IPv6 CN), you say that "To avoid tunneling through any HA, Correspondent Routes (CRs) may be placed near CNs to handle bindings. CRs are routers enhanced which the ability to handle bindings for a mobile network, allowing a direct tunnel to the MR providing a certain level of optimization." IMHO, CRs are not the only solution that may be used to provide a certain level of optimisation. There are other solutions, like using some kind of ad-hoc routing within the nesting, RRH, etc, that can reduce the number of tunnels to only one. I'd suggest to maintain the sentence "Route optimization would require collaboration among the MRs" and maybe rewrite the other part to just provide examples, like the one of CRs and maybe others.=20 In the case I (VMN and standard IPv6 CN), maybe it's worth IMHO to point that the VMN could also use its CoA (looking at RFC3775, I think that it is an implementation dependant behaviour) to some communications. For example, if a VMN attaches to a NEMO, for short-lived communications (e.g. DNS requests), it may prefer to use its CoA as source address. Therefore, IMHO, I think it would be useful to add some text pointing that also. What do you think? Kind Regards, Carlos J. El vie, 15-10-2004 a las 16:40, Masafumi Watari escribi=F3: > Hello, >=20 > I've submitted a draft based on the presentation I made during the SD > meeting. Please find the document in the URL below. >=20 > http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt >=20 > I hope that the draft helps the problem statement of Neste NEMO, and > that the solution for RO considers the differenent cases metioned in > the draft. >=20 > Thanks, >=20 > Masafumi Watari >=20 > ______________________________________________________________________ > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-watari-nemo-nested-cn-00.txt > Date: Thu, 14 Oct 2004 16:19:27 -0400 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Route Optimization with Nested Correspondent Nodes > Author(s) : M. Watari, T. Ernst > Filename : draft-watari-nemo-nested-cn-00.txt > Pages : 18 > Date : 2004-10-14 > =09 > This document aims at assisting the problem statement of route > optimization in nested mobile networks. We describe the paths > packets would take using existing Mobile IPv6 and NEMO Basic Support > mechanisms when one or both end nodes of a communication flow are > located in a nested NEMO. One of both of the end nodes may > themselves be either mobile nodes performing Mobile IPv6, or standard > IPv6 nodes performing no mobility function at all. The path can > become extremely suboptimal if no optimization is provided. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the usern= ame > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-watari-nemo-nested-cn-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-watari-nemo-nested-cn-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > ______________________________________________________________________ > Content-Type: text/plain > Content-ID: <2004-10-14164528.I-D@ietf.org> >=20 >=20 > ______________________________________________________________________ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-ichDH/DT6BWWldq9o5MN Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBdN025vKyPtrWqkARAmjAAKConEAZufYZxyew0+2859leXqm82wCdEBiv oBVppz7cdq8EspXwee7gOZA= =xkKi -----END PGP SIGNATURE----- --=-ichDH/DT6BWWldq9o5MN-- From nemo-bounces@ietf.org Tue Oct 19 06:14:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07537 for ; Tue, 19 Oct 2004 06:14:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqTp-00023e-R7; Tue, 19 Oct 2004 05:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqEh-00087f-7o for nemo@megatron.ietf.org; Tue, 19 Oct 2004 05:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04426 for ; Tue, 19 Oct 2004 05:24:47 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqQj-0008KN-Uh for nemo@ietf.org; Tue, 19 Oct 2004 05:37:25 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 521496245; Tue, 19 Oct 2004 02:23:37 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68229-01; Tue, 19 Oct 2004 02:23:36 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 60F956233; Tue, 19 Oct 2004 02:23:36 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id B56F461D4; Tue, 19 Oct 2004 02:23:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Date: Tue, 19 Oct 2004 02:24:42 -0700 To: IETF NEMO WG X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" Subject: [nemo] New draft on prefix delegation X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, Pascal and I have put together a draft that talks about how prefix provisioning and delegation can happen at the NEMO protocol level. This is intended to be a complementary process to what Ralph has described, that happens at the back end and DHCPv6 servers. Ideally, if the WG thinks this approach is good, we would like to better integrate the DHCPv6 back end approach (and possibly others, if proposed). http://www.mobilenetworks.org/nemo/drafts/draft-kniveton-nemo-prefix- del-00.html (html) or http://www.mobilenetworks.org/nemo/drafts/draft-kniveton-nemo-prefix- del-00.txt (text) This draft is a work in progress, since we have changed the formats quite a bit while writing -00, the sections might not all match up so please feel free to point out discrepancies. While the draft didn't make it to the IETF repository by yesterday's -00 cutoff, we would still encourage anyone interested to read it before the Washington meeting. -TJ & Pascal From nemo-bounces@ietf.org Tue Oct 19 21:30:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13051 for ; Tue, 19 Oct 2004 21:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3mP-0001LY-9c; Tue, 19 Oct 2004 19:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJtTP-0007YN-A2 for nemo@megatron.ietf.org; Tue, 19 Oct 2004 08:52:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19608 for ; Tue, 19 Oct 2004 08:52:12 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtfW-0003u0-QU for nemo@ietf.org; Tue, 19 Oct 2004 09:04:51 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9JCrSG2020000; Tue, 19 Oct 2004 05:53:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i9JCoqIk026426; Tue, 19 Oct 2004 07:50:53 -0500 Received: from [10.161.201.119] (zfr01-2119.crm.mot.com [10.161.201.119]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2A4B88A3A63; Tue, 19 Oct 2004 14:52:06 +0200 (CEST) Message-ID: <41750DF5.2070108@motorola.com> Date: Tue, 19 Oct 2004 14:52:05 +0200 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Masafumi Watari Subject: Re: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt References: <20041015.234051.48485883.watari@sfc.wide.ad.jp> <1098177846.2468.33.camel@acorde> In-Reply-To: <1098177846.2468.33.camel@acorde> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id i9JCrSG2020000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Masafumi, Carlos, Masafumi, thanks for the draft. I think it helps in explaining the=20 overhead of the NEMO basic support protocol with nested moving networks.=20 Especially, I liked that the many different scenarios (location/type=20 of CN and MNN) have been considered. Few comments below, somehow inline with Carlos' ones: Carlos Jes=FAs Bernardos Cano wrote: > I have a couple of comments. First, in the case A (LFN and standard > IPv6 CN), you say that >=20 > "To avoid tunneling through any HA, Correspondent Routes (CRs) may be > placed near CNs to handle bindings. CRs are routers enhanced which > the ability to handle bindings for a mobile network, allowing a > direct tunnel to the MR providing a certain level of optimization." >=20 > IMHO, CRs are not the only solution that may be used to provide a > certain level of optimisation. There are other solutions, like using > some kind of ad-hoc routing within the nesting, RRH, etc, that can > reduce the number of tunnels to only one. I'd suggest to maintain the > sentence "Route optimization would require collaboration among the MRs" > and maybe rewrite the other part to just provide examples, like the one > of CRs and maybe others.=20 I agree that CR is not the only solutions, and I also understand that it=20 is not the objective of the draft to list solutions nor discuss them in=20 details. So, IMHO, I would suggest to remove from the draft any=20 references to solutions (such as CR, or others). This would provide a draft focusing _only_ on the issues with the=20 current protocols (highlighting the need for RO) but free of any=20 solution. Only then, IMHO, the draft could provide the needed=20 necessary-unbiased foundations for the problem statement discussion in=20 the WG. So I would propose to remove the two following paragraphs: o in 2.1: "Route optimization would require collaboration among the MRs. To avoid tunneling through any HA, Correspondent Routes (CRs) may be placed near CNs to handle bindings. CRs are routers enhanced which the ability to handle bindings for a mobile network, allowing a direct tunnel to the MR providing a certain level of optimization." o in 3: "The models generally assumed for route optimization are optimization among all MRs in both NEMOs, and a bi-directional tunnel between the two root-MRs." Another comment on section 5.3: - What is the HA4 mentioned in the text? It does not appear in Fig=20 13, nor in fig 16. - Fig.16: the path down to CN seems to be missing in the figure.=20 Should it not be like: VMN - MR3 - MR2 - MR1 - MR1_HA - MR2_HA - MR3_HA - VMN_HA - MR3_HA -=20 MR2_HA - MR1_HA - MR1 - MR2 - MR3 - CN Thanks, Christophe. From nemo-bounces@ietf.org Tue Oct 19 21:41:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13633 for ; Tue, 19 Oct 2004 21:41:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3wL-0004Tt-6E; Tue, 19 Oct 2004 20:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJth2-0000l9-VX for nemo@megatron.ietf.org; Tue, 19 Oct 2004 09:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21038 for ; Tue, 19 Oct 2004 09:06:18 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJttA-0004OE-63 for nemo@ietf.org; Tue, 19 Oct 2004 09:18:56 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i9JD21u9004206; Tue, 19 Oct 2004 06:02:01 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9JCr1tD017022; Tue, 19 Oct 2004 07:53:02 -0500 Message-ID: <41751006.4090005@motorola.com> Date: Tue, 19 Oct 2004 15:00:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J.Kniveton" Subject: Re: [nemo] New draft on prefix delegation References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2074219383CDCCAA3126D493" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2074219383CDCCAA3126D493 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi TJ, Pascal, thank you for putting up this draft proposing to request assignment of prefixes with a BU and assignment confirmation with BAck. This is an interesting idea. Other methods could be DHCP, and even piggybacking with Mobile Prefix Discovery or with Dynamic Home Agent Address Discovery, etc. I'm tempted to favor DHCP, see below. T.J.Kniveton wrote: > Pascal and I have put together a draft that talks about how prefix > provisioning and delegation can happen at the NEMO protocol level. > This is intended to be a complementary process to what Ralph has > described, that happens at the back end and DHCPv6 servers. Ideally, > if the WG thinks this approach is good, we would like to better > integrate the DHCPv6 back end approach (and possibly others, if > proposed). Would a NEMO-PD-enabled HA use a DHCPv6 server to manage the prefix allocation? I suppose this is what you mean by "integrate the DHCPv6 back end approach". I personally would go for an entirely DHCP-based solution. Allocating and freeing prefixes (and addresses) is usually large programs, risky to run in the kernel space. HA is usually in kernel, DHCP server in app space. Exceptions there are to this, ok, but still. DHCP has other advantages as well. It already has hierarchical concepts (Server and Relay), while HA has not. This could be used with a large moving network served by only a MR and that has many internal FR's (fixed). Using DHCP, MR may act as a Client and request a short prefix from its home DHCP Server and simultaneously act as a Relay (or Server) and assign a longer prefix to its FR's acting respectively as Clients. On the contrary, delegating prefixes in the BU/BAck makes it impossible for FR's to acquire a prefix, since they don't run Mobile IPv6. An additional advantage of DHCP is reusing the complex management software that a DHCP does for addresses (allocate, free, re-allocate, manage fragmentation), etc. HA has no such functionality that could be reused. > CorId: A Correlator that is set by the MR in order to associate a MNP > request with the prefix given in the confirmation. There can be at > most one active prefix associated with each Correlator. This > mechanism ensures the uniqueness of the allocation of a prefix, > should either the BU or the BA be lost in transit. In order to guarantee uniqueness of the assignment, the association should base also on the Home Address because different MR's may generate same CorID. With DHCP, this "uniqueness" is based on the MAC address and with a Transaction ID. With DHCP there are options for releasing addresses. On the contrary BU-BAck PD does not have a feature to release a prefix. Releasing is important, because if an MR goes asleep another MR can re-use that prefix. With DHCP there are options for going in "dormant" mode and back up again, minimizing the amount of messages exchanged. With DHCP there are possibilities to update the DNS as well (although no prefixes in the DNS, but gateway addresses may be needed). When DHCP assigns/removes an address, it automatically adds/removes routes corresponding to that address. This is re-usable software, essential when assigning a prefix. The draft in question proposes similar features (transient/persistent). DHCP has a message CONFIRM, sent by the Client. BU/BAck has a MNP Confirmation option, but sent by the HA :-) Finally, my oppinion is that the method used by the MIP6 WG to assign a Home Address to MN should be used by NEMO too, for prefixes. That is, if MIP6 MN generates the Home Address from DHAAD+MPD then NEMO should do MNP from MPD. If MIP6 assigns the Home Address from DHCP, then NEMO should do MNP from DHCP too. Same with BU/BAck. > Proposing a new, specific solution might seem irrelevant when a > standard, generic mechanism already exists: in this case, the DHCPv6 > Prefix Delegation. In fact, it is possible for the Home Agent to > act as a DHCPv6PD Delegating Router. This solution presents the > advantage of reusing existing standard flows from RFC3633 [6]. I agree with this. > Yet, in a deployment where the MNPs are preassigned to the MR, a AAA > server, interfacing with the HA, and eventually coupled with a > provisioning system in its back-end, can provide the required service > for assigning and authorizing the prefixes to the MRs; in such a > case, the value of implementing a DHCPv6PD server is highly arguable. > > Yes, it is highly arguable. I do not know whether a Radius server uses DHCP or not. I do not know whether a Radius server can talk to a IPv6 HA either... What do you think... Alex --------------enig2074219383CDCCAA3126D493 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdRAMMmC0w56zj54RAm1dAKC5bYdqN/siu6ty43gu24oMPJDP5QCfRKX3 hAWX7Xn1yXLE+JMsZ7JuoyU= =w49U -----END PGP SIGNATURE----- --------------enig2074219383CDCCAA3126D493-- From nemo-bounces@ietf.org Tue Oct 19 22:21:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17016 for ; Tue, 19 Oct 2004 22:21:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4DF-0004Dr-84; Tue, 19 Oct 2004 20:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJw8Q-00048W-A9 for nemo@megatron.ietf.org; Tue, 19 Oct 2004 11:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08106 for ; Tue, 19 Oct 2004 11:42:42 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwKV-0000vY-Um for nemo@ietf.org; Tue, 19 Oct 2004 11:55:23 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 17:57:08 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9JFg5Sf027975; Tue, 19 Oct 2004 17:42:05 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 17:42:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] New draft on prefix delegation Date: Tue, 19 Oct 2004 17:41:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] New draft on prefix delegation Thread-Index: AcS13HN2S5lzqBvVT9OVQTKRixvqWQAE5Hdw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "T.J.Kniveton" X-OriginalArrivalTime: 19 Oct 2004 15:42:03.0405 (UTC) FILETIME=[2E2423D0:01C4B5F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: mardi 19 octobre 2004 15:01 > To: T.J.Kniveton > Cc: IETF NEMO WG; Pascal Thubert (pthubert) > Subject: Re: [nemo] New draft on prefix delegation >=20 > Hi TJ, Pascal, thank you for putting up this draft proposing to request > assignment of prefixes with a BU and assignment confirmation with BAck. > This is an interesting idea. :) =20 > Other methods could be DHCP, and even piggybacking with Mobile Prefix > Discovery or with Dynamic Home Agent Address Discovery, etc. I'm > tempted to favor DHCP, see below. > You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever. In fact, it's a WG doc.=20 Here, we are looking at a NEMO based alternative, for instance should PD be overkill in a given deployment. For instance, prefixes might be attributed be a provisioning system and available to the HA via AAA.=20 One value of the NEMO approach is agnostic to the backend installation. > T.J.Kniveton wrote: > > Pascal and I have put together a draft that talks about how prefix > > provisioning and delegation can happen at the NEMO protocol level. > > This is intended to be a complementary process to what Ralph has > > described, that happens at the back end and DHCPv6 servers. Ideally, > > if the WG thinks this approach is good, we would like to better > > integrate the DHCPv6 back end approach (and possibly others, if > > proposed). >=20 > Would a NEMO-PD-enabled HA use a DHCPv6 server to manage the prefix > allocation? I suppose this is what you mean by "integrate the DHCPv6 > back end approach". >=20 > I personally would go for an entirely DHCP-based solution. Allocating > and freeing prefixes (and addresses) is usually large programs, risky to > run in the kernel space. HA is usually in kernel, DHCP server in app > space. Exceptions there are to this, ok, but still. You mean, it's easier for the MR then for the HA to be a DHCP client? > DHCP has other advantages as well. It already has hierarchical concepts > (Server and Relay), while HA has not. This could be used with a large > moving network served by only a MR and that has many internal FR's > (fixed). Using DHCP, MR may act as a Client and request a short prefix > from its home DHCP Server and simultaneously act as a Relay (or Server) > and assign a longer prefix to its FR's acting respectively as Clients. >=20 > On the contrary, delegating prefixes in the BU/BAck makes it impossible > for FR's to acquire a prefix, since they don't run Mobile IPv6. You go it right that we thought that the HA might be a PD client. We are looking for some help from Ralph on the back end consideration section to detail exactly how that could work. In that case, the FR can benefit from PD as well. > An additional advantage of DHCP is reusing the complex management > software that a DHCP does for addresses (allocate, free, re-allocate, > manage fragmentation), etc. HA has no such functionality that could be > reused. Right. The right choice depends a lot on the provisioning. If choice there is :) > > CorId: A Correlator that is set by the MR in order to associate a MNP > > request with the prefix given in the confirmation. There can be at > > most one active prefix associated with each Correlator. This > > mechanism ensures the uniqueness of the allocation of a prefix, > > should either the BU or the BA be lost in transit. >=20 > In order to guarantee uniqueness of the assignment, the association > should base also on the Home Address because different MR's may generate > same CorID. With DHCP, this "uniqueness" is based on the MAC address > and with a Transaction ID. Right. If it's unclear then it's an issue against the doc. Cool. >=20 > With DHCP there are options for releasing addresses. On the contrary > BU-BAck PD does not have a feature to release a prefix. Releasing is > important, because if an MR goes asleep another MR can re-use that prefix. Yes, there is. But we mapped things to the binding lifecycle as opposed to making a separate lifecycle. Tighter integration, you know :) >=20 > With DHCP there are options for going in "dormant" mode and back up > again, minimizing the amount of messages exchanged. >=20 > With DHCP there are possibilities to update the DNS as well (although no > prefixes in the DNS, but gateway addresses may be needed). Right. HA doing DHCPv6PD client for transient prefixes could make a lot of sense. Managing a local pool could do the job too... For persistent prefixes, I guess it might rather depend on the AAA system, though. Let's see what inputs we get from the ML. Pascal From nemo-bounces@ietf.org Tue Oct 19 22:32:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17785 for ; Tue, 19 Oct 2004 22:32:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4cL-00023S-Ey; Tue, 19 Oct 2004 20:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwiK-0000P6-SH for nemo@megatron.ietf.org; Tue, 19 Oct 2004 12:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11860 for ; Tue, 19 Oct 2004 12:19:49 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwuT-00027g-0F for nemo@ietf.org; Tue, 19 Oct 2004 12:32:30 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9JGL6G2026943; Tue, 19 Oct 2004 09:21:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9JGJiXO012273; Tue, 19 Oct 2004 11:19:44 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AC2338A3A63; Tue, 19 Oct 2004 18:19:43 +0200 (CEST) Message-ID: <41753E99.9030007@motorola.com> Date: Tue, 19 Oct 2004 18:19:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] New draft on prefix delegation References: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FE0C049E55A4FE572D0D7D0" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FE0C049E55A4FE572D0D7D0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> Other methods could be DHCP, and even piggybacking with Mobile >> Prefix Discovery or with Dynamic Home Agent Address Discovery, etc. >> I'm tempted to favor DHCP, see below. >> > You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever. > In fact, it's a WG doc. You mean draft-droms-nemo-dhcpv6-pd-01.txt is a WG item? There are aspects in that draft that are not necessary in order to delegate prefixes from HA to MR (Tree Options, MR obtaining a prefix from AR, etc.) And there are NEMO-relevant aspects that are not mentioned in that draft. For example, when MR requests a DP it should be sent on the same MR-HA tunnel interface, and not "on the interface associated associated with the upstream router". Moreover, MR MUST NOT perform Delegating Router Solicitation operations of RFC3315 while not at home. draft-droms-pd-nemo: > For example, in the case of Basic Network Mobility Support [6], the > HA would add an entry in its binding cache registering the delegated > prefix to the MR to which the prefix was delegated. No! Adding an entry in the BC should be a result of receiving a BU and not of assigning a prefix, IMHO. However, HA assigning a prefix to MR SHOULD result in a route added in the HA and a route added in the MR. >> With DHCP there are options for releasing addresses. On the >> contrary BU-BAck PD does not have a feature to release a prefix. >> Releasing is important, because if an MR goes asleep another MR can >> re-use that prefix. > > Yes, there is. But we mapped things to the binding lifecycle as > opposed to making a separate lifecycle. I think the MR should still have the opportunity to trigger the release of a MNP, instead of waiting for a timeout. Alex --------------enig3FE0C049E55A4FE572D0D7D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdT6fMmC0w56zj54RAnfgAJ99VUpFg+0qKpRTQKnNKF5nM71o+QCg0+99 vvECjK+8RIv1cl3gGu5F4b8= =nLAW -----END PGP SIGNATURE----- --------------enig3FE0C049E55A4FE572D0D7D0-- From nemo-bounces@ietf.org Tue Oct 19 22:36:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18323 for ; Tue, 19 Oct 2004 22:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4dJ-0003bb-Bq; Tue, 19 Oct 2004 20:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJxJU-0004oO-VU for nemo@megatron.ietf.org; Tue, 19 Oct 2004 12:58:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16091 for ; Tue, 19 Oct 2004 12:58:12 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJxVb-0003Fp-Kc for nemo@ietf.org; Tue, 19 Oct 2004 13:10:54 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 19:12:35 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9JGvBSv016333; Tue, 19 Oct 2004 18:57:31 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 18:57:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: RO between MR and CN Date: Tue, 19 Oct 2004 18:57:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: RO between MR and CN Thread-Index: AcSx1cHh2NOj3oehSGS7VOJ+78792QEHlYAQ From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "Masafumi Watari" X-OriginalArrivalTime: 19 Oct 2004 16:57:10.0946 (UTC) FILETIME=[ACD85020:01C4B5FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Carlos :) Is the MIRON document already published in a final form or does it make = sense to provide feed back for lower interest things like typos? For the = time being, let me discuss concepts. > > Hi, > > > > On Wed, 13 Oct 2004 13:34:06 +0200, > > "Pascal Thubert (pthubert)" wrote: > > > > > Hi Tania > > > > > > I was thinking things like of snooping. MR might intercept all = packets to LFN, recognize > a HoT and keep it. I remember discussing that with Alex long ago... = Anyway, we try to say > "don't take that path" as opposed to describe a solution in details. > > > > I don't think its possible to provide RO while keeping the RR = function > > of MIPv6 untouched. It would probably require modification of the > > packet at MR to use the HoA opt and the routing header for every > > packet, if we want to keep the MIPv6 spec as is. >=20 > Yes, one possible solution is the MR performing all the RR and RO > signalling on behalf of the LFNs of the NEMO, in order to provide RO = for > LFNs that are communicating to CNs outside the NEMO. This is actually > the solution we have proposed in MIRON (see my previous e-mail if you > want a pointer to it), so the MR, as you said, has to process the > packets sent/received by a LFN in order to insert HoA DO/remove RH. I > agree that it could have some performance concerns if the process is > performed to every LFN-CN "flow", but as we have already discussed in = a > previous thread, some mechanism should be used to perform the RO in a > reasonable way. There are 2 aspects to the proposal, even if (like ORC) it's packaged as = one. The first aspect is the proxying for the MNN. The second is = obtaining a topologically correct CoA via DHCP. 1) proxying As we say in this thread, we discussed that on the ML, at least Alex and = I, and there are some identified protential problems to the approach = (that might be worth more text in the taxonomy?) that you might have to = deal with: 1a) MNN is VMN If the MNN is a visitor that handles its own mobility and RO, the MR = might in fact act as an attacker (against its will :). CoT messages = might clash, and if the MN moves away, the MR might keep the CN binding = improperly 1b) MNN has an SA with CN For instance, CN is a VPN entry point for MNN, and MNN handles its own = IPSEC. Manipulating packets on the fly will cause them to be dropped. 1c) Snooping for CoT MR has to snoop packets to the MNN in order to find CoT. This defeats = the very purpose of the test (collocation). So if the test is improved = in some future, it might not work anymore. And it's pretty dirty, = reading someone else's packets, isn't it :) ? 1d) modifying packets on the fly Too bad MIP RO to CN is based on Home addr option as opposed to = tunnels, which does not seem to be an option. The MR has to match source = AND destination in order to find whether it can do RO to the CN. And = then it has to insert the option, which might be a painful operation = (apparently more costly then tunnelling, which is already hardware = assisted in some boxes).=20 In short, it is going to be software routed for quite some time. 2) CoA Getting the CoA from the TOP has also been discussed in the ML. As you = point out, there are approaches based on PD, like = draft-leekj-nemo-ro-pd-02.txt but also = draft-droms-nemo-dhcpv6-pd-01.txt. There's also, closer to your = proposal, a proxy ND based proposal draft-jeong-nemo-ro-ndproxy-02.txt . = See = http://www-users.cs.umn.edu/~jjeong/publications/international-conference= /vtc2004-spring-jaehoon.pdf as well. I like that proposal a lot, but we = must be clear on the use case. We discussed that some time ago on the = list as well, but I could not dig out the link. The potential issue I see for both approaches is due to the "proxy" = states in the network (and this is why RRH uses source routing as = opposed to transparent): 2a) If the nested structure moves as a whole, it's neat. If it's all = swarming then the proxy states are all wrong all the time and the = packets do not make it through. So the issue is the resilience to = movement. It seems that when the tree grows deeper, or when the inner or = in/out movement get more and more important, the chances to reach a node = drop rapidly. =20 > > > > > It seems preferable, for instance, to establish a MR-CR tunnel and = exchange fine grained > routes for MNPs over the tunnel (route projection). > > > > I think I agree on this. >=20 > This is, IMHO, a different approach, in which the RO requires some > support from the routing infrastructure, and that present some > advantages. But, OTOH, solutions based on MR-CN RO are also = interesting > IMHO, as an approach that does not require support in the routing > infrastructure and puts the RO support functionality only in the = edges, > i.e. the CN and the MR (if the transparency to the MNNs is required, = the > MR is the other edge in which RO mechanisms can be added). >=20 > What do you think? >=20 Right. It would be very nice if you can keep the ML aware of your = progress. This solution seems very representative of the MR-CN solution = space. Simulating and testing should demonstrate the expected benefits of the = approach, but also show what the limits are in terms of performance in = the MR, scalability in the mobile cloud, and resilience to the relative = movements within the nested NEMO. Note that RRH allows MNN-CN RO, but it's not documented too much and the = solution is not finalized at all; but as opposed to your requirements, = it would require a change to the MNN and the CN to get there. The idea = is that the MNN would insert an RRH with all slots blank. Pascal From nemo-bounces@ietf.org Tue Oct 19 22:42:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18944 for ; Tue, 19 Oct 2004 22:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4dk-00042J-0Q; Tue, 19 Oct 2004 20:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJxUG-0005jN-DL for nemo@megatron.ietf.org; Tue, 19 Oct 2004 13:09:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17311 for ; Tue, 19 Oct 2004 13:09:19 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJxgO-0003cZ-Hl for nemo@ietf.org; Tue, 19 Oct 2004 13:22:01 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id E60412F36D; Tue, 19 Oct 2004 19:08:49 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 0AEC62F2A0; Tue, 19 Oct 2004 19:08:45 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC30859B@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC30859B@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8CC5DA47-21F1-11D9-AF09-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: About RRH security (was Re: [nemo] RE: RO between MR and CN Date: Tue, 19 Oct 2004 19:08:51 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: nemo WG , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Pascal, El 19/10/2004, a las 10:02, Pascal Thubert (pthubert) escribi=F3: > > > If I understand your point, the problem is the time shifting attack=20 > has consequences even when the attacker is gone, at least till the=20 > next RRH. The draft does not mention how often RRH are sent and what=20= > triggers them. > Perfect summary, indeed > Note that in this case, and as opposed to MIP RO, the L4 ACKs are=20 > still protected because there is an SA. But data packets only MAY be protected by IPSec, it is not a MUST,=20 right? So perhaps data packets will flow in clear text, in which case the=20 attacker can see al the traffic am i missing your point? > So redirecting packets like this would be equivalent to destroying=20 > them, and then the flows tarish. But you can not make that a bombing=20= > attack. Since the guy in on the path, it's easier for him to just=20 > destroy the packets. And once he's gone, he can not reuse any token he=20= > got while he was in to maintain the attack. > > Our implementation has a number of heuristics to decide when to roam=20= > and when to send RRH. And I guess there could be many more that could=20= > make a difference on the marketplace while still maintaining=20 > interoperability. agree > MIP does not tell you when to roam. The RRH draft does not tell you=20= > when to send RH4's as opposed to RH3's. But as you suggest, explaining=20= > that issue and giving directions could be very useful. > But the point here is that if the RRH refresh is not done soon enough,=20= there may be security implications. I mean, those heuristics not only=20 have performance concequences but security implications > The lack of traffic back might be a trigger, to, like, send RRH first,=20= > and if it's still no good, move to another AR. The bandwidth you get=20= > (back and forth) is more often then not the key to movement. When you=20= > have IPSEC, an unknown access with a lot of bandwidth might be a=20 > better choice then a safe access that's very benevolent and very slow=20= > ... like a modem. > >> >> Now MIPv6 prevents this type of attacks by limiting BCE lifetime to 7 >> minutes. The problem here is that the BCE lifetime may be higher >> because the BU that has created it was protected with an IPSec SA. >> >> The result of this attack is that an attacker may be on the path for >> just a moment and launch an attack that last for a period T (which = may >> be very long) >> >> AFAICT the draft does not consider this explicitely, in particular it >> doesn't defines values for T. >> Please note that sending the RRH in every packet doesn't really >> protects against this attacks, since for instance unidirectional = flows >> comming from the HA to the MR would still be susceptible to this type >> of attacks. > > Again, the lack of incoming traffic can trigger a RRH. Yes, my point is that you probably want to do it more often in some=20 cases to prevent time shifted attacks, (even if you are not moving) > A BU can be used to convey it in the absence of traffic. The question=20= > is when you have a malevolent guy on your path, he can easily kill=20 > your traffic by just scrambling the radio waves of dropping packets.=20= > The problem you raise, as I understand it, is to avoid lasting effects=20= > when the bad guy is gone. yes > Again, this is not MIP RO where the bad guy is an intruder close to=20= > the CN that attacks and goes. Here, the "bad guy" might stay there.=20 > You might even be visiting him. It's not only a question of adding a=20= > RRH but also a question of detecting a situation and moving away. > well, perhaps this is more ambicious... I guess that an initial approach would be to avoid time shifting=20 attacks. I mean, if our security goal is simply to be as good as fixed IPv6,=20 this is good enough imho > >> My suggestion would be to limit the lifetime of the information >> obtained from the RRH to 7 minutes, the same that the BCE information >> obtained through the RR procedure. >> >> >> Comments? > Thanks a lot for you point. I'll try some text and submit it to you,=20= > unless you wish to propose something? > I don't feel that i understand all the elements involved in the=20 heuristics to write something, but i would be glad to provide feedback=20= on the text > In our implementation, RRH is sent much more often then every 7mn good, but probably some lower bound for the frequency should be defined=20= i guess. Regards, marcelo > and it's configurable by the user. We also have an exponential=20 > backoff. > And like I said, there's more to it. Maybe we should start a=20 > reflection on roaming heuristics when you're in un-trusted=20 > territories, what happens if there's r rogue on the way, how MR/MNs=20 > react to fluctuating bandwidth (back and forth) etc... Obviously this=20= > is beyond the RRH draft... > > Pascal > > > > > > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Wed Oct 20 00:31:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25983 for ; Wed, 20 Oct 2004 00:31:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4jl-0005Zu-K2; Tue, 19 Oct 2004 20:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0qo-0004d1-8S for nemo@megatron.ietf.org; Tue, 19 Oct 2004 16:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11697 for ; Tue, 19 Oct 2004 16:44:55 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK131-00022S-A5 for nemo@ietf.org; Tue, 19 Oct 2004 16:57:38 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 63E026246; Tue, 19 Oct 2004 13:43:39 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74685-07; Tue, 19 Oct 2004 13:43:38 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 7575A6245; Tue, 19 Oct 2004 13:43:38 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 7F40A6226; Tue, 19 Oct 2004 13:43:36 -0700 (PDT) In-Reply-To: <41753E99.9030007@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> <41753E99.9030007@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] New draft on prefix delegation Date: Tue, 19 Oct 2004 13:44:34 -0700 To: Alexandru Petrescu X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit The reason why we wrote this draft are: 1) We want a way for the MR to signal to the HA that it wants either (a) a transient prefix to be used for the lifetime of its binding, similar to how DHCP would hand out an address, or (b) for a persistent prefix to be provisioned at the HA, which the MR can then use for subsequent bindings as well. 2) We thought that doing a NEMO-based flow might save on messages, and might also give more information and status codes that wouldn't be relevant for DHCP. 3) DHCPv6 could be used, but might not be present or implemented in all deployments, so this would offer a way to do allocation and delegation without necessitating DHCP. 4) We thought that it would not be very difficult to integrate this type of solution with a DHCPv6-based solution at the router/HA part. -TJ From nemo-bounces@ietf.org Wed Oct 20 02:54:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05229 for ; Wed, 20 Oct 2004 02:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK94S-0007F2-Hj; Wed, 20 Oct 2004 01:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5eG-0006Po-DC for nemo@megatron.ietf.org; Tue, 19 Oct 2004 21:52:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14503 for ; Tue, 19 Oct 2004 21:52:13 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5qT-0002q1-U6 for nemo@ietf.org; Tue, 19 Oct 2004 22:04:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9K1OJC19563; Tue, 19 Oct 2004 18:24:19 -0700 X-mProtect: <200410200124> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdABEF17; Tue, 19 Oct 2004 18:24:18 PDT Message-ID: <4175C7C3.70407@iprg.nokia.com> Date: Tue, 19 Oct 2004 19:04:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] New draft on prefix delegation References: <41751006.4090005@motorola.com> In-Reply-To: <41751006.4090005@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "T.J.Kniveton" , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Finally, my oppinion is that the method used by the MIP6 WG to assign a > Home Address to MN should be used by NEMO too, for prefixes. That is, > if MIP6 MN generates the Home Address from DHAAD+MPD then NEMO should do > MNP from MPD. If MIP6 assigns the Home Address from DHCP, then NEMO > should do MNP from DHCP too. Same with BU/BAck. there was such a draft proposed in March 2003 extending the Mobile Prefix discovery mechanism to delegate prefixes for the Mobile Router. see http://www.mobilenetworks.org/nemo/drafts/draft-paakkonen-nemo-prefix-delegation-00.txt at that time, the NEMO WG rejected the draft saying that we already have a mechanism through DHCPv6. Vijay From nemo-bounces@ietf.org Wed Oct 20 03:32:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07533 for ; Wed, 20 Oct 2004 03:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9J1-0003Vm-9R; Wed, 20 Oct 2004 01:46:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6GP-0006EM-6U for nemo@megatron.ietf.org; Tue, 19 Oct 2004 22:31:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17764 for ; Tue, 19 Oct 2004 22:31:42 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Sh-0003oa-7j for nemo@ietf.org; Tue, 19 Oct 2004 22:44:29 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9K2SO7R023921; Wed, 20 Oct 2004 10:28:24 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id F3141B240CF; Wed, 20 Oct 2004 10:34:29 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-TC5emotqnVFpESvR8nDZ" Organization: Panasonic Singapore Laboratories Message-Id: <1098239668.9236.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 10:34:29 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Alexandru Petrescu Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-TC5emotqnVFpESvR8nDZ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Alex & all, As I have mentioned earlier in the thread on RO Taxonomy Draft, I was thinking about the issue of return routability procedure when applied in NEMO. Well, the thought process manifest itself into a draft for your reading pleasure, information of which you can find in the forwarded announcement below. One thing I like to highlight is that this draft is NOT a route optimization solution. I view it as identifying a potential security problem of NEMO-RO, and then proposing a mechanism to address this problem. This mechanism may be incorporated in future NEMO Extended Support should there be a need. As always, comments, criticism, suggestions welcomed (regardless of harsh or not :)). Thanks. /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ng-nemo-rrnp-00.txt Date: Tue, 19 Oct 2004 07:47:00 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending Return Routability Procedure for Network Prefix (RRNP) Author(s) : C. Ng, J. Hirano Filename : draft-ng-nemo-rrnp-00.txt Pages : 24 Date : 2004-10-18 This memo highlights the inadequacy of existing return routability procedure when one takes network prefix into consideration under the context of route optimization with Network Mobility (NEMO). An extended return routability procedure, called Return Routability with Network Prefix (RRNP), is thus proposed to address this problem. With RRNP, a correspondent node can verify the collocation of care-of address, home address, and network prefix(es) specified in a binding update message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ng-nemo-rrnp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-10-18172904.I-D@ietf.org> ________________________________________________________________________ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-TC5emotqnVFpESvR8nDZ Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-18172904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt --=-TC5emotqnVFpESvR8nDZ Content-Type: Message/External-body; name="draft-ng-nemo-rrnp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-18172904.I-D@ietf.org> --=-TC5emotqnVFpESvR8nDZ-- From nemo-bounces@ietf.org Wed Oct 20 03:37:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07827 for ; Wed, 20 Oct 2004 03:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Kw-0004dd-4n; Wed, 20 Oct 2004 01:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6nX-0002Ka-EG for nemo@megatron.ietf.org; Tue, 19 Oct 2004 23:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20429 for ; Tue, 19 Oct 2004 23:05:51 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6zk-0004W9-H3 for nemo@ietf.org; Tue, 19 Oct 2004 23:18:38 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9K32bp7025307 for ; Wed, 20 Oct 2004 11:02:37 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 8CD8FB240CF for ; Wed, 20 Oct 2004 11:08:43 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1098241723.9238.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 11:08:43 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [nemo] Issues List on Multihoming Issues X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello all, Like to announce the availability of an issue list for NEMO multihoming issues draft at the following URL: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ We will be working on the 01 version of the draft to close as much of these issues as possible. Meanwhile, input from the WG will definitely be helpful and welcomed. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 20 04:14:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09176 for ; Wed, 20 Oct 2004 04:14:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKACW-0004nW-42; Wed, 20 Oct 2004 02:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK8t8-0005uk-7w for nemo@megatron.ietf.org; Wed, 20 Oct 2004 01:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29920 for ; Wed, 20 Oct 2004 01:19:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK95L-0007QX-Jy for nemo@ietf.org; Wed, 20 Oct 2004 01:32:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9K4pvh19484; Tue, 19 Oct 2004 21:51:57 -0700 X-mProtect: <200410200451> Nokia Silicon Valley Messaging Protection Received: from danira-pool05052.americas.nokia.com (10.241.50.52, claiming to be "[10.241.50.52]") by darkstar.iprg.nokia.com smtpdhwkSIb; Tue, 19 Oct 2004 21:51:56 PDT Message-ID: <4175F543.2060809@iprg.nokia.com> Date: Tue, 19 Oct 2004 22:18:59 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] New draft on prefix delegation References: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> <41753E99.9030007@motorola.com> In-Reply-To: <41753E99.9030007@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > >>> Other methods could be DHCP, and even piggybacking with Mobile Prefix >>> Discovery or with Dynamic Home Agent Address Discovery, etc. >>> I'm tempted to favor DHCP, see below. >>> >> You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever. >> In fact, it's a WG doc. > > > You mean draft-droms-nemo-dhcpv6-pd-01.txt is a WG item? There are > aspects in that draft that are not necessary in order to delegate > prefixes from HA to MR (Tree Options, MR obtaining a prefix from AR, etc.) I agree. Vijay From nemo-bounces@ietf.org Wed Oct 20 07:58:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25408 for ; Wed, 20 Oct 2004 07:58:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEJN-0006ob-Eu; Wed, 20 Oct 2004 07:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDhA-0007X0-7T for nemo@megatron.ietf.org; Wed, 20 Oct 2004 06:27:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17645 for ; Wed, 20 Oct 2004 06:27:44 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDtS-0004wH-Fe for nemo@ietf.org; Wed, 20 Oct 2004 06:40:35 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i9KAKBVF012293; Wed, 20 Oct 2004 03:20:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9KAJbtD023121; Wed, 20 Oct 2004 05:19:38 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 440EF88CF7C; Wed, 20 Oct 2004 12:27:37 +0200 (CEST) Message-ID: <41763D93.1000109@motorola.com> Date: Wed, 20 Oct 2004 12:27:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] New draft on prefix delegation References: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig43031071662C151D6E2B175B" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig43031071662C151D6E2B175B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> I personally would go for an entirely DHCP-based solution. >> Allocating and freeing prefixes (and addresses) is usually large >> programs, risky to run in the kernel space. HA is usually in >> kernel, DHCP server in app space. Exceptions there are to this, ok, >> but still. > > You mean, it's easier for the MR then for the HA to be a DHCP client? I just meant that address/prefix allocation and keeping track of them is usually complex software with large data structures, pertaining to run in userspace, as UDP application level, something that a DHCP Server does. And not intended to run in the kernel space, where a HA usually runs. I didn't mean that either MR or HA is easier to be a DHCP Client. >> An additional advantage of DHCP is reusing the complex management >> software that a DHCP does for addresses (allocate, free, >> re-allocate, manage fragmentation), etc. HA has no such >> functionality that could be reused. > > Right. The right choice depends a lot on the provisioning. If choice > there is :) "Provisioning"? Alex --------------enig43031071662C151D6E2B175B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdj2ZMmC0w56zj54RAnY1AJ4sbSvcuXlGWrIRtpXVrjOxzQ3PlwCdGWHh zpzb/5V2ele0Bw0PbfnGNe0= =S+cg -----END PGP SIGNATURE----- --------------enig43031071662C151D6E2B175B-- From nemo-bounces@ietf.org Wed Oct 20 08:42:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28255 for ; Wed, 20 Oct 2004 08:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEwH-0006gW-86; Wed, 20 Oct 2004 07:47:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDjt-0000Wm-UR for nemo@megatron.ietf.org; Wed, 20 Oct 2004 06:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17897 for ; Wed, 20 Oct 2004 06:30:33 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDwB-0004zi-VD for nemo@ietf.org; Wed, 20 Oct 2004 06:43:25 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 12:10:27 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9K9t4Sj020109; Wed, 20 Oct 2004 11:55:09 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 11:55:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] New draft on prefix delegation Date: Wed, 20 Oct 2004 11:54:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3089D9@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] New draft on prefix delegation Thread-Index: AcS2fmDek7IzTkb6QseubhtAGNdtngACYtSQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Alexandru Petrescu" X-OriginalArrivalTime: 20 Oct 2004 09:55:06.0641 (UTC) FILETIME=[E0CBC810:01C4B68A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Sorry for being unclear: My understanding was to base the WG doc on the initial (00) draft by Ralph. The LMM solution that was added in 01 will be taken out as far as I understand. Does not mean it's not a good solution, but it addresses a different topic. So we split. The MR to HA PD becomes the WG doc, and the LMM stays in the author-named doc. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vijay Devarapalli > Sent: mercredi 20 octobre 2004 07:19 > To: Alexandru Petrescu > Cc: IETF NEMO WG; Pascal Thubert (pthubert); T.J.Kniveton > Subject: Re: [nemo] New draft on prefix delegation >=20 > Alexandru Petrescu wrote: > > Pascal Thubert (pthubert) wrote: > > > >>> Other methods could be DHCP, and even piggybacking with Mobile Prefix > >>> Discovery or with Dynamic Home Agent Address Discovery, etc. > >>> I'm tempted to favor DHCP, see below. > >>> > >> You mean DHCPv6PD right? Well, Ralph's draft is more valid then ever. > >> In fact, it's a WG doc. > > > > > > You mean draft-droms-nemo-dhcpv6-pd-01.txt is a WG item? There are > > aspects in that draft that are not necessary in order to delegate > > prefixes from HA to MR (Tree Options, MR obtaining a prefix from AR, etc.) >=20 > I agree. >=20 > Vijay From nemo-bounces@ietf.org Wed Oct 20 08:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28391 for ; Wed, 20 Oct 2004 08:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF0A-0007Vq-5y; Wed, 20 Oct 2004 07:51:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDoo-0001i9-4l for nemo@megatron.ietf.org; Wed, 20 Oct 2004 06:35:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18706 for ; Wed, 20 Oct 2004 06:35:38 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKE17-0005Au-F0 for nemo@ietf.org; Wed, 20 Oct 2004 06:48:29 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9KAb0G2010918; Wed, 20 Oct 2004 03:37:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9KAZZXO024804; Wed, 20 Oct 2004 05:35:36 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 784E988CF7C; Wed, 20 Oct 2004 12:35:35 +0200 (CEST) Message-ID: <41763F72.3010603@motorola.com> Date: Wed, 20 Oct 2004 12:35:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J.Kniveton" Subject: Re: [nemo] New draft on prefix delegation References: <7892795E1A87F04CADFCCF41FADD00FC308804@xmb-ams-337.emea.cisco.com> <41753E99.9030007@motorola.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF38CA908767AB3AA9260958B" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF38CA908767AB3AA9260958B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit T.J.Kniveton wrote: > The reason why we wrote this draft are: > > 1) We want a way for the MR to signal to the HA that it wants either > (a) a transient prefix to be used for the lifetime of its binding, > similar to how DHCP would hand out an address, or (b) for a > persistent prefix to be provisioned at the HA, which the MR can then > use for subsequent bindings as well. TJ, a "transient" concept goes against the "continuity" concept of Mobile IPv6. An MR would not be interested in "transient" prefixes because that gives "transient" Home Addresses to LFN, meaning interrupting communications when changing the prefix. Or otherwise, did you also think about binding the "transient" prefix to the "persistent" prefix? (Care-of Prefix and Home Prefix). > 2) We thought that doing a NEMO-based flow might save on messages, > and might also give more information and status codes that wouldn't > be relevant for DHCP. This may be true. DHCP exchange is usually 4 message exchange, BU/BAck is only 2. DHCP provides discovery, while BU/BAck no. I doubt there's no room for extension in DHCP messages though, to support MNP-delegation related parameters. > 3) DHCPv6 could be used, but might not be present or implemented in > all deployments, so this would offer a way to do allocation and > delegation without necessitating DHCP. This may be true, but the modularity concepts suggest to use a simple tool for such task: Mobile IPv6 for continuity, DHCP for allocation, etc. > 4) We thought that it would not be very difficult to integrate this > type of solution with a DHCPv6-based solution at the router/HA part. Ok. Alex --------------enigF38CA908767AB3AA9260958B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdj93MmC0w56zj54RAgj4AJ4kelxwKnahCsAa3+WorV/97Y5PCQCgviiy W7VcKhNSi0MB2/+luoZSoyY= =LTXU -----END PGP SIGNATURE----- --------------enigF38CA908767AB3AA9260958B-- From nemo-bounces@ietf.org Wed Oct 20 09:05:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00661 for ; Wed, 20 Oct 2004 09:05:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFTd-0004bq-D8; Wed, 20 Oct 2004 08:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKElf-0003hf-V0 for nemo@megatron.ietf.org; Wed, 20 Oct 2004 07:36:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23869 for ; Wed, 20 Oct 2004 07:36:29 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKExy-0006Xd-DH for nemo@ietf.org; Wed, 20 Oct 2004 07:49:20 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 9EFD22F567; Wed, 20 Oct 2004 13:35:56 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id A9B812F567; Wed, 20 Oct 2004 13:35:54 +0200 (CEST) Subject: RE: [nemo] RE: RO between MR and CN From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RkWIt/KIcDYNkEweoRBJ" Organization: Universidad Carlos III de Madrid Message-Id: <1098272191.2476.122.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 13:36:32 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: nemo@ietf.org, =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Masafumi Watari X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-RkWIt/KIcDYNkEweoRBJ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Pascal, First, thank you very much for the feedback and comments, we really appreciate so much them. Please, see the comments in-line, El mar, 19-10-2004 a las 18:57, Pascal Thubert (pthubert) escribi=F3:=20 > Hi Carlos :) >=20 > Is the MIRON document already published in a final form or does it make s= ense to provide feed back for lower interest things like typos? For the tim= e being, let me discuss concepts. It is already published, so I'm afraid the typos cannot be fixed :-( > > > Hi, > > > > > > On Wed, 13 Oct 2004 13:34:06 +0200, > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > Hi Tania > > > > > > > > I was thinking things like of snooping. MR might intercept all pack= ets to LFN, recognize > > a HoT and keep it. I remember discussing that with Alex long ago... Any= way, we try to say > > "don't take that path" as opposed to describe a solution in details. > > > > > > I don't think its possible to provide RO while keeping the RR functio= n > > > of MIPv6 untouched. It would probably require modification of the > > > packet at MR to use the HoA opt and the routing header for every > > > packet, if we want to keep the MIPv6 spec as is. > >=20 > > Yes, one possible solution is the MR performing all the RR and RO > > signalling on behalf of the LFNs of the NEMO, in order to provide RO fo= r > > LFNs that are communicating to CNs outside the NEMO. This is actually > > the solution we have proposed in MIRON (see my previous e-mail if you > > want a pointer to it), so the MR, as you said, has to process the > > packets sent/received by a LFN in order to insert HoA DO/remove RH. I > > agree that it could have some performance concerns if the process is > > performed to every LFN-CN "flow", but as we have already discussed in a > > previous thread, some mechanism should be used to perform the RO in a > > reasonable way. >=20 > There are 2 aspects to the proposal, even if (like ORC) it's packaged as = one. The first aspect is the proxying for the MNN. The second is obtaining = a topologically correct CoA via DHCP. >=20 > 1) proxying >=20 > As we say in this thread, we discussed that on the ML, at least Alex and = I, and there are some identified protential problems to the approach (that = might be worth more text in the taxonomy?) that you might have to deal with= : >=20 > 1a) MNN is VMN > If the MNN is a visitor that handles its own mobility and RO, the MR mig= ht in fact act as an attacker (against its will :). CoT messages might clas= h, and if the MN moves away, the MR might keep the CN binding improperly This part of the solution ("proxying") is only intended to LFNs, as it's stated on the document. > 1b) MNN has an SA with CN > For instance, CN is a VPN entry point for MNN, and MNN handles its own I= PSEC. Manipulating packets on the fly will cause them to be dropped. Agree. We are aware of that. Maybe it is not clearly stated in the doc, but of course if end-to-end IPSec is used, this part of the solution cannot be applied. > 1c) Snooping for CoT > MR has to snoop packets to the MNN in order to find CoT. This defeats th= e very purpose of the test (collocation). So if the test is improved in som= e future, it might not work anymore. And it's pretty dirty, reading someone= else's packets, isn't it :) ? I agree that if RR is changed in the future, our solution may not work. Nevertheless, we proposed this, as you call "dirty" solution, just because we didn't want to change RR (one of our main goals is to propose a solution that does not require changes to deployed protocols and nodes, i.e. MIPv6 MNs and CNs). I agree that reading someone else's packets is not the ideal solution, but OTOH, if you don't want your packets to be read, you use IPSEC. Besides, if you don't use IPSEC, your router (or someone in the path) can read your packets anyway. > 1d) modifying packets on the fly > Too bad MIP RO to CN is based on Home addr option as opposed to tunnels,= which does not seem to be an option. The MR has to match source AND destin= ation in order to find whether it can do RO to the CN. And then it has to i= nsert the option, which might be a painful operation (apparently more costl= y then tunnelling, which is already hardware assisted in some boxes).=20 > In short, it is going to be software routed for quite some time. Well, as some other solutions proposed so far, this solution is not intended to be used with _every_packet routed by the MR. There are many flows that are not worth to be "MIRON-processed" ;-) (e.g. DNS, etc). Some heuristics have to be defined to make the decision about which "LFN-CN" flows should be optimised and which not. > 2) CoA >=20 > Getting the CoA from the TOP has also been discussed in the ML. As you po= int out, there are approaches based on PD, like draft-leekj-nemo-ro-pd-02.t= xt but also draft-droms-nemo-dhcpv6-pd-01.txt. There's also, closer to your= proposal, a proxy ND based proposal draft-jeong-nemo-ro-ndproxy-02.txt . S= ee http://www-users.cs.umn.edu/~jjeong/publications/international-conferenc= e/vtc2004-spring-jaehoon.pdf as well. I like that proposal a lot, but we mu= st be clear on the use case. We discussed that some time ago on the list as= well, but I could not dig out the link. >=20 > The potential issue I see for both approaches is due to the "proxy" state= s in the network (and this is why RRH uses source routing as opposed to tra= nsparent): >=20 > 2a) If the nested structure moves as a whole, it's neat. If it's all swar= ming then the proxy states are all wrong all the time and the packets do no= t make it through. So the issue is the resilience to movement. It seems tha= t when the tree grows deeper, or when the inner or in/out movement get more= and more important, the chances to reach a node drop rapidly. Well, we are simulating now our solution in order to check this an other issues we have detected so far. OTOH, IMHO that is not such a big problem, if a nested tree moves, root-MR detects the movement, and the it can inform the other MR using DHCPv6 (DHCPv6 supports sending information from the server to clients). The new addresses would be propagated to the MRs within the nested tree and then every MR would be able to send the appropriate BU. > =20 >=20 > > > > > > > It seems preferable, for instance, to establish a MR-CR tunnel and = exchange fine grained > > routes for MNPs over the tunnel (route projection). > > > > > > I think I agree on this. > >=20 > > This is, IMHO, a different approach, in which the RO requires some > > support from the routing infrastructure, and that present some > > advantages. But, OTOH, solutions based on MR-CN RO are also interesting > > IMHO, as an approach that does not require support in the routing > > infrastructure and puts the RO support functionality only in the edges, > > i.e. the CN and the MR (if the transparency to the MNNs is required, th= e > > MR is the other edge in which RO mechanisms can be added). > >=20 > > What do you think? > >=20 >=20 > Right. It would be very nice if you can keep the ML aware of your progres= s. This solution seems very representative of the MR-CN solution space. Actually, we were thinking in submitting a revised version of MIRON to the WG formatted as an I-D to further discussion, but we were waiting to have some more simulation results and we were also waiting to the possible recharter of the WG to focus on RO solutions. > Simulating and testing should demonstrate the expected benefits of the ap= proach, but also show what the limits are in terms of performance in the MR= , scalability in the mobile cloud, and resilience to the relative movement= s within the nested NEMO. Agree. Actually, we are now working on that. > Note that RRH allows MNN-CN RO, but it's not documented too much and the = solution is not finalized at all; but as opposed to your requirements, it w= ould require a change to the MNN and the CN to get there. The idea is that = the MNN would insert an RRH with all slots blank. That's also interesting. The problem, IMHO, is that it would break the CN and MNN transparency. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-RkWIt/KIcDYNkEweoRBJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBdk2/5vKyPtrWqkARAnxCAJ9xZFdIYHry5HRodxc7yKqTdC9cLQCghUcj ESIRbi631AtgxaF8uRAF0Xk= =FLkX -----END PGP SIGNATURE----- --=-RkWIt/KIcDYNkEweoRBJ-- From nemo-bounces@ietf.org Wed Oct 20 10:25:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07664 for ; Wed, 20 Oct 2004 10:25:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGZY-0003ym-TP; Wed, 20 Oct 2004 09:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFxA-0002en-Bc for nemo@megatron.ietf.org; Wed, 20 Oct 2004 08:52:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29069 for ; Wed, 20 Oct 2004 08:52:25 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG9T-0008BJ-JQ for nemo@ietf.org; Wed, 20 Oct 2004 09:05:16 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 15:07:09 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KCpfSn029323; Wed, 20 Oct 2004 14:51:50 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 14:51:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] New draft on prefix delegation Date: Wed, 20 Oct 2004 14:51:40 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344A96@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] New draft on prefix delegation Thread-Index: AcS2cgzSmVQZO1dvQiWrrFcEshWytgAGSmnw From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Alexandru Petrescu" X-OriginalArrivalTime: 20 Oct 2004 12:51:43.0527 (UTC) FILETIME=[8D084370:01C4B6A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Vijay: What they did at the time was pretty different in goals and features than what we propose now. Yet, their work is acknowledged in the draft.=20 You might want to go through the new draft, in particular there is a long and detailed chapter on the Motivation for NEMO prefix delegation. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vijay Devarapalli > Sent: mercredi 20 octobre 2004 04:05 > To: Alexandru Petrescu > Cc: IETF NEMO WG; T.J.Kniveton; Pascal Thubert (pthubert) > Subject: Re: [nemo] New draft on prefix delegation >=20 > Alexandru Petrescu wrote: >=20 > > Finally, my oppinion is that the method used by the MIP6 WG to assign a > > Home Address to MN should be used by NEMO too, for prefixes. That is, > > if MIP6 MN generates the Home Address from DHAAD+MPD then NEMO should do > > MNP from MPD. If MIP6 assigns the Home Address from DHCP, then NEMO > > should do MNP from DHCP too. Same with BU/BAck. >=20 > there was such a draft proposed in March 2003 extending the Mobile > Prefix discovery mechanism to delegate prefixes for the Mobile Router. > see > http://www.mobilenetworks.org/nemo/drafts/draft-paakkonen-nemo-prefix-de legation-00.txt >=20 > at that time, the NEMO WG rejected the draft saying that we already > have a mechanism through DHCPv6. >=20 > Vijay From nemo-bounces@ietf.org Wed Oct 20 10:39:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10372 for ; Wed, 20 Oct 2004 10:39:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGm7-00076L-JT; Wed, 20 Oct 2004 09:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGF8-0005Wf-8i for nemo@megatron.ietf.org; Wed, 20 Oct 2004 09:11:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00940 for ; Wed, 20 Oct 2004 09:10:59 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGRQ-0000Bt-Pi for nemo@ietf.org; Wed, 20 Oct 2004 09:23:51 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 15:25:42 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KDANSf002751; Wed, 20 Oct 2004 15:10:24 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 15:00:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] New draft on prefix delegation Date: Wed, 20 Oct 2004 15:00:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344A9F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] New draft on prefix delegation Thread-Index: AcS2kJ0M8SiLaHOfTkG0om5DpyoE+AAEznew From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "T.J.Kniveton" X-OriginalArrivalTime: 20 Oct 2004 13:00:22.0717 (UTC) FILETIME=[C27E5ED0:01C4B6A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: mercredi 20 octobre 2004 12:36 > To: T.J.Kniveton > Cc: Pascal Thubert (pthubert); IETF NEMO WG > Subject: Re: [nemo] New draft on prefix delegation >=20 > T.J.Kniveton wrote: > > The reason why we wrote this draft are: > > > > 1) We want a way for the MR to signal to the HA that it wants either > > (a) a transient prefix to be used for the lifetime of its binding, > > similar to how DHCP would hand out an address, or (b) for a > > persistent prefix to be provisioned at the HA, which the MR can then > > use for subsequent bindings as well. >=20 > TJ, a "transient" concept goes against the "continuity" concept of > Mobile IPv6. An MR would not be interested in "transient" prefixes > because that gives "transient" Home Addresses to LFN, meaning > interrupting communications when changing the prefix. Or otherwise, did > you also think about binding the "transient" prefix to the "persistent" > prefix? (Care-of Prefix and Home Prefix). Right: one application of the transient prefix is the local mobility management as detailed in draft-droms-nemo-dhcpv6-pd-01.txt=20 >=20 > > 2) We thought that doing a NEMO-based flow might save on messages, > > and might also give more information and status codes that wouldn't > > be relevant for DHCP. >=20 > This may be true. DHCP exchange is usually 4 message exchange, BU/BAck > is only 2. DHCP provides discovery, while BU/BAck no. I doubt there's > no room for extension in DHCP messages though, to support MNP-delegation > related parameters. >=20 > > 3) DHCPv6 could be used, but might not be present or implemented in > > all deployments, so this would offer a way to do allocation and > > delegation without necessitating DHCP. >=20 > This may be true, but the modularity concepts suggest to use a simple > tool for such task: Mobile IPv6 for continuity, DHCP for allocation, etc. Allocation might be done by a provisioning system as opposed to a DHCP server. Pascal From nemo-bounces@ietf.org Wed Oct 20 17:07:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26568 for ; Wed, 20 Oct 2004 17:07:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIGc-0003cQ-Ob; Wed, 20 Oct 2004 11:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHZF-0008T3-ET for nemo@megatron.ietf.org; Wed, 20 Oct 2004 10:35:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09969 for ; Wed, 20 Oct 2004 10:35:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHla-0001yA-3h for nemo@ietf.org; Wed, 20 Oct 2004 10:48:42 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 16:50:32 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KEYKSt026616; Wed, 20 Oct 2004 16:35:13 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 16:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: RO between MR and CN Date: Wed, 20 Oct 2004 16:35:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344B18@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: RO between MR and CN Thread-Index: AcS2mR8aXPhngFWQTi6HLOQO4XN7LQADG2Tw From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 20 Oct 2004 14:35:12.0852 (UTC) FILETIME=[02141140:01C4B6B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= , Masafumi Watari X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable , we discussed that on the ML, at least Alex and I, and there are > some identified protential problems to the approach (that might be = worth more text in the > taxonomy?) that you might have to deal with: > > > > 1a) MNN is VMN > > If the MNN is a visitor that handles its own mobility and RO, the = MR might in fact act > as an attacker (against its will :). CoT messages might clash, and if = the MN moves away, the > MR might keep the CN binding improperly >=20 > This part of the solution ("proxying") is only intended to LFNs, as = it's > stated on the document. This is part of the typo part then, the MNN acronym is used sometimes. = The Next question is whether you have to prevent VMNs or if you add an = algorithm to detect those clients for which you do not do RO. Snooping? =20 > > 1b) MNN has an SA with CN > > For instance, CN is a VPN entry point for MNN, and MNN handles its = own IPSEC. > Manipulating packets on the fly will cause them to be dropped. >=20 > Agree. We are aware of that. Maybe it is not clearly stated in the = doc, > but of course if end-to-end IPSec is used, this part of the solution > cannot be applied. Again this require more snooping. Anyway, we found nothing better in the = exploration of solutions that would be transparent to CN and MNN. All = this snooping seems to be the price to pay for the requirements you = took. Note that global HAHA approaches from the other end of the = spectrum. RO is between proxies that belong to the infrastructure and = exchange projected routes over dynamic tunnel (route projection). = Protecting the privacy the CoA from the other end is another requirement = that appears sometimes.=20 There might be different sets of requirements and the requirements end = up orienting the solution quite dramatically. I'm not even sure that the = WG will be able to sort out THE set of requirements with THE order of = priority so that we can devise THE RO solution. It might appear that the = best fit RO solution depends on the type of deployment. We'll see :) >=20 > > 1c) Snooping for CoT > > MR has to snoop packets to the MNN in order to find CoT. This = defeats the very purpose > of the test (collocation). So if the test is improved in some future, = it might not work > anymore. And it's pretty dirty, reading someone else's packets, isn't = it :) ? >=20 >=20 > I agree that if RR is changed in the future, our solution may not = work. > Nevertheless, we proposed this, as you call "dirty" solution, just > because we didn't want to change RR (one of our main goals is to = propose > a solution that does not require changes to deployed protocols and > nodes, i.e. MIPv6 MNs and CNs). > I agree that reading someone else's packets is not the ideal solution, > but OTOH, if you don't want your packets to be read, you use IPSEC. > Besides, if you don't use IPSEC, your router (or someone in the path) > can read your packets anyway. >=20 > > 1d) modifying packets on the fly > > Too bad MIP RO to CN is based on Home addr option as opposed to = tunnels, which does not > seem to be an option. The MR has to match source AND destination in = order to find whether it > can do RO to the CN. And then it has to insert the option, which might = be a painful operation > (apparently more costly then tunnelling, which is already hardware = assisted in some boxes). > > In short, it is going to be software routed for quite some time. >=20 > Well, as some other solutions proposed so far, this solution is not > intended to be used with _every_packet routed by the MR. There are = many > flows that are not worth to be "MIRON-processed" ;-) (e.g. DNS, etc). > Some heuristics have to be defined to make the decision about which > "LFN-CN" flows should be optimised and which not. Sure, that makes sense to me. The point is still that you have to look = up every packet and match both source and destination to see if you have = a proxy binding. This is 1) quite costly in terms of CPU and 2) I'm = afraid that hardware acceleration will not be easy to perform, as = opposed to simple tunnels; same for inserting headers inside the packet. = > > 2) CoA > > > > Getting the CoA from the TOP has also been discussed in the ML. As = you point out, there are > approaches based on PD, like draft-leekj-nemo-ro-pd-02.txt but also = draft-droms-nemo-dhcpv6- > pd-01.txt. There's also, closer to your proposal, a proxy ND based = proposal draft-jeong-nemo- > ro-ndproxy-02.txt . See = http://www-users.cs.umn.edu/~jjeong/publications/international- > conference/vtc2004-spring-jaehoon.pdf as well. I like that proposal a = lot, but we must be > clear on the use case. We discussed that some time ago on the list as = well, but I could not > dig out the link. > > > > The potential issue I see for both approaches is due to the "proxy" = states in the network > (and this is why RRH uses source routing as opposed to transparent): > > > > 2a) If the nested structure moves as a whole, it's neat. If it's all = swarming then the > proxy states are all wrong all the time and the packets do not make it = through. So the issue > is the resilience to movement. It seems that when the tree grows = deeper, or when the inner or > in/out movement get more and more important, the chances to reach a = node drop rapidly. >=20 > Well, we are simulating now our solution in order to check this an = other > issues we have detected so far. OTOH, IMHO that is not such a big > problem, if a nested tree moves, root-MR detects the movement, and the > it can inform the other MR using DHCPv6 (DHCPv6 supports sending > information from the server to clients). The new addresses would be > propagated to the MRs within the nested tree and then every MR would = be > able to send the appropriate BU. >=20 I do not mean it's that bas when the tree moves as a whole; but rather = when each node is independent and moves relatively to other nodes. Think = of MRs in car, wireless APs on the traffic lights and some buildings. = And imagine that to get to the AP, you might needs to hop over one or = two cars, because you are in a shadow area around the block or = something. > > > > > > > > > > > It seems preferable, for instance, to establish a MR-CR tunnel = and exchange fine > grained > > > routes for MNPs over the tunnel (route projection). > > > > > > > > I think I agree on this. > > > > > > This is, IMHO, a different approach, in which the RO requires = some > > > support from the routing infrastructure, and that present some > > > advantages. But, OTOH, solutions based on MR-CN RO are also = interesting > > > IMHO, as an approach that does not require support in the routing > > > infrastructure and puts the RO support functionality only in the = edges, > > > i.e. the CN and the MR (if the transparency to the MNNs is = required, the > > > MR is the other edge in which RO mechanisms can be added). > > > > > > What do you think? > > > > > > > Right. It would be very nice if you can keep the ML aware of your = progress. This solution > seems very representative of the MR-CN solution space. >=20 > Actually, we were thinking in submitting a revised version of MIRON to > the WG formatted as an I-D to further discussion, but we were waiting = to > have some more simulation results and we were also waiting to the > possible recharter of the WG to focus on RO solutions. Cool, please keep us tuned on the simulation results :) >=20 > > Simulating and testing should demonstrate the expected benefits of = the approach, but also > show what the limits are in terms of performance in the MR, = scalability in the mobile cloud, > and resilience to the relative movements within the nested NEMO. >=20 > Agree. Actually, we are now working on that. >=20 > > Note that RRH allows MNN-CN RO, but it's not documented too much and = the solution is not > finalized at all; but as opposed to your requirements, it would = require a change to the MNN > and the CN to get there. The idea is that the MNN would insert an RRH = with all slots blank. >=20 > That's also interesting. The problem, IMHO, is that it would break the > CN and MNN transparency. >=20 You're right. I'm pointing out that there is a world of solutions = depending on what the key reqs are... Pascal From nemo-bounces@ietf.org Wed Oct 20 22:04:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09489 for ; Wed, 20 Oct 2004 22:04:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIR9-0007Gp-EN; Wed, 20 Oct 2004 11:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHmP-00020B-IY; Wed, 20 Oct 2004 10:49:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11434; Wed, 20 Oct 2004 10:49:30 -0400 (EDT) Message-Id: <200410201449.KAA11434@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:49:30 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-mib-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-nemo-mib-00.txt Pages : 36 Date : 2004-10-19 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20105441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105441.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Oct 20 23:14:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18852 for ; Wed, 20 Oct 2004 23:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIdK-00032T-QF; Wed, 20 Oct 2004 11:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKI7d-0007Ju-Pq for nemo@megatron.ietf.org; Wed, 20 Oct 2004 11:11:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13281 for ; Wed, 20 Oct 2004 11:11:22 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIJy-0002hy-Cj for nemo@ietf.org; Wed, 20 Oct 2004 11:24:15 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i9KF7jKq004316; Wed, 20 Oct 2004 08:07:45 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i9KF606I021050; Wed, 20 Oct 2004 10:06:01 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 63B688A358D; Wed, 20 Oct 2004 17:06:16 +0200 (CEST) Message-ID: <41767EE2.5060700@motorola.com> Date: Wed, 20 Oct 2004 17:06:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: provisioning system? (was: [nemo] New draft on prefix delegation) References: <7892795E1A87F04CADFCCF41FADD00FC344A9F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC344A9F@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2F66EADAF5E609ADC320A69" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2F66EADAF5E609ADC320A69 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Allocation might be done by a provisioning system as opposed to a > DHCP server. Sorry for being completely ignorant about "provisioning system", but what is it more exactly? I've searched the RFC's and I found "provisioning" in RFC3730 (EPP: Extensible Provisioning Protocol). Internet Drafts have CAPWAP for Provisioning of Wireless Access Points. Which of those two? (actually none claims to be an alternative to DHCP). Or do you refer to a completely independent MR having no Home and asking for a prefix directly from Registrars? Remark this could be automated as well... Alex --------------enigB2F66EADAF5E609ADC320A69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdn7oMmC0w56zj54RApsnAJ4wD17Kx+rEEJijpeGwXHMWOBlQ0gCg+rWS bHDhSWhidF/Av/s2QIph7AY= =0ua+ -----END PGP SIGNATURE----- --------------enigB2F66EADAF5E609ADC320A69-- From nemo-bounces@ietf.org Thu Oct 21 07:10:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29042 for ; Thu, 21 Oct 2004 07:10:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKMJo-0005PY-S5; Wed, 20 Oct 2004 15:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKICw-0001ND-Si for nemo@megatron.ietf.org; Wed, 20 Oct 2004 11:16:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13725 for ; Wed, 20 Oct 2004 11:16:51 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIPI-0002oO-13 for nemo@ietf.org; Wed, 20 Oct 2004 11:29:45 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4CA6D5D09C; Thu, 21 Oct 2004 00:16:17 +0900 (JST) Date: Thu, 21 Oct 2004 00:13:48 +0900 (JST) Message-Id: <20041021.001348.104124391.watari@sfc.wide.ad.jp> To: cjbc@it.uc3m.es Subject: Re: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt From: Masafumi Watari In-Reply-To: <1098177846.2468.33.camel@acorde> References: <20041015.234051.48485883.watari@sfc.wide.ad.jp> <1098177846.2468.33.camel@acorde> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Carlos, Thank you for your comments. Yes, I agree CR is not the only solution and that the text is somewhat off the focus of the draft. I will remove that. Actually, I was writing a solution draft, but then I changed my mind and forgot to remove it... I will also add some text about the use of CoA for VMNs. Thank you! Masafumi Watari On Tue, 19 Oct 2004 11:24:06 +0200, Carlos Jes=FAs Bernardos Cano wrote: > Dear Masafumi, > = > I think that the draft is useful and helps in the description of the= > problem statement in nested NEMOs, so thanks for providing it. > = > I have a couple of comments. First, in the case A (LFN and standard > IPv6 CN), you say that > = > "To avoid tunneling through any HA, Correspondent Routes (CRs) may b= e > placed near CNs to handle bindings. CRs are routers enhanced which= > the ability to handle bindings for a mobile network, allowing a > direct tunnel to the MR providing a certain level of optimization."= > = > IMHO, CRs are not the only solution that may be used to provide a > certain level of optimisation. There are other solutions, like using > some kind of ad-hoc routing within the nesting, RRH, etc, that can > reduce the number of tunnels to only one. I'd suggest to maintain the= > sentence "Route optimization would require collaboration among the MR= s" > and maybe rewrite the other part to just provide examples, like the o= ne > of CRs and maybe others. = > = > In the case I (VMN and standard IPv6 CN), maybe it's worth IMHO to > point that the VMN could also use its CoA (looking at RFC3775, I thin= k > that it is an implementation dependant behaviour) to some > communications. For example, if a VMN attaches to a NEMO, for > short-lived communications (e.g. DNS requests), it may prefer to use = its > CoA as source address. Therefore, IMHO, I think it would be useful to= > add some text pointing that also. > = > What do you think? > = > Kind Regards, > = > Carlos J. > = > = > El vie, 15-10-2004 a las 16:40, Masafumi Watari escribi=F3: > > Hello, > > = > > I've submitted a draft based on the presentation I made during the = SD > > meeting. Please find the document in the URL below. > > = > > http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.= txt > > = > > I hope that the draft helps the problem statement of Neste NEMO, an= d > > that the solution for RO considers the differenent cases metioned i= n > > the draft. > > = > > Thanks, > > = > > Masafumi Watari > > = > > ___________________________________________________________________= ___ > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-watari-nemo-nested-cn-00.txt > > Date: Thu, 14 Oct 2004 16:19:27 -0400 > > = > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > = > > = > > Title : Route Optimization with Nested Correspondent Nodes > > Author(s) : M. Watari, T. Ernst > > Filename : draft-watari-nemo-nested-cn-00.txt > > Pages : 18 > > Date : 2004-10-14 > > = > > This document aims at assisting the problem statement of route > > optimization in nested mobile networks. We describe the paths > > packets would take using existing Mobile IPv6 and NEMO Basic Sup= port > > mechanisms when one or both end nodes of a communication flow ar= e > > located in a nested NEMO. One of both of the end nodes may > > themselves be either mobile nodes performing Mobile IPv6, or sta= ndard > > IPv6 nodes performing no mobility function at all. The path can= > > become extremely suboptimal if no optimization is provided. > > = > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.= txt > > = > > To remove yourself from the I-D Announcement list, send a message t= o = > > i-d-announce-request@ietf.org with the word unsubscribe in the body= of the message. = > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-annou= nce > > to change your subscription settings. > > = > > = > > Internet-Drafts are also available by anonymous FTP. Login with the= username > > "anonymous" and a password of your e-mail address. After logging in= , > > type "cd internet-drafts" and then > > "get draft-watari-nemo-nested-cn-00.txt". > > = > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > = > > = > > Internet-Drafts can also be obtained by e-mail. > > = > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-watari-nemo-nested-cn-00.txt". > > = > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail reade= rs > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > = > > = > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > = > > ___________________________________________________________________= ___ > > Content-Type: text/plain > > Content-ID: <2004-10-14164528.I-D@ietf.org> > > = > > = > > ___________________________________________________________________= ___ > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > -- = > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Thu Oct 21 07:25:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02468 for ; Thu, 21 Oct 2004 07:25:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKRlJ-0005EL-UE; Wed, 20 Oct 2004 21:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIPw-0006fb-VM for nemo@megatron.ietf.org; Wed, 20 Oct 2004 11:30:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14734 for ; Wed, 20 Oct 2004 11:30:22 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIcM-00035E-UO for nemo@ietf.org; Wed, 20 Oct 2004 11:43:16 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 17:45:09 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KFTCTH011479; Wed, 20 Oct 2004 17:29:49 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 17:29:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: provisioning system? (was: [nemo] New draft on prefix delegation) Date: Wed, 20 Oct 2004 17:29:38 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344B61@xmb-ams-337.emea.cisco.com> Thread-Topic: provisioning system? (was: [nemo] New draft on prefix delegation) Thread-Index: AcS2txFW5UZt+1hERFCUXbVkYIjxMQAAGdMg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Oct 2004 15:29:42.0909 (UTC) FILETIME=[9F2F2AD0:01C4B6B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Alex A provisioning system is the part of the OSS that sets up thing automatically. For instance you reach into such a system when you create an account on a webmail. Some be very very complex.=20 Also, there's a lot of customization (service) to perform in order to adapt a generic product for a service provider. You could try google to get more. For instance, Microsoft has a product called MPS. http://www.microsoft.com/serviceproviders/mps/default.asp In the flow of creating a user account, a provisioning system might have to create derived information such as the configuration of a mobile router. The system might not be able to feed that config into the router transactionally. But it could save the relevant information in a database that the HA could read, eg using diameter or radius. A specific flow is needed when the user's device boots for the first time. This relates to the MIPv6 bootstrap problem. This new draft addresses that problem, amongst others such as implicit config check. Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: mercredi 20 octobre 2004 17:06 > To: Pascal Thubert (pthubert) > Cc: T.J.Kniveton; IETF NEMO WG > Subject: Re: provisioning system? (was: [nemo] New draft on prefix delegation) >=20 > Pascal Thubert (pthubert) wrote: > > Allocation might be done by a provisioning system as opposed to a > > DHCP server. >=20 > Sorry for being completely ignorant about "provisioning system", but > what is it more exactly? I've searched the RFC's and I found > "provisioning" in RFC3730 (EPP: Extensible Provisioning Protocol). > Internet Drafts have CAPWAP for Provisioning of Wireless Access Points. > Which of those two? (actually none claims to be an alternative to DHCP). >=20 > Or do you refer to a completely independent MR having no Home and asking > for a prefix directly from Registrars? Remark this could be automated > as well... >=20 > Alex From nemo-bounces@ietf.org Thu Oct 21 07:30:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03751 for ; Thu, 21 Oct 2004 07:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKTOF-0000gw-Rn; Wed, 20 Oct 2004 23:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKId1-0002dz-BC for nemo@megatron.ietf.org; Wed, 20 Oct 2004 11:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15964 for ; Wed, 20 Oct 2004 11:43:52 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIpS-0003KN-1S for nemo@ietf.org; Wed, 20 Oct 2004 11:56:46 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id EE6B05D106; Thu, 21 Oct 2004 00:43:06 +0900 (JST) Date: Thu, 21 Oct 2004 00:40:38 +0900 (JST) Message-Id: <20041021.004038.78798033.watari@sfc.wide.ad.jp> To: Christophe.Janneteau@motorola.com Subject: Re: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt From: Masafumi Watari In-Reply-To: <41750DF5.2070108@motorola.com> References: <20041015.234051.48485883.watari@sfc.wide.ad.jp> <1098177846.2468.33.camel@acorde> <41750DF5.2070108@motorola.com> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, cjbc@it.uc3m.es X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Christophe, Thank you for your comments. Please see my reply inline; On Tue, 19 Oct 2004 14:52:05 +0200, Christophe Janneteau wrote: > Hi Masafumi, Carlos, > = > Masafumi, thanks for the draft. I think it helps in explaining the = > overhead of the NEMO basic support protocol with nested moving networ= ks. = > Especially, I liked that the many different scenarios (location/typ= e = > of CN and MNN) have been considered. > > Few comments below, somehow inline with Carlos' ones: > = > Carlos Jes=FAs Bernardos Cano wrote: > > I have a couple of comments. First, in the case A (LFN and standar= d > > IPv6 CN), you say that > > = > > "To avoid tunneling through any HA, Correspondent Routes (CRs) may= be > > placed near CNs to handle bindings. CRs are routers enhanced whi= ch > > the ability to handle bindings for a mobile network, allowing a > > direct tunnel to the MR providing a certain level of optimization= ." > > = > > IMHO, CRs are not the only solution that may be used to provide a > > certain level of optimisation. There are other solutions, like usin= g > > some kind of ad-hoc routing within the nesting, RRH, etc, that can > > reduce the number of tunnels to only one. I'd suggest to maintain t= he > > sentence "Route optimization would require collaboration among the = MRs" > > and maybe rewrite the other part to just provide examples, like the= one > > of CRs and maybe others. = > = > I agree that CR is not the only solutions, and I also understand that= it = > is not the objective of the draft to list solutions nor discuss them = in = > details. So, IMHO, I would suggest to remove from the draft any = > references to solutions (such as CR, or others). > = > This would provide a draft focusing _only_ on the issues with the = > current protocols (highlighting the need for RO) but free of any = > solution. Only then, IMHO, the draft could provide the needed = > necessary-unbiased foundations for the problem statement discussion i= n = > the WG. > = > So I would propose to remove the two following paragraphs: > = > o in 2.1: > "Route optimization would require collaboration among the MRs. T= o > avoid tunneling through any HA, Correspondent Routes (CRs) may be= > placed near CNs to handle bindings. CRs are routers enhanced whi= ch > the ability to handle bindings for a mobile network, allowing a > direct tunnel to the MR providing a certain level of optimization= ." > = > o in 3: > "The models generally assumed for route optimization are optimiza= tion > among all MRs in both NEMOs, and a bi-directional tunnel between = the > two root-MRs." I guess my intension was to kind of summerize some general solutions often seen in proposals, but I as mentioned in my previous mail, I will remove these. > Another comment on section 5.3: > - What is the HA4 mentioned in the text? It does not appear in Fig= = > 13, nor in fig 16. It should be VMN_HA. I will fix that. > - Fig.16: the path down to CN seems to be missing in the figure. = > Should it not be like: > = > VMN - MR3 - MR2 - MR1 - MR1_HA - MR2_HA - MR3_HA - VMN_HA - MR3_HA - = > MR2_HA - MR1_HA - MR1 - MR2 - MR3 - CN Yes, correct... I will fix this as well. Thanks again, Masafumi Watari From nemo-bounces@ietf.org Thu Oct 21 07:31:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04110 for ; Thu, 21 Oct 2004 07:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUH1-0005J2-Tq; Thu, 21 Oct 2004 00:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKItp-0001EY-35 for nemo@megatron.ietf.org; Wed, 20 Oct 2004 12:01:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17440 for ; Wed, 20 Oct 2004 12:01:09 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJ68-0003la-Ai for nemo@ietf.org; Wed, 20 Oct 2004 12:14:03 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9KG2QG2026568; Wed, 20 Oct 2004 09:02:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i9KFxqJv019869; Wed, 20 Oct 2004 10:59:52 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CE0EE8A358D; Wed, 20 Oct 2004 18:01:01 +0200 (CEST) Message-ID: <41768BB7.4090809@motorola.com> Date: Wed, 20 Oct 2004 18:00:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: provisioning system? (was: [nemo] New draft on prefix delegation) References: <7892795E1A87F04CADFCCF41FADD00FC344B61@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC344B61@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB89E9CC45243926CF8BA34AF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB89E9CC45243926CF8BA34AF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal, seems to me like you are talking about what was formerly known as ASP Application Service Provider. Although I'm aware of several ASP products I'm not aware of any joint effort to standardize interfaces. Or maybe webservices aka SOAP and XML. But those are completely outside the scope of NEMO. If on the other hand MSP requires prefixes in the BU/BAck then it should be explicitely stated so. Please describe the architecture that MSP assumes. I very well see a NEMO over MSP informational draft. Pascal Thubert (pthubert) wrote: > A provisioning system is the part of the OSS that sets up thing OSS: Open Source Software, Operating System Stack > automatically. For instance you reach into such a system when you > create an account on a webmail. Some be very very complex. Also, > there's a lot of customization (service) to perform in order to adapt > a generic product for a service provider. You could try google to > get more. For instance, Microsoft has a product called MPS. > http://www.microsoft.com/serviceproviders/mps/default.asp > > In the flow of creating a user account, a provisioning system might > have to create derived information such as the configuration of a > mobile router. The system might not be able to feed that config into > the router transactionally. But it could save the relevant > information in a database that the HA could read, eg using diameter > or radius. Do you know whether diameter/radius use DHCP? I guess yes but I'm not sure. > A specific flow is needed when the user's device boots for the first > time. This relates to the MIPv6 bootstrap problem. > > This new draft addresses that problem, amongst others such as > implicit config check. Alex --------------enigB89E9CC45243926CF8BA34AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdou9MmC0w56zj54RAsSzAKCWcaOJA1jSAwWZfHSq66I6pFeuDQCdHoR0 kBZRTNQIsDV8QJ3hQvYvpuA= =mack -----END PGP SIGNATURE----- --------------enigB89E9CC45243926CF8BA34AF-- From nemo-bounces@ietf.org Thu Oct 21 07:35:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04698 for ; Thu, 21 Oct 2004 07:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUHv-0005bS-Mn; Thu, 21 Oct 2004 00:10:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJCa-0007M3-6M for nemo@megatron.ietf.org; Wed, 20 Oct 2004 12:20:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20106 for ; Wed, 20 Oct 2004 12:20:31 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJOv-0004Ck-2P for nemo@ietf.org; Wed, 20 Oct 2004 12:33:26 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A20A85D098; Thu, 21 Oct 2004 01:20:01 +0900 (JST) Date: Thu, 21 Oct 2004 01:17:33 +0900 (JST) Message-Id: <20041021.011733.112532574.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Subject: Re: [nemo] RE: RO between MR and CN From: Masafumi Watari In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, maria@it.uc3m.es, cjbc@it.uc3m.es X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Carlos and Pascal, I find MIRON interesting since I had previously worked on something very similar, what I called, "Binding Proxy Agent (BPA)" to provide RO between MIP6 MN and standard IPv6 CN. Unfortunatelly all my papers are in Japanese so I don't have any refs, but I have presented this at Connectathon2003, and below is the pdf. (BPA is mentioned later) http://www.connectathon.org/talks03/cthon-keio.pdf I also have an evaluation based on the implementation I made as an extention to KAME stack. BTW, does MIRON work if the CN initializes the RR, and not the MR? Also, it seems very costly to perform RR for every packet destined to the LFN, no? Some more comments inline; On Tue, 19 Oct 2004 18:57:03 +0200, "Pascal Thubert (pthubert)" wrote: > Hi Carlos :) > > Is the MIRON document already published in a final form or does it make sense to provide feed back for lower interest things like typos? For the time being, let me discuss concepts. > > > > Hi, > > > > > > On Wed, 13 Oct 2004 13:34:06 +0200, > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > Hi Tania > > > > > > > > I was thinking things like of snooping. MR might intercept all packets to LFN, recognize > > a HoT and keep it. I remember discussing that with Alex long ago... Anyway, we try to say > > "don't take that path" as opposed to describe a solution in details. > > > > > > I don't think its possible to provide RO while keeping the RR function > > > of MIPv6 untouched. It would probably require modification of the > > > packet at MR to use the HoA opt and the routing header for every > > > packet, if we want to keep the MIPv6 spec as is. > > > > Yes, one possible solution is the MR performing all the RR and RO > > signalling on behalf of the LFNs of the NEMO, in order to provide RO for > > LFNs that are communicating to CNs outside the NEMO. This is actually > > the solution we have proposed in MIRON (see my previous e-mail if you > > want a pointer to it), so the MR, as you said, has to process the > > packets sent/received by a LFN in order to insert HoA DO/remove RH. I > > agree that it could have some performance concerns if the process is > > performed to every LFN-CN "flow", but as we have already discussed in a > > previous thread, some mechanism should be used to perform the RO in a > > reasonable way. > > There are 2 aspects to the proposal, even if (like ORC) it's packaged as one. The first aspect is the proxying for the MNN. The second is obtaining a topologically correct CoA via DHCP. > > 1) proxying > > As we say in this thread, we discussed that on the ML, at least Alex and I, and there are some identified protential problems to the approach (that might be worth more text in the taxonomy?) that you might have to deal with: > > 1a) MNN is VMN > If the MNN is a visitor that handles its own mobility and RO, the MR might in fact act as an attacker (against its will :). CoT messages might clash, and if the MN moves away, the MR might keep the CN binding improperly This can be checked by sending MIP6 like packet to the MNN from the MR and see its response, or if the VMN moved from a different link, it would send a BU to its HA which would be an indication of it being a VMN. MR should keep a list of those VMN though. > 1b) MNN has an SA with CN > For instance, CN is a VPN entry point for MNN, and MNN handles its own IPSEC. Manipulating packets on the fly will cause them to be dropped. This is true. > 1c) Snooping for CoT > MR has to snoop packets to the MNN in order to find CoT. This defeats the very purpose of the test (collocation). So if the test is improved in some future, it might not work anymore. And it's pretty dirty, reading someone else's packets, isn't it :) ? Yes, it is dirty, and I did something similar for BPA. But since BPA focused on assisting the deployment of MIP6, I thought it be a trade off. For MIRON, since it targets NEMO, I would prefere something like a CR place near CN and not modify the packet. > 1d) modifying packets on the fly > Too bad MIP RO to CN is based on Home addr option as opposed to tunnels, which does not seem to be an option. The MR has to match source AND destination in order to find whether it can do RO to the CN. And then it has to insert the option, which might be a painful operation (apparently more costly then tunnelling, which is already hardware assisted in some boxes). Why do you compare it with the tunneling cost? watari From nemo-bounces@ietf.org Thu Oct 21 07:37:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05062 for ; Thu, 21 Oct 2004 07:37:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUJ9-00064M-F4; Thu, 21 Oct 2004 00:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJPy-0002Yq-PH for nemo@megatron.ietf.org; Wed, 20 Oct 2004 12:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22146 for ; Wed, 20 Oct 2004 12:34:22 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJcK-0004fp-5t for nemo@ietf.org; Wed, 20 Oct 2004 12:47:17 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id C00315D125; Thu, 21 Oct 2004 01:33:52 +0900 (JST) Date: Thu, 21 Oct 2004 01:31:24 +0900 (JST) Message-Id: <20041021.013124.85322684.watari@sfc.wide.ad.jp> To: cjbc@it.uc3m.es Subject: Re: [nemo] NEMO RO Problem From: Masafumi Watari In-Reply-To: <1097856109.2435.128.camel@acorde> References: <1097145435.2464.74.camel@acorde> <20041016.000631.102532482.watari@sfc.wide.ad.jp> <1097856109.2435.128.camel@acorde> Organization: Keio University X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello, Sorry for my delayed reply. On Fri, 15 Oct 2004 18:01:49 +0200, Carlos Jes=FAs Bernardos Cano wrote: > Hi Masafumi, > = > Please, see my reply inline. > = > El vie, 15-10-2004 a las 17:06, Masafumi Watari escribi=F3: > > Hello Carlos, > > = > > One quick question I had regarding your comment: > > = > > On Thu, 07 Oct 2004 12:37:15 +0200, > > Carlos Jes=FAs Bernardos Cano wrote: > > = > > > El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3: > > > > Dear all, > > > > = > > > > I wrote a document about NEMO RO problem, please click the = > > > > following link to see the details: > > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt > > > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc > > > > = > > > > This document benefits from a lot of discussions and drafts. > > > > It is still a preliminary version, so there are still a lot = > > > > of questions. For example, Alex said that the charter does > > > > not requires dealing with multi-homing and NEMO RO. IMO, the > > > > requirement that RO solution should function for multi-homing N= EMO = > > > > networks and should not conflict with multi-homing mechanism se= ems > > > > OK. We may also take a stepwise approach to solve multi-homing > > > > and RO issues. Thanks for your comments. > > > = > > > First, thanks for providing the document. As Alex, I can help yo= u with > > > the edition if you want to submit this input as I-D. > > = > > > > = > > > "MR may choose to perform RO function = > > > just with its HA if the number of different CNs is large and all = CNs = > > > scatter around the Internet." > > > = > > > What do you mean with this sentence? I'm not sure, but performing= RO > > > just with the HA sounds to me like not performing RO at all. > > = > > Are you suggesting that bypassing of all HAs on the way as a > > requirement for the solution in RO? For example, RRH always uses t= he > > HA of the sub-MR, while bypassing the HA of the root-MR. > = > No, I'm not suggesting that. I made that comment thinking in a > non-nested NEMO. It sounded to me that if MR decides to perform some = RO > function just with its HA, it is like not performing RO at all, becau= se > packets follow the same path than when NEMO Basic Support is used (i.= e. > CN<->HA<->MR<->MNN). Of course, in a nested NEMO scenario, if packets= > only traverse one HA instead of every MR's HA, these packets are > experiencing some RO. BTW, IMHO the ideal solution would be bypassing= > all the HAs, but I don't know if such solution would be feasible or n= ot > while maintaining the transparency to the MNNs. Therefore, I wasn't > suggesting that requirement. Okay, I understand. I also agree actually. I guess that RO solution could have different levels; for example, solution which bypass all HAs or only the HAs of other MRs on the way. But my concern is that going through even one HA can still be a long path depending on the location so I don't know. MIP6 bypass all HAs so I guess we can with NEMO as well... Masafumi Watari From nemo-bounces@ietf.org Thu Oct 21 07:37:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05140 for ; Thu, 21 Oct 2004 07:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUJO-0006Ai-1r; Thu, 21 Oct 2004 00:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJTY-0003aW-8C for nemo@megatron.ietf.org; Wed, 20 Oct 2004 12:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22638 for ; Wed, 20 Oct 2004 12:38:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJfy-0004li-DV for nemo@ietf.org; Wed, 20 Oct 2004 12:51:03 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 18:52:54 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KGaLT1028347; Wed, 20 Oct 2004 18:37:33 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 18:36:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: provisioning system? (was: [nemo] New draft on prefix delegation) Date: Wed, 20 Oct 2004 18:36:10 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344BB1@xmb-ams-337.emea.cisco.com> Thread-Topic: provisioning system? (was: [nemo] New draft on prefix delegation) Thread-Index: AcS2vi6K/tnLgGAgRdOeElZXB1MDsgAAsXCw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Oct 2004 16:36:15.0566 (UTC) FILETIME=[EAFE46E0:01C4B6C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > Pascal, seems to me like you are talking about what was formerly known > as ASP Application Service Provider. Although I'm aware of several ASP > products I'm not aware of any joint effort to standardize interfaces. > Or maybe webservices aka SOAP and XML. But those are completely outside > the scope of NEMO. Not quite :(=20 A provisioning system is just the name for one of the major components of an Operating Support Systems (OSS). The OSS has to be integrated with other systems such as the BSS (Business Support Systems, not 802.11) We as NEMO need to think of a solution that can be deployed in the real world. Which is full of BSS...=20 Pascal From nemo-bounces@ietf.org Thu Oct 21 07:39:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05470 for ; Thu, 21 Oct 2004 07:39:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKULi-00080I-Dr; Thu, 21 Oct 2004 00:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKCB-0002HM-8R for nemo@megatron.ietf.org; Wed, 20 Oct 2004 13:24:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29176 for ; Wed, 20 Oct 2004 13:24:10 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKOW-0006L3-GT for nemo@ietf.org; Wed, 20 Oct 2004 13:37:06 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id E7EE02F562; Wed, 20 Oct 2004 19:23:32 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 934602F534; Wed, 20 Oct 2004 19:23:31 +0200 (CEST) Subject: RE: [nemo] RE: RO between MR and CN From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC344B18@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC344B18@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Qu8Bxa+imh4WgzhbS0dh" Organization: Universidad Carlos III de Madrid Message-Id: <1098293048.2476.223.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 19:24:09 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: nemo@ietf.org, =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Masafumi Watari X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Qu8Bxa+imh4WgzhbS0dh Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Pascal, El mi=E9, 20-10-2004 a las 16:35, Pascal Thubert (pthubert) escribi=F3:=20 > , we discussed that on the ML, at least Alex and I, and there are > > some identified protential problems to the approach (that might be wort= h more text in the > > taxonomy?) that you might have to deal with: > > > > > > 1a) MNN is VMN > > > If the MNN is a visitor that handles its own mobility and RO, the MR= might in fact act > > as an attacker (against its will :). CoT messages might clash, and if t= he MN moves away, the > > MR might keep the CN binding improperly > >=20 > > This part of the solution ("proxying") is only intended to LFNs, as it'= s > > stated on the document. > This is part of the typo part then, the MNN acronym is used sometimes. Th= e > Next question is whether you have to prevent VMNs or if you add an algori= thm to detect those clients for which you do not do RO. Snooping? We have to detect those clients that are not LFNs, and just do not consider them as candidates for MIRON. It's IMHO easy, and can be done by looking at the headers of the packet. > =20 > > > 1b) MNN has an SA with CN > > > For instance, CN is a VPN entry point for MNN, and MNN handles its o= wn IPSEC. > > Manipulating packets on the fly will cause them to be dropped. > >=20 > > Agree. We are aware of that. Maybe it is not clearly stated in the doc, > > but of course if end-to-end IPSec is used, this part of the solution > > cannot be applied. >=20 > Again this require more snooping. Anyway, we found nothing better in the = exploration of solutions that would be transparent to CN and MNN. All this = snooping seems to be the price to pay for the requirements you took. Note t= hat global HAHA approaches from the other end of the spectrum. RO is betwee= n proxies that belong to the infrastructure and exchange projected routes o= ver dynamic tunnel (route projection). Protecting the privacy the CoA from = the other end is another requirement that appears sometimes.=20 >=20 > There might be different sets of requirements and the requirements end up= orienting the solution quite dramatically. I'm not even sure that the WG w= ill be able to sort out THE set of requirements with THE order of priority = so that we can devise THE RO solution. It might appear that the best fit RO= solution depends on the type of deployment. We'll see :) Yes, I agree. MIRON is just a proposal that provides some RO, without requiring any change on the CN/MNN operation. When we started to address the RO issue in NEMO, one of the strong requirements we had in mind was exactly that: to not change the CN/MNN operation. Of course, MIRON does not try to be THE solution, just one initial approach that may be useful in some cases and that may be also helpful to us in the understanding of the NEMO RO problem. > >=20 > > > 1c) Snooping for CoT > > > MR has to snoop packets to the MNN in order to find CoT. This defeat= s the very purpose > > of the test (collocation). So if the test is improved in some future, i= t might not work > > anymore. And it's pretty dirty, reading someone else's packets, isn't i= t :) ? > >=20 > >=20 > > I agree that if RR is changed in the future, our solution may not work. > > Nevertheless, we proposed this, as you call "dirty" solution, just > > because we didn't want to change RR (one of our main goals is to propos= e > > a solution that does not require changes to deployed protocols and > > nodes, i.e. MIPv6 MNs and CNs). > > I agree that reading someone else's packets is not the ideal solution, > > but OTOH, if you don't want your packets to be read, you use IPSEC. > > Besides, if you don't use IPSEC, your router (or someone in the path) > > can read your packets anyway. > >=20 > > > 1d) modifying packets on the fly > > > Too bad MIP RO to CN is based on Home addr option as opposed to tunn= els, which does not > > seem to be an option. The MR has to match source AND destination in ord= er to find whether it > > can do RO to the CN. And then it has to insert the option, which might = be a painful operation > > (apparently more costly then tunnelling, which is already hardware assi= sted in some boxes). > > > In short, it is going to be software routed for quite some time. > >=20 > > Well, as some other solutions proposed so far, this solution is not > > intended to be used with _every_packet routed by the MR. There are many > > flows that are not worth to be "MIRON-processed" ;-) (e.g. DNS, etc). > > Some heuristics have to be defined to make the decision about which > > "LFN-CN" flows should be optimised and which not. > Sure, that makes sense to me. The point is still that you have to look up= every packet and match both source and destination to see if you have a pr= oxy binding. This is 1) quite costly in terms of CPU and 2) I'm afraid that= hardware acceleration will not be easy to perform, as opposed to simple tu= nnels; same for inserting headers inside the packet.=20 Well, routers have to look in the headers of every packet anyway, haven't they? It is heavier in terms of CPU that just using a tunnel, but IMHO, there are many protocols/services/applications today that already require software processing (e.g. firewalls, etc), and BTW, we are trying to do some optimising, so isn't that worth adding some CPU load in the MR? ;-) > > > 2) CoA > > > > > > Getting the CoA from the TOP has also been discussed in the ML. As yo= u point out, there are > > approaches based on PD, like draft-leekj-nemo-ro-pd-02.txt but also dra= ft-droms-nemo-dhcpv6- > > pd-01.txt. There's also, closer to your proposal, a proxy ND based prop= osal draft-jeong-nemo- > > ro-ndproxy-02.txt . See http://www-users.cs.umn.edu/~jjeong/publication= s/international- > > conference/vtc2004-spring-jaehoon.pdf as well. I like that proposal a l= ot, but we must be > > clear on the use case. We discussed that some time ago on the list as w= ell, but I could not > > dig out the link. > > > > > > The potential issue I see for both approaches is due to the "proxy" s= tates in the network > > (and this is why RRH uses source routing as opposed to transparent): > > > > > > 2a) If the nested structure moves as a whole, it's neat. If it's all = swarming then the > > proxy states are all wrong all the time and the packets do not make it = through. So the issue > > is the resilience to movement. It seems that when the tree grows deeper= , or when the inner or > > in/out movement get more and more important, the chances to reach a nod= e drop rapidly. > >=20 > > Well, we are simulating now our solution in order to check this an othe= r > > issues we have detected so far. OTOH, IMHO that is not such a big > > problem, if a nested tree moves, root-MR detects the movement, and the > > it can inform the other MR using DHCPv6 (DHCPv6 supports sending > > information from the server to clients). The new addresses would be > > propagated to the MRs within the nested tree and then every MR would be > > able to send the appropriate BU. > >=20 > I do not mean it's that bas when the tree moves as a whole; but rather wh= en each node is independent and moves relatively to other nodes. Think of M= Rs in car, wireless APs on the traffic lights and some buildings. And imagi= ne that to get to the AP, you might needs to hop over one or two cars, beca= use you are in a shadow area around the block or something. I'm not sure to get your point. I'm not sure if you are thinking in a MANET scenario, in which ad-routing protocols take care of the problem. If you are thinking in a non-MANET scenario, I don't see the problem either. I don't see clearly why you say that with MIRON, in the scenario you point out, the chances to reach a node drop rapidly. With MIRON, when a MR moves, if it is the root-MR, it just has to obtain IPv6 addresses using DHCPv6 (to be used by itself, and by every nested MR below it), and update the binding with its HA, using standard NEMO Basic Support protocol. If the MR is not a root-MR, it just receives an update of the IPv6 addresses used by itself and the MRs it has below, and updates the binding with its HA. >=20 > > > > > > > > > > > > > > It seems preferable, for instance, to establish a MR-CR tunnel = and exchange fine > > grained > > > > routes for MNPs over the tunnel (route projection). > > > > > > > > > > I think I agree on this. > > > > > > > > This is, IMHO, a different approach, in which the RO requires some > > > > support from the routing infrastructure, and that present some > > > > advantages. But, OTOH, solutions based on MR-CN RO are also interes= ting > > > > IMHO, as an approach that does not require support in the routing > > > > infrastructure and puts the RO support functionality only in the ed= ges, > > > > i.e. the CN and the MR (if the transparency to the MNNs is required= , the > > > > MR is the other edge in which RO mechanisms can be added). > > > > > > > > What do you think? > > > > > > > > > > Right. It would be very nice if you can keep the ML aware of your pro= gress. This solution > > seems very representative of the MR-CN solution space. > >=20 > > Actually, we were thinking in submitting a revised version of MIRON to > > the WG formatted as an I-D to further discussion, but we were waiting t= o > > have some more simulation results and we were also waiting to the > > possible recharter of the WG to focus on RO solutions. >=20 > Cool, please keep us tuned on the simulation results :) >=20 > >=20 > > > Simulating and testing should demonstrate the expected benefits of th= e approach, but also > > show what the limits are in terms of performance in the MR, scalability= in the mobile cloud, > > and resilience to the relative movements within the nested NEMO. > >=20 > > Agree. Actually, we are now working on that. > >=20 > > > Note that RRH allows MNN-CN RO, but it's not documented too much and = the solution is not > > finalized at all; but as opposed to your requirements, it would require= a change to the MNN > > and the CN to get there. The idea is that the MNN would insert an RRH w= ith all slots blank. > >=20 > > That's also interesting. The problem, IMHO, is that it would break the > > CN and MNN transparency. > >=20 > You're right. I'm pointing out that there is a world of solutions dependi= ng on what the key reqs are... Completely agree. Carlos > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-Qu8Bxa+imh4WgzhbS0dh Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBdp845vKyPtrWqkARAuBmAJ9L0fyrSGRVw+0KO3Jg6yp7vVjkAgCgtuQ7 rZh3W+Wxm/qWU55WOxNpZTA= =/pJ3 -----END PGP SIGNATURE----- --=-Qu8Bxa+imh4WgzhbS0dh-- From nemo-bounces@ietf.org Thu Oct 21 07:40:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05550 for ; Thu, 21 Oct 2004 07:40:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKULs-00087i-UY; Thu, 21 Oct 2004 00:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKHV-0002c9-Dt for nemo@megatron.ietf.org; Wed, 20 Oct 2004 13:29:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29551 for ; Wed, 20 Oct 2004 13:29:46 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKTw-0006Uj-AH for nemo@ietf.org; Wed, 20 Oct 2004 13:42:42 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id i9KHWaVm016484; Wed, 20 Oct 2004 10:32:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i9KHRHNM019585; Wed, 20 Oct 2004 12:27:18 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id ED37788CF7C; Wed, 20 Oct 2004 19:29:40 +0200 (CEST) Message-ID: <4176A07E.8090601@motorola.com> Date: Wed, 20 Oct 2004 19:29:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: provisioning system? (was: [nemo] New draft on prefix delegation) References: <7892795E1A87F04CADFCCF41FADD00FC344BB1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC344BB1@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74100FCFCAD5AD6BD16B2A77" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF NEMO WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74100FCFCAD5AD6BD16B2A77 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> Pascal, seems to me like you are talking about what was formerly >> known as ASP Application Service Provider. Although I'm aware of >> several ASP products I'm not aware of any joint effort to >> standardize interfaces. Or maybe webservices aka SOAP and XML. But >> those are completely outside the scope of NEMO. > > Not quite :( > > A provisioning system is just the name for one of the major > components of an Operating Support Systems (OSS). The OSS has to be > integrated with other systems such as the BSS (Business Support > Systems, not 802.11) > > We as NEMO need to think of a solution that can be deployed in the > real world. Which is full of BSS... At this point I'm a bit lost, maybe because I find this decription to be too generic, I'm sorry. Thanks for the information. Alex --------------enig74100FCFCAD5AD6BD16B2A77 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdqCEMmC0w56zj54RAq/aAKCoHq552loe9esOiyTG7Zb2/atgUgCgyg/n ShIRiQw+l3crMuMp7M26HwE= =2kkH -----END PGP SIGNATURE----- --------------enig74100FCFCAD5AD6BD16B2A77-- From nemo-bounces@ietf.org Thu Oct 21 07:46:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06635 for ; Thu, 21 Oct 2004 07:46:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKalP-0004fK-9l; Thu, 21 Oct 2004 07:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKhW-0000Mn-Gs for nemo@megatron.ietf.org; Wed, 20 Oct 2004 13:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02608 for ; Wed, 20 Oct 2004 13:56:35 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKts-0007SJ-B7 for nemo@ietf.org; Wed, 20 Oct 2004 14:09:30 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id i9KALt6O011530; Wed, 20 Oct 2004 03:21:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i9KAGaNM013198; Wed, 20 Oct 2004 05:16:36 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 54FC288CF7C; Wed, 20 Oct 2004 12:18:59 +0200 (CEST) Message-ID: <41763B8D.3000307@motorola.com> Date: Wed, 20 Oct 2004 12:18:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] New draft on prefix delegation References: <41751006.4090005@motorola.com> <4175C7C3.70407@iprg.nokia.com> In-Reply-To: <4175C7C3.70407@iprg.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig25D23D15F21B90D3D36B0968" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF NEMO WG , "T.J.Kniveton" , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig25D23D15F21B90D3D36B0968 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Finally, my oppinion is that the method used by the MIP6 WG to >> assign a Home Address to MN should be used by NEMO too, for >> prefixes. That is, if MIP6 MN generates the Home Address from >> DHAAD+MPD then NEMO should do MNP from MPD. If MIP6 assigns the >> Home Address from DHCP, then NEMO should do MNP from DHCP too. Same >> with BU/BAck. > > there was such a draft proposed in March 2003 extending the Mobile > Prefix discovery mechanism to delegate prefixes for the Mobile > Router. see > http://www.mobilenetworks.org/nemo/drafts/draft-paakkonen-nemo-prefix-delegation-00.txt > > > at that time, the NEMO WG rejected the draft saying that we already > have a mechanism through DHCPv6. IMHO the best way to assign addresses and prefixes is via DHCP. It also makes sense to use the same mechanism in MIP6 and NEMO, and even better - MIP4, MIP6 and NEMO. I've also noticed a new idea of assigning the Home Address with IKE... would this work for MNP's? Alex --------------enig25D23D15F21B90D3D36B0968 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdjuTMmC0w56zj54RAoWFAKCwE4n1s6UFn/m7TG+JZA4/+RjVEwCeOpKz KhE+mQevZEH609SyT5X2HfY= =w6lf -----END PGP SIGNATURE----- --------------enig25D23D15F21B90D3D36B0968-- From nemo-bounces@ietf.org Thu Oct 21 07:46:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06803 for ; Thu, 21 Oct 2004 07:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKam5-0005zK-Oa; Thu, 21 Oct 2004 07:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKL22-0004Iz-4d for nemo@megatron.ietf.org; Wed, 20 Oct 2004 14:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05523 for ; Wed, 20 Oct 2004 14:17:47 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLEP-0008Ez-8q for nemo@ietf.org; Wed, 20 Oct 2004 14:30:41 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 3F0142F577; Wed, 20 Oct 2004 20:17:17 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 2200E2F585; Wed, 20 Oct 2004 20:17:15 +0200 (CEST) Subject: Re: [nemo] RE: RO between MR and CN From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <20041021.011733.112532574.watari@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC308840@xmb-ams-337.emea.cisco.com> <20041021.011733.112532574.watari@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L+aw2E37kJzKTczSJxYA" Organization: Universidad Carlos III de Madrid Message-Id: <1098296270.2476.272.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 20:17:51 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: nemo@ietf.org, =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-L+aw2E37kJzKTczSJxYA Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Masafumi, and Pascal, Thanks for your reply. Comments inline... El mi=E9, 20-10-2004 a las 18:17, Masafumi Watari escribi=F3: > Hi Carlos and Pascal, >=20 > I find MIRON interesting since I had previously worked on something > very similar, what I called, "Binding Proxy Agent (BPA)" to provide RO > between MIP6 MN and standard IPv6 CN. Unfortunatelly all my papers > are in Japanese so I don't have any refs, but I have presented this at > Connectathon2003, and below is the pdf. (BPA is mentioned later) > http://www.connectathon.org/talks03/cthon-keio.pdf >=20 It seems similar in the sense that is a kind of proxy. But in your case, if I've understood well, you tried to provide some RO between MNs and normal IPv6 nodes (without MIPv6 RO CN capabilities). In our case, we try to provide some MIPv6 RO between MIPv6 CNs and LFNs inside the MN. /* NEMO Off Topic: I find your proposal very interesting, but difficult to deploy, because you need to have BPAs near the CNs */ > I also have an evaluation based on the implementation I made as an > extention to KAME stack. >=20 > BTW, does MIRON work if the CN initializes the RR, and not the MR? Yes, you refer to a CN that's actually a MN, don't you? In that case, I think that MIRON will also work, if the LFN has the MIPv6 CN capabilities. > Also, it seems very costly to perform RR for every packet destined to > the LFN, no? Well, it depends of how many different "LFN-CN flows" the MR tries to optimise. Moreover, not all the "flows" should be optimised (some heuristics should be added to decide which flows are worth to be optimised). >=20 > Some more comments inline; >=20 > On Tue, 19 Oct 2004 18:57:03 +0200, > "Pascal Thubert (pthubert)" wrote: >=20 > > Hi Carlos :) > >=20 > > Is the MIRON document already published in a final form or does it make= sense to provide feed back for lower interest things like typos? For the t= ime being, let me discuss concepts. > >=20 > > > > Hi, > > > > > > > > On Wed, 13 Oct 2004 13:34:06 +0200, > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > Hi Tania > > > > > > > > > > I was thinking things like of snooping. MR might intercept all pa= ckets to LFN, recognize > > > a HoT and keep it. I remember discussing that with Alex long ago... A= nyway, we try to say > > > "don't take that path" as opposed to describe a solution in details. > > > > > > > > I don't think its possible to provide RO while keeping the RR funct= ion > > > > of MIPv6 untouched. It would probably require modification of the > > > > packet at MR to use the HoA opt and the routing header for every > > > > packet, if we want to keep the MIPv6 spec as is. > > >=20 > > > Yes, one possible solution is the MR performing all the RR and RO > > > signalling on behalf of the LFNs of the NEMO, in order to provide RO = for > > > LFNs that are communicating to CNs outside the NEMO. This is actually > > > the solution we have proposed in MIRON (see my previous e-mail if you > > > want a pointer to it), so the MR, as you said, has to process the > > > packets sent/received by a LFN in order to insert HoA DO/remove RH. I > > > agree that it could have some performance concerns if the process is > > > performed to every LFN-CN "flow", but as we have already discussed in= a > > > previous thread, some mechanism should be used to perform the RO in a > > > reasonable way. > >=20 > > There are 2 aspects to the proposal, even if (like ORC) it's packaged a= s one. The first aspect is the proxying for the MNN. The second is obtainin= g a topologically correct CoA via DHCP. > >=20 > > 1) proxying > >=20 > > As we say in this thread, we discussed that on the ML, at least Alex an= d I, and there are some identified protential problems to the approach (tha= t might be worth more text in the taxonomy?) that you might have to deal wi= th: > >=20 > > 1a) MNN is VMN > > If the MNN is a visitor that handles its own mobility and RO, the MR m= ight in fact act as an attacker (against its will :). CoT messages might cl= ash, and if the MN moves away, the MR might keep the CN binding improperly >=20 > This can be checked by sending MIP6 like packet to the MNN from the MR > and see its response, or if the VMN moved from a different link, it > would send a BU to its HA which would be an indication of it being a > VMN. MR should keep a list of those VMN though. I think that are other ways to know whether a MNN is a LFN or not. But, anyway, some list should be kept by the MR (at least, the list of "LFN-CN flows" being optimised). >=20 > > 1b) MNN has an SA with CN > > For instance, CN is a VPN entry point for MNN, and MNN handles its own= IPSEC. Manipulating packets on the fly will cause them to be dropped. >=20 > This is true. >=20 > > 1c) Snooping for CoT > > MR has to snoop packets to the MNN in order to find CoT. This defeats = the very purpose of the test (collocation). So if the test is improved in s= ome future, it might not work anymore. And it's pretty dirty, reading someo= ne else's packets, isn't it :) ? >=20 > Yes, it is dirty, and I did something similar for BPA. But since BPA > focused on assisting the deployment of MIP6, I thought it be a trade > off. For MIRON, since it targets NEMO, I would prefere something like > a CR place near CN and not modify the packet. As Pascal has pointed out (I agree with him), IMHO, it depends on the scenarios. Different scenarios may impose different requirements. For example, IMHO, in not all the scenarios may be feasible to place a CR near a CN... >=20 > > 1d) modifying packets on the fly > > Too bad MIP RO to CN is based on Home addr option as opposed to tunnel= s, which does not seem to be an option. The MR has to match source AND dest= ination in order to find whether it can do RO to the CN. And then it has to= insert the option, which might be a painful operation (apparently more cos= tly then tunnelling, which is already hardware assisted in some boxes).=20 >=20 > Why do you compare it with the tunneling cost? >=20 > watari --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-L+aw2E37kJzKTczSJxYA Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBdqvO5vKyPtrWqkARAvwOAJ4l/uEyzOTbKpW3ggONoIdmDjqZNwCgw3bw B73Eco+7+5/mOXvaYsKomW4= =CxMv -----END PGP SIGNATURE----- --=-L+aw2E37kJzKTczSJxYA-- From nemo-bounces@ietf.org Thu Oct 21 08:33:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16102 for ; Thu, 21 Oct 2004 08:33:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb8A-0002hl-6s; Thu, 21 Oct 2004 07:29:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKT7c-00046u-0Z for nemo@megatron.ietf.org; Wed, 20 Oct 2004 22:56:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16837 for ; Wed, 20 Oct 2004 22:56:09 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKTK8-0003hx-IU for nemo@ietf.org; Wed, 20 Oct 2004 23:09:09 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 232E04C0B1 for ; Thu, 21 Oct 2004 11:55:35 +0900 (JST) Date: Thu, 21 Oct 2004 11:58:03 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks Message-Id: <20041021115803.0218035d.ernst@sfc.wide.ad.jp> In-Reply-To: <20040804063003.GA2030@login.ecs.soton.ac.uk> References: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> <20040804063003.GA2030@login.ecs.soton.ac.uk> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, There was this discussion in early August, so I wonder if there is anything that we should do in the NEMO WG regarding this, and otherwise if there is anyone in our group willing to take a close look at the work done in v6ops.=20 Thanks, Thierry. On Wed, 4 Aug 2004 07:30:03 +0100 Tim Chown wrote: > I think NAT is a consideration for the assisted tunneling requirements > analysis that is happening in v6ops. Have you read that? > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-r= equirements-00.txt >=20 > It is NAT-PT that is pushed to the "last resort" status in v6ops (there is > a new push to write up why in an applicability statement, agreed this wee= k). >=20 > I can't find any active reference to "doors" - could you provide a point= er? > Looks like nemo should be talking to v6ops here :)=20 >=20 > thanks, > tim >=20 > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) wrote: > > Well, as I understand the work being done at the MIP6 or v6Ops, Doors i= s not considered because of IPR. On the other hand, since the IPR encumberi= ng is the basically same as that of nemo basic support, doors should be acc= eptable within Nemo. So there IS something that is Nemo specific after all. > >=20 > > There was a discussion in Seoul about NAT traversal (I asked Hesham ove= r the mike) - correct me if I'm wrong - they are not covering NAT in the cu= rrent ipv4/IPv6 interoperability solutions. So we end up with in one hand a= non standard thing (doors) that has now been thoroughly tested and goes th= ough all sorts of NAT including reverse and symmetrical, or in the other en= d the beginning of what may be a MIP remake of v6ops transition story. > >=20 > > Could we just standardize doors so we can deliver something efficient t= o our customers? And then if alternates pop up, they'll have to prove they = are better in that space. > >=20 > > Pascal > >=20 > >=20 > > > -----Original Message----- > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Thierry Ernst > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > To: nemo > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > >=20 > > >=20 > > > Hi Will, > > >=20 > > > Actually, the draft-iett-nemo-requirements mention NAT traversal and > > > IPv4-IPv6 transitin, so that is something we do care about. This said, > > > we concluded last year that there wasn't NEMO-specific issues. If the= re > > > is one, I think the WG should defintely address it. If these are issu= es > > > not specific to NEMO, we need to make sure these issues are addressed= by > > > the relefvant WG. > > >=20 > > > In any case, I agree with your statement. > > >=20 > > > Thierry. > > >=20 > > >=20 > > >=20 > > >=20 > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > ivancic wrote: > > >=20 > > > > Thierry and/or TJ asked if there was additional work that NEMO shou= ld > > > > address prior to closing or rechartering. > > > > > > > > I strongly believe that the group should standardize on a NAT/PAT > > > > transversal over IPv4 backbones. This will greatly increase the > > > > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the > > > > European Nations and just about any Industrial nations is trying to= help > > > > kick-start IPv6 deployments. However, the ISP's and industry do no= t yet > > > > have a good business case. Making the transission easier will help= ALL > > > > of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with= the > > > > "Doors" protocol and demonstrated this to the CIO of the US DoD. T= he > > > > ability to run IPv6 over IPv4 and mix networks was very very import= ant. > > > > > > > > See: > > > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > Note, the "off-site demonstrations in Washington D.C. area" was for= the > > > > Office of Secretary of Defense in order to show a migration path fr= om > > > > IPv4 to IPv6. > > > > > > > > > > > > Will > > > > > > > > -- > > > > ****************************** > > > > William D. Ivancic > > > > Phone 216-433-3494 > > > > Fax 216-433-8705 > > > > Lab 216-433-2620 > > > > Mobile 440-503-4892 > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > >=20 > >=20 > >=20 >=20 >=20 From nemo-bounces@ietf.org Thu Oct 21 08:34:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16634 for ; Thu, 21 Oct 2004 08:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb9r-0005G0-0i; Thu, 21 Oct 2004 07:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKTWs-0004Eh-Rt for nemo@megatron.ietf.org; Wed, 20 Oct 2004 23:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19442 for ; Wed, 20 Oct 2004 23:22:10 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.201] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKTjK-0004T3-0P for nemo@ietf.org; Wed, 20 Oct 2004 23:35:11 -0400 Received: by mproxy.gmail.com with SMTP id 55so56646wri for ; Wed, 20 Oct 2004 20:21:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cFGbWqU53mBD1qYMGhHwFih7VGQdZOEqPesDCkIEC4FiJ0j1lY76yQKNXlpMy04AIGsZ1UgqGsIVEUsma6OVO5e6t39G08aA9+o95+9bUR4VcRHsPnV46H76vLYoU8p+05ctkkXvtABmYeLNwpJio7izYY+ZJiwSZOSRjixAjFw Received: by 10.54.29.8 with SMTP id c8mr172615wrc; Wed, 20 Oct 2004 20:21:41 -0700 (PDT) Received: by 10.54.39.17 with HTTP; Wed, 20 Oct 2004 20:21:41 -0700 (PDT) Message-ID: <2cbceb16041020202115a4a224@mail.gmail.com> Date: Thu, 21 Oct 2004 08:51:41 +0530 From: Vikrant Kaulgud To: Chan-Wah Ng Subject: Re: [nemo] Issues List on Multihoming Issues In-Reply-To: <1098241723.9238.16.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1098241723.9238.16.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vikrant Kaulgud List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi folks, In issue 2 regarding multi-homed MNNs, are we considering MNNs are multi-homed by virtue of obtaining multiple nemo prefixes or would MNNs have multiple access paths to the MRs themselves. In the later situation, multihoming on MNNs can be exploited in better way to achieve higher levels of fault tolerance. Rgds Vikrant Infosys Technologies Ltd. India. On Wed, 20 Oct 2004 11:08:43 +0800, Chan-Wah Ng wrote: > Hello all, > > Like to announce the availability of an issue list for NEMO multihoming > issues draft at the following URL: > > http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ > > We will be working on the 01 version of the draft to close as much of > these issues as possible. Meanwhile, input from the WG will definitely > be helpful and welcomed. > > /rgds > /cwng > > -- ~~~~~~~~ Regards Vikrant From nemo-bounces@ietf.org Thu Oct 21 08:56:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21098 for ; Thu, 21 Oct 2004 08:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbOA-0004vP-At; Thu, 21 Oct 2004 07:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKYog-0005jB-QG for nemo@megatron.ietf.org; Thu, 21 Oct 2004 05:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22380 for ; Thu, 21 Oct 2004 05:00:55 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKZ17-0001Xn-TR for nemo@ietf.org; Thu, 21 Oct 2004 05:13:58 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5301C40D8C; Thu, 21 Oct 2004 11:00:21 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 0D13A40D86; Thu, 21 Oct 2004 11:00:21 +0200 (CEST) Subject: Re: [nemo] NEMO RO Problem From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <20041021.013124.85322684.watari@sfc.wide.ad.jp> References: <1097145435.2464.74.camel@acorde> <20041016.000631.102532482.watari@sfc.wide.ad.jp> <1097856109.2435.128.camel@acorde> <20041021.013124.85322684.watari@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7sBzye32c6VdR15Tc3r/" Organization: Universidad Carlos III de Madrid Message-Id: <1098349259.2432.0.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 21 Oct 2004 11:01:00 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-7sBzye32c6VdR15Tc3r/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Masafumi, > > > > "MR may choose to perform RO function=20 > > > > just with its HA if the number of different CNs is large and all CN= s=20 > > > > scatter around the Internet." > > > >=20 > > > > What do you mean with this sentence? I'm not sure, but performing R= O > > > > just with the HA sounds to me like not performing RO at all. > > >=20 > > > Are you suggesting that bypassing of all HAs on the way as a > > > requirement for the solution in RO? For example, RRH always uses the > > > HA of the sub-MR, while bypassing the HA of the root-MR. > >=20 > > No, I'm not suggesting that. I made that comment thinking in a > > non-nested NEMO. It sounded to me that if MR decides to perform some RO > > function just with its HA, it is like not performing RO at all, because > > packets follow the same path than when NEMO Basic Support is used (i.e. > > CN<->HA<->MR<->MNN). Of course, in a nested NEMO scenario, if packets > > only traverse one HA instead of every MR's HA, these packets are > > experiencing some RO. BTW, IMHO the ideal solution would be bypassing > > all the HAs, but I don't know if such solution would be feasible or not > > while maintaining the transparency to the MNNs. Therefore, I wasn't > > suggesting that requirement. >=20 > Okay, I understand. I also agree actually. I guess that RO solution > could have different levels; for example, solution which bypass all > HAs or only the HAs of other MRs on the way. >=20 > But my concern is that going through even one HA can still be a long > path depending on the location so I don't know. MIP6 bypass all HAs > so I guess we can with NEMO as well... Yes, I agree on that. IMHO, we definitely have to look for a solution that bypass all the HAs, but the problem I see is that it can be maybe (hopefully not) hard to get if transparency to MNNs and CNs is considered a strong requirement (as I think, IMHO, it should be, for a general solution). Carlos > Masafumi Watari --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-7sBzye32c6VdR15Tc3r/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBd3rK5vKyPtrWqkARAnUYAKCc+kCgxvS9h5Ry9As8NROFi5ddZwCfSdwM s4gFdTfyLKjtE+muwUlaJmo= =yBeO -----END PGP SIGNATURE----- --=-7sBzye32c6VdR15Tc3r/-- From nemo-bounces@ietf.org Thu Oct 21 08:59:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21801 for ; Thu, 21 Oct 2004 08:59:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbOL-0004zW-OM; Thu, 21 Oct 2004 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaLB-0001UP-IR for nemo@megatron.ietf.org; Thu, 21 Oct 2004 06:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27080 for ; Thu, 21 Oct 2004 06:38:38 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKaXm-0002rw-5u for nemo@ietf.org; Thu, 21 Oct 2004 06:51:43 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AD1D92F6BB; Thu, 21 Oct 2004 12:38:06 +0200 (CEST) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 8E4AA2F663; Thu, 21 Oct 2004 12:38:06 +0200 (CEST) In-Reply-To: <1098239668.9236.11.camel@localhost> References: <1098239668.9236.11.camel@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] Date: Thu, 21 Oct 2004 12:38:15 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, Thanks for the draft. I think that the idea of randomly selecting one address to perform the =20= RR check in order to prove prefix "ownership" is very nice. However, before entering into details, i have a more general concern: =20= Why do you think that a prefix BU with the CN is needed? I mean, i understand that it makes sense to have a BU that affects a =20 prefix with the HA, since all the packets addressed to the addresses in =20= the prefix will be routed through the HA. However, in the case of the CN, the CN wwill be probably communicating =20= with a few nodes within the nemo (probably in most cases with only one) In this case, the benefit of having a bu that affects a prefix seems =20 really reduced, since it only provides benefits in those cases when =20 more than one MNN of the nemo is communicating with the same CN. Do you =20= think this is worth the effort? (i mean changing the BU implies =20 modifying all CNs) Regards, marcelo El 20/10/2004, a las 4:34, Chan-Wah Ng escribi=F3: > Hello Alex & all, > > As I have mentioned earlier in the thread on RO Taxonomy Draft, I was > thinking about the issue of return routability procedure when applied =20= > in > NEMO. Well, the thought process manifest itself into a draft for your > reading pleasure, information of which you can find in the forwarded > announcement below. > > One thing I like to highlight is that this draft is NOT a route > optimization solution. I view it as identifying a potential security > problem of NEMO-RO, and then proposing a mechanism to address this > problem. This mechanism may be incorporated in future NEMO Extended > Support should there be a need. > > As always, comments, criticism, suggestions welcomed (regardless of > harsh or not :)). > > Thanks. > > /rgds > /cwng > > > -----Forwarded Message----- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-ng-nemo-rrnp-00.txt > Date: Tue, 19 Oct 2004 07:47:00 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > > Title : Extending Return Routability Procedure for = Network > Prefix (RRNP) > Author(s) : C. Ng, J. Hirano > Filename : draft-ng-nemo-rrnp-00.txt > Pages : 24 > Date : 2004-10-18 > =09 > This memo highlights the inadequacy of existing return routability > procedure when one takes network prefix into consideration under = the > context of route optimization with Network Mobility (NEMO). An > extended return routability procedure, called Return Routability =20= > with > Network Prefix (RRNP), is thus proposed to address this problem. > With RRNP, a correspondent node can verify the collocation of =20 > care-of > address, home address, and network prefix(es) specified in a = binding > update message. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of = =20 > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ng-nemo-rrnp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > = _______________________________________________________________________=20= > _ > Content-Type: text/plain > Content-ID: <2004-10-18172904.I-D@ietf.org> > > > = _______________________________________________________________________=20= > _ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Content-Type: text/plain > Content-ID: <2004-10-18172904.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt > Content-Type: text/plain > Content-ID: <2004-10-18172904.I-D@ietf.org> > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Thu Oct 21 09:01:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22208 for ; Thu, 21 Oct 2004 09:01:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbOX-00053T-Dw; Thu, 21 Oct 2004 07:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKajw-0003My-3z for nemo@megatron.ietf.org; Thu, 21 Oct 2004 07:04:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28205 for ; Thu, 21 Oct 2004 07:04:12 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKawW-0003Dc-63 for nemo@ietf.org; Thu, 21 Oct 2004 07:17:17 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9LB0xDl015090; Thu, 21 Oct 2004 19:00:59 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id C2C63B240CF; Thu, 21 Oct 2004 19:07:02 +0800 (SGT) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Laboratories Message-Id: <1098356821.9179.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 21 Oct 2004 19:07:02 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i9LB0xDl015090 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Marcelo, On Thu, 2004-10-21 at 18:38, marcelo bagnulo braun wrote: > Hi Chan-Wah, >=20 > Thanks for the draft. >=20 > I think that the idea of randomly selecting one address to perform the = =20 > RR check in order to prove prefix "ownership" is very nice. >=20 Thank you. > However, before entering into details, i have a more general concern: =20 > Why do you think that a prefix BU with the CN is needed? I am just anticipating it. More below. >=20 > I mean, i understand that it makes sense to have a BU that affects a =20 > prefix with the HA, since all the packets addressed to the addresses in= =20 > the prefix will be routed through the HA. > However, in the case of the CN, the CN wwill be probably communicating = =20 > with a few nodes within the nemo (probably in most cases with only one) > In this case, the benefit of having a bu that affects a prefix seems =20 > really reduced, since it only provides benefits in those cases when =20 > more than one MNN of the nemo is communicating with the same CN. Do you= =20 > think this is worth the effort? (i mean changing the BU implies =20 > modifying all CNs) >=20 I understand your line of thinking. But firstly, I am assuming a RO solution requires MR to send prefix to someone (except its own HA) in the BU, not necessarily CN. For instance, a correspondent router. Then the RRNP can be used by that "somebody" to check the validity. Secondly your argument is more on arguing against a RO solution that requires new functionality be implemented on CN. I am not promoting one. I am just anticipating that should such a RO solution materialize, my RRNP proposal may be useful. Thirdly, the RRNP is an extension, not a change in the original RR procedure. We don't require all CN to understand the new RR procedure. Fourthly, addressing your comment on BU with a prefix to CN where there is only one MNN communicating with the CN. But what is the alternative? By sending only normal BU, it is not enough to establish optimized route. =20 Of-course, I understand that there is other approaches to route optimization that will keep CN untouched. If the final solution selected by the WG (after re-charter) does not require the verification of a network prefix, then fine, I treat my RRNP as a useful classroom exercise. Otherwise, I suspect that my RRNP may prove useful. /rgds /cwng > Regards, marcelo >=20 > El 20/10/2004, a las 4:34, Chan-Wah Ng escribi=F3: >=20 > > Hello Alex & all, > > > > As I have mentioned earlier in the thread on RO Taxonomy Draft, I was > > thinking about the issue of return routability procedure when applied= =20 > > in > > NEMO. Well, the thought process manifest itself into a draft for you= r > > reading pleasure, information of which you can find in the forwarded > > announcement below. > > > > One thing I like to highlight is that this draft is NOT a route > > optimization solution. I view it as identifying a potential security > > problem of NEMO-RO, and then proposing a mechanism to address this > > problem. This mechanism may be incorporated in future NEMO Extended > > Support should there be a need. > > > > As always, comments, criticism, suggestions welcomed (regardless of > > harsh or not :)). > > > > Thanks. > > > > /rgds > > /cwng > > > > > > -----Forwarded Message----- > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-ng-nemo-rrnp-00.txt > > Date: Tue, 19 Oct 2004 07:47:00 -0400 > > > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > > directories. > > > > > > Title : Extending Return Routability Procedure for Network > > Prefix (RRNP) > > Author(s) : C. Ng, J. Hirano > > Filename : draft-ng-nemo-rrnp-00.txt > > Pages : 24 > > Date : 2004-10-18 > > =09 > > This memo highlights the inadequacy of existing return routability > > procedure when one takes network prefix into consideration under t= he > > context of route optimization with Network Mobility (NEMO). An > > extended return routability procedure, called Return Routability =20 > > with > > Network Prefix (RRNP), is thus proposed to address this problem. > > With RRNP, a correspondent node can verify the collocation of =20 > > care-of > > address, home address, and network prefix(es) specified in a bindi= ng > > update message. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body o= f =20 > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announc= e > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the =20 > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ng-nemo-rrnp-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _____________________________________________________________________= __=20 > > _ > > Content-Type: text/plain > > Content-ID: <2004-10-18172904.I-D@ietf.org> > > > > > > _____________________________________________________________________= __=20 > > _ > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > Content-Type: text/plain > > Content-ID: <2004-10-18172904.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt > > Content-Type: text/plain > > Content-ID: <2004-10-18172904.I-D@ietf.org> > > > > > ------------------------------------------ > Please note that my former email address > mbagnulo@ing.uc3m.es is no longer in use > Please send mail to: > marcelo at it dot uc3m dot es > ------------------------------------------ >=20 >=20 >=20 From nemo-bounces@ietf.org Thu Oct 21 11:09:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11295 for ; Thu, 21 Oct 2004 11:09:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeQq-0003z4-8b; Thu, 21 Oct 2004 11:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdk2-0005Ui-Ai for nemo@megatron.ietf.org; Thu, 21 Oct 2004 10:16:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03677 for ; Thu, 21 Oct 2004 10:16:32 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdwe-00042o-Mx for nemo@ietf.org; Thu, 21 Oct 2004 10:29:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2004 10:16:02 -0400 X-BrightmailFiltered: true Received: from dshell-w2k01.cisco.com (rtp-vpn3-86.cisco.com [10.82.216.86]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LEFxxU001809 for ; Thu, 21 Oct 2004 10:15:59 -0400 (EDT) Message-Id: <6.0.3.0.2.20041021100941.03d55e88@lint> X-Sender: dshell@lint X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 21 Oct 2004 10:15:59 -0400 To: nemo@ietf.org From: Daniel J Shell Subject: FW: [nemo] NAT/PAT transfersal over IPv4 networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 21 Oct 2004 11:00:46 -0400 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org NEMO It is essential for my deployments of NEMO for my customer base to have the "doors" function standardized. All of my deployments to date have used the doors function over NAT/PAT ipv4 ISP links. Without this functionality NEMO is very limited for my customer base. With the "doors" implementation my customers can deploy a NEMO solution and begin the "SPIRAL" development necessary to move to an IPv6 mobility environment. Some current customers are: Office of Secretary of Defense Joint Forces Command and others. Please keep up the great in the NEMO standards efforts. Thank You Dan Shell CISCO Government Solutions Unit Ip mobility/wireless/satellite 440 331 5663 From nemo-bounces@ietf.org Thu Oct 21 15:17:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08856 for ; Thu, 21 Oct 2004 15:17:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiBd-0004up-6I; Thu, 21 Oct 2004 15:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKi0t-0005ME-G6 for nemo@megatron.ietf.org; Thu, 21 Oct 2004 14:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05023 for ; Thu, 21 Oct 2004 14:50:13 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiDX-00038r-VP for nemo@ietf.org; Thu, 21 Oct 2004 15:03:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2004 11:49:47 -0700 X-BrightmailFiltered: true Received: from ajamwal-u60.cisco.com (ajamwal-u60.cisco.com [128.107.132.155]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9LIne9c015049; Thu, 21 Oct 2004 11:49:41 -0700 (PDT) Date: Thu, 21 Oct 2004 11:49:40 -0700 (PDT) From: Sri Gundavelli To: Daniel J Shell Subject: Re: FW: [nemo] NAT/PAT transfersal over IPv4 networks In-Reply-To: <6.0.3.0.2.20041021100941.03d55e88@lint> Message-ID: References: <6.0.3.0.2.20041021100941.03d55e88@lint> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org We definetly need to standardise a solution for this problem. I personally think some good thinking went in to the Doors mechanism. We can definetly use it as a basis for building a solution for traversal over v4 clouds. Sri. On Thu, 21 Oct 2004, Daniel J Shell wrote: > NEMO > > It is essential for my deployments of NEMO for my customer base to have the > "doors" > function standardized. All of my deployments to date have used the doors > function over NAT/PAT > ipv4 ISP links. Without this functionality NEMO is very limited for my > customer base. > With the "doors" implementation my customers can deploy a NEMO solution and > begin > the "SPIRAL" development necessary to move to an IPv6 mobility environment. > > Some current customers are: > Office of Secretary of Defense > Joint Forces Command > and others. > > Please keep up the great in the NEMO standards efforts. > > Thank You > > > > Dan Shell > CISCO Government Solutions Unit > Ip mobility/wireless/satellite > 440 331 5663 > > > From nemo-bounces@ietf.org Thu Oct 21 21:17:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21094 for ; Thu, 21 Oct 2004 21:17:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlTE-0002c7-8P; Thu, 21 Oct 2004 18:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkCA-0003mQ-1a for nemo@megatron.ietf.org; Thu, 21 Oct 2004 17:10:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27731 for ; Thu, 21 Oct 2004 17:09:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkOn-0000s5-Ku for nemo@ietf.org; Thu, 21 Oct 2004 17:23:06 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9LKfvZ14190; Thu, 21 Oct 2004 13:41:57 -0700 X-mProtect: <200410212041> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[172.18.141.95]") by darkstar.iprg.nokia.com smtpdGWvE9P; Thu, 21 Oct 2004 13:41:55 PDT Message-ID: <4178256F.50403@iprg.nokia.com> Date: Thu, 21 Oct 2004 14:09:03 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal over IPv4 networks) References: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> <20040804063003.GA2030@login.ecs.soton.ac.uk> <20041021115803.0218035d.ernst@sfc.wide.ad.jp> In-Reply-To: <20041021115803.0218035d.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 8bit Cc: nemo , dshell@cisco.com, ryuji@sfc.wide.ad.jp, "T.J.Kniveton" , pthubert@cisco.ccom.cnri.reston.va.us, William.D.Ivancic@nasa.gov X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 8bit Thierry, I personally prefer a solution based on Ryuji's draft http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-v4tunnel-00.txt the Mobile Router basically registers its IPv4 CoA with its Home Agent which supports both IPv4 and IPv6. the outer tunnel would be between the MR's IPv4 CoA and HA's IPv4 address. the inner tunnel would be between the MR's IPv6 HoA (MNN's IPv6 address) and the CN's IPv6 address. for traffic between the MR and the HA, the inner tunnel would be between the MR's IPv6 HoA and HA's IPv6 address. this eliminates double tunneling. with "Doors", for example you end up with a NEMO tunnel inside a Doors tunnel. with the above solution, you end up with a single NEMO tunnel with outer IPv4 header and inner IPv6 header. I was planning to write up something on this, but didnt get to do it before the ID cutt-off deadline. if its okay with the chairs, I would like to present a couple of slides at the next meeting. Vijay Thierry Ernst wrote: > Dear all, > > There was this discussion in early August, so I wonder if there is > anything that we should do in the NEMO WG regarding this, and otherwise > if there is anyone in our group willing to take a close look at the work > done in v6ops. > > Thanks, > Thierry. > > > > > > On Wed, 4 Aug 2004 07:30:03 +0100 > Tim Chown wrote: > > >>I think NAT is a consideration for the assisted tunneling requirements >>analysis that is happening in v6ops. Have you read that? >>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt >> >>It is NAT-PT that is pushed to the "last resort" status in v6ops (there is >>a new push to write up why in an applicability statement, agreed this week). >> >>I can't find any active reference to "doors" - could you provide a pointer? >>Looks like nemo should be talking to v6ops here :) >> >>thanks, >>tim >> >>On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) wrote: >> >>>Well, as I understand the work being done at the MIP6 or v6Ops, Doors is not considered because of IPR. On the other hand, since the IPR encumbering is the basically same as that of nemo basic support, doors should be acceptable within Nemo. So there IS something that is Nemo specific after all. >>> >>>There was a discussion in Seoul about NAT traversal (I asked Hesham over the mike) - correct me if I'm wrong - they are not covering NAT in the current ipv4/IPv6 interoperability solutions. So we end up with in one hand a non standard thing (doors) that has now been thoroughly tested and goes though all sorts of NAT including reverse and symmetrical, or in the other end the beginning of what may be a MIP remake of v6ops transition story. >>> >>>Could we just standardize doors so we can deliver something efficient to our customers? And then if alternates pop up, they'll have to prove they are better in that space. >>> >>>Pascal >>> >>> >>> >>>>-----Original Message----- >>>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst >>>>Sent: mercredi 4 ao{t 2004 01:41 >>>>To: nemo >>>>Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >>>> >>>> >>>>Hi Will, >>>> >>>>Actually, the draft-iett-nemo-requirements mention NAT traversal and >>>>IPv4-IPv6 transitin, so that is something we do care about. This said, >>>>we concluded last year that there wasn't NEMO-specific issues. If there >>>>is one, I think the WG should defintely address it. If these are issues >>>>not specific to NEMO, we need to make sure these issues are addressed by >>>>the relefvant WG. >>>> >>>>In any case, I agree with your statement. >>>> >>>>Thierry. >>>> >>>> >>>> >>>> >>>>On Tue, 03 Aug 2004 18:21:37 -0400 >>>>ivancic wrote: >>>> >>>> >>>>>Thierry and/or TJ asked if there was additional work that NEMO should >>>>>address prior to closing or rechartering. >>>>> >>>>>I strongly believe that the group should standardize on a NAT/PAT >>>>>transversal over IPv4 backbones. This will greatly increase the >>>>>ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the >>>>>European Nations and just about any Industrial nations is trying to help >>>>>kick-start IPv6 deployments. However, the ISP's and industry do not yet >>>>>have a good business case. Making the transission easier will help ALL >>>>>of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with the >>>>>"Doors" protocol and demonstrated this to the CIO of the US DoD. The >>>>>ability to run IPv6 over IPv4 and mix networks was very very important. >>>>> >>>>>See: >>>>>http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm >>>>>Note, the "off-site demonstrations in Washington D.C. area" was for the >>>>>Office of Secretary of Defense in order to show a migration path from >>>>>IPv4 to IPv6. >>>>> >>>>> >>>>>Will >>>>> >>>>>-- >>>>>****************************** >>>>>William D. Ivancic >>>>>Phone 216-433-3494 >>>>>Fax 216-433-8705 >>>>>Lab 216-433-2620 >>>>>Mobile 440-503-4892 >>>>>http://roland.grc.nas.gov/~ivancic >>>>> >>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Thu Oct 21 22:08:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00194 for ; Thu, 21 Oct 2004 22:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoTv-000277-3L; Thu, 21 Oct 2004 21:44:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKo0t-0002c3-C2 for nemo@megatron.ietf.org; Thu, 21 Oct 2004 21:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20292 for ; Thu, 21 Oct 2004 21:14:36 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoDb-0008SY-Ly for nemo@ietf.org; Thu, 21 Oct 2004 21:27:48 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9M1EaNH009904 for ; Thu, 21 Oct 2004 19:14:36 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i9M1EYJQ011873 for ; Fri, 22 Oct 2004 03:14:35 +0200 (MEST) Message-ID: <41785F25.8020303@sun.com> Date: Thu, 21 Oct 2004 18:15:17 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on basic support X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Comments on draft-ietf-nemo-basic-support-03.txt Overall the draft is quite good. Some comments and questions below: 1. Section 3 is doesn't talk about authorization for a MR routing a specific prefix. I suggest adding text after Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address. saying: , once it has verified that the mobile router is authorized to route to those prefixes. The mobile IPv6 mechanisms [1] provides for authentication and the authorization might be performed by maintaining a list of the prefixes which each MR (i.e., Home Address) is allowed to route. Note that this is merely an example. Another example would be that the class of MRs (identified by e.g. the CA+certificate name string in the cert used to setup IPsec) are associated with a set of allowed prefixes. I don't know if folks want to add a new section with multiple examples of how authorization checks can be performed. If not, the above example should at least point out to implementors that some checks are required. 2. Section 1 says The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgment to the Mobile Router. A positive acknowledgment means that the Home Agent has set up forwarding for the mobile network. I suggest clarifying the second sentence to say A positive acknowledgment with the R bit set means that the Home Agent has set up forwarding for the mobile network. 3. Section 4.2 has 140 Mobile Router Operation not permitted 141 Invalid Prefix 142 Not Authorized for Prefix 143 Forwarding Setup failed I understood the meaning of all but 143. From the text it looks like the meaning is "Prefix missing"/"Can't do implicit mode" so why not name the error something along those lines? 4. Multiple prefixes and errors I don't know exactly where it makes sense to clarify this, but the document should say that if one prefix can't be setup, the the HA will not setup any of them. Perhaps saying "if any prefix fails, then all of them will fail" in section 4.3? Also, adding this to the 5th paragraph in section 6.6? 5.Section 5.4.1 and 5.4.2 has these sentences with The Mobile Router MUST discard Binding Acknowledgments with status ... I can understand that the error codes don't make sense in the specific case, but silently ignoring them seems wrong; after all a binding ack with such an error indicates that the HA didn't set things up, and pretending that the BA wasn't received by discarding it isn't useful. Thus I think you want to say something like Since Binding Acknowledgments with status ... should not happen in implicit mode, the Mobile Router will treat them as fatal errors (just like most >=128 are fatal errors). 6. Section 5.5 suggests using the Tunnel Encapsulation Limit, but I don't think it has the suggested effect. A MR can use the option to limit how much nesting occurs "above" the router i.e. between the MR and the Internet, but can't use it to limit how much nesting is "below" it i.e. how deep chains of nested MRs attach to the MR, which is what the text suggests. Or am I the one who is confused? The MR could limit the amount of nesting "below" it by parsing the packet to see how many IP headers are present, but this fails if ESP tunnels are used. 7. Section 5.6 says when that interface is attached to a visited link. However, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface, for topologically correct addresses. and I have no idea what "topologically correct" means in this context. Shouldn't the MR just reply for the addresses it has assigned to the egress interface, just like any other node? Or is this trying to hint at some form of proxy ND? 8. When multiple prefixes are included, then the status in the binding ack signaling an unauthorized prefix doesn't help tell the MR which is the bad prefix. Is this something that has been discussed? If one wanted to provide this information, one could make the Binding Ack carry prefix options, either for all the failed or for all the acceptable prefixes. 9. Section 6.2 has a suboptimal order. After the discussion of the prefix checks, it has the paragraph for unregistering. Since the unregistering check ignores the prefixes it would be clearer if that paragraph was placed earlier in section 6.2. 10. I don't understand how the R bit in the DHAD request and replies help. First of all, when all the HAs on the home link are upgraded to support MRs, which is likely to be the common case, it isn't needed. When some HAs support it and others do not, then in some cases the anycast DHAD request will reach an HA which doesn't understand the R bit. Hence the MR needs to be prepared to handle the reply without the R bit, by trying all the listed HAs. Hence the R bit is an optimization for this "not all support it" case when the anycast happens by chance to reach a HA which supports MRs. It doesn't seem worth while to add the R bit to optimize this infrequent case. 11. Section 9 says In case the Mobile Router receives a IP-in-IP tunneled packet from a node in the Mobile Network and the Mobile Router has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet. In don't understand why this restriction is in place. Wouldn't it prevent nested mobile networks where the "lower" one will use its home address, which the upper MR has no knowledge of, in the inner header? 12. Section 9 should say something about authorization checks before the MR can cause routes to be injected by the HA, whether this is done using prefix options or running a routing protocol. 13. Appendix B.2 says: The following should be considered when the Home Network is configured for running OSPF. - The entire Home domain SHOULD NOT be configured as a single area if a Home Agent supports Mobile Routers. At least the Home Network should be configured as a separate area. - The bi-directional tunnel interfaces to the Mobile Routers should never be included in the same area as the backbone links. I don't understand the motivation for this? Is it performance related? If I run a flat (no areas defined) OSPF routing domain with 4 links and 4 prefixes, the above "SHOULD" appears to force me to configure areas. At a minimum the text should explain the basis for the considerations, and perhaps also say that they apply to large routing domains. 14. Since the IETF has been notified of IPR, I think that form of "Intellectual property statement" should be used. 15. It makes sense to run a spell checker. I found the spelling "infrasructure". Erik From nemo-bounces@ietf.org Thu Oct 21 22:10:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00594 for ; Thu, 21 Oct 2004 22:10:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoW7-0005Ts-UV; Thu, 21 Oct 2004 21:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoAt-00049D-LR for nemo@megatron.ietf.org; Thu, 21 Oct 2004 21:24:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22910 for ; Thu, 21 Oct 2004 21:24:56 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoNb-0000SB-JV for nemo@ietf.org; Thu, 21 Oct 2004 21:38:08 -0400 Received: from iseran.local (U190092.ppp.dion.ne.jp [218.222.190.92]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E451E4C08C for ; Fri, 22 Oct 2004 10:24:05 +0900 (JST) Date: Fri, 22 Oct 2004 09:28:23 +0900 From: Thierry Ernst To: nemo Subject: Re: FW: [nemo] NAT/PAT transfersal over IPv4 networks Message-Id: <20041022092823.1283a402.ernst@sfc.wide.ad.jp> In-Reply-To: References: <6.0.3.0.2.20041021100941.03d55e88@lint> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Just note that the reason why I re-introduce this discussion was to see if this is something that should happen in the NEMO WG, or if we should discuss closely with v6ops folks of other. I haven't had the time to check this yet, so if someone has some input to give about v6ops, that would be welcome. Or, if someone could volunteer to check, that will welcome too. Thanks. Thierry. On Thu, 21 Oct 2004 11:49:40 -0700 (PDT) Sri Gundavelli wrote: > > We definetly need to standardise a solution for this > problem. I personally think some good thinking went > in to the Doors mechanism. We can definetly use it > as a basis for building a solution for traversal > over v4 clouds. > > > Sri. > > > > > On Thu, 21 Oct 2004, Daniel J Shell wrote: > > > NEMO > > > > It is essential for my deployments of NEMO for my customer base to have the > > "doors" > > function standardized. All of my deployments to date have used the doors > > function over NAT/PAT > > ipv4 ISP links. Without this functionality NEMO is very limited for my > > customer base. > > With the "doors" implementation my customers can deploy a NEMO solution and > > begin > > the "SPIRAL" development necessary to move to an IPv6 mobility environment. > > > > Some current customers are: > > Office of Secretary of Defense > > Joint Forces Command > > and others. > > > > Please keep up the great in the NEMO standards efforts. > > > > Thank You > > > > > > > > Dan Shell > > CISCO Government Solutions Unit > > Ip mobility/wireless/satellite > > 440 331 5663 > > > > > > > From nemo-bounces@ietf.org Thu Oct 21 22:17:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01447 for ; Thu, 21 Oct 2004 22:17:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKomX-000439-9L; Thu, 21 Oct 2004 22:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoO3-00059B-ER for nemo@megatron.ietf.org; Thu, 21 Oct 2004 21:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26090 for ; Thu, 21 Oct 2004 21:38:32 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoaj-0001UQ-3j for nemo@ietf.org; Thu, 21 Oct 2004 21:51:44 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 21:38:00 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks Date: Thu, 21 Oct 2004 21:37:50 -0400 Message-ID: Thread-Topic: [nemo] NAT/PAT transfersal over IPv4 networks Thread-Index: AcS3agsNznGBNPQTShS/H9ZkbuPyJQAbXgsg From: "Soliman, Hesham" To: "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 22 Oct 2004 01:38:00.0056 (UTC) FILETIME=[C3979780:01C4B7D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thierry, all,=20 I don't understand why this issue should be discussed in nemo. There are certainly migration scenarios that=20 are specific to mobility and are not usually addresed by current mechanisms. We had this discussion in v6ops and=20 mip6 and I think this discussion should happen in those groups. Let's not discuss the same problem in many groups. Hesham > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On=20 > Behalf Of > Thierry Ernst > Sent: Wednesday, October 20, 2004 10:58 PM > To: nemo > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >=20 >=20 >=20 > Dear all, >=20 > There was this discussion in early August, so I wonder if there is > anything that we should do in the NEMO WG regarding this,=20 > and otherwise > if there is anyone in our group willing to take a close look=20 > at the work > done in v6ops.=20 >=20 > Thanks, > Thierry. >=20 >=20 >=20 >=20 >=20 > On Wed, 4 Aug 2004 07:30:03 +0100 > Tim Chown wrote: >=20 > > I think NAT is a consideration for the assisted tunneling=20 > requirements > > analysis that is happening in v6ops. Have you read that? > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted > -tunneling-requirements-00.txt > >=20 > > It is NAT-PT that is pushed to the "last resort" status in=20 > v6ops (there is > > a new push to write up why in an applicability statement,=20 > agreed this week). > >=20 > > I can't find any active reference to "doors" - could you=20 > provide a pointer? > > Looks like nemo should be talking to v6ops here :)=20 > >=20 > > thanks, > > tim > >=20 > > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert=20 > (pthubert) wrote: > > > Well, as I understand the work being done at the MIP6 or=20 > v6Ops, Doors is not considered because of IPR. On the other=20 > hand, since the IPR encumbering is the basically same as=20 > that of nemo basic support, doors should be acceptable=20 > within Nemo. So there IS something that is Nemo specific after all. > > >=20 > > > There was a discussion in Seoul about NAT traversal (I=20 > asked Hesham over the mike) - correct me if I'm wrong - they=20 > are not covering NAT in the current ipv4/IPv6=20 > interoperability solutions. So we end up with in one hand a=20 > non standard thing (doors) that has now been thoroughly=20 > tested and goes though all sorts of NAT including reverse=20 > and symmetrical, or in the other end the beginning of what=20 > may be a MIP remake of v6ops transition story. > > >=20 > > > Could we just standardize doors so we can deliver=20 > something efficient to our customers? And then if alternates=20 > pop up, they'll have to prove they are better in that space. > > >=20 > > > Pascal > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: nemo-bounces@ietf.org=20 > [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > > To: nemo > > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > >=20 > > > >=20 > > > > Hi Will, > > > >=20 > > > > Actually, the draft-iett-nemo-requirements mention NAT=20 > traversal and > > > > IPv4-IPv6 transitin, so that is something we do care=20 > about. This said, > > > > we concluded last year that there wasn't NEMO-specific=20 > issues. If there > > > > is one, I think the WG should defintely address it. If=20 > these are issues > > > > not specific to NEMO, we need to make sure these=20 > issues are addressed by > > > > the relefvant WG. > > > >=20 > > > > In any case, I agree with your statement. > > > >=20 > > > > Thierry. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > > ivancic wrote: > > > >=20 > > > > > Thierry and/or TJ asked if there was additional work=20 > that NEMO should > > > > > address prior to closing or rechartering. > > > > > > > > > > I strongly believe that the group should standardize=20 > on a NAT/PAT > > > > > transversal over IPv4 backbones. This will greatly=20 > increase the > > > > > ability to deploy NEMO IPv6 networks. The US DoD,=20 > Japan, Korea, the > > > > > European Nations and just about any Industrial=20 > nations is trying to help > > > > > kick-start IPv6 deployments. However, the ISP's and=20 > industry do not yet > > > > > have a good business case. Making the transission=20 > easier will help ALL > > > > > of IPv6 deployments. I used some of Pascal's IPv6 =20 > NEMO code with the > > > > > "Doors" protocol and demonstrated this to the CIO of=20 > the US DoD. The > > > > > ability to run IPv6 over IPv4 and mix networks was=20 > very very important. > > > > > > > > > > See: > > > > >=20 http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > Note, the "off-site demonstrations in Washington D.C. area" was = for the > > > > Office of Secretary of Defense in order to show a migration path = from > > > > IPv4 to IPv6. > > > > > > > > > > > > Will > > > > > > > > -- > > > > ****************************** > > > > William D. Ivancic > > > > Phone 216-433-3494 > > > > Fax 216-433-8705 > > > > Lab 216-433-2620 > > > > Mobile 440-503-4892 > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > >=20 > >=20 > >=20 >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Thu Oct 21 22:58:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05134 for ; Thu, 21 Oct 2004 22:58:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpXD-0000cX-As; Thu, 21 Oct 2004 22:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpPF-00073Q-0H for nemo@megatron.ietf.org; Thu, 21 Oct 2004 22:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03517 for ; Thu, 21 Oct 2004 22:43:49 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpbx-0003Hw-EO for nemo@ietf.org; Thu, 21 Oct 2004 22:57:02 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9M2ePUY001008; Fri, 22 Oct 2004 10:40:26 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id E993EB240CF; Fri, 22 Oct 2004 10:46:27 +0800 (SGT) Subject: Re: [nemo] Issues List on Multihoming Issues From: Chan-Wah Ng To: Vikrant Kaulgud In-Reply-To: <2cbceb16041020202115a4a224@mail.gmail.com> References: <1098241723.9238.16.camel@localhost> <2cbceb16041020202115a4a224@mail.gmail.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1098413187.9181.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 22 Oct 2004 10:46:27 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Vikrant, On Thu, 2004-10-21 at 11:21, Vikrant Kaulgud wrote: > Hi folks, > > In issue 2 regarding multi-homed MNNs, are we considering MNNs are > multi-homed by virtue of obtaining multiple nemo prefixes or would > MNNs have multiple access paths to the MRs themselves. > We are more focused on MNNs having multiple addresses configured from different NEMO-prefix, since some issues may be related to NEMO. > In the later situation, multihoming on MNNs can be exploited in better > way to achieve higher levels of fault tolerance. > This I agree, but there is nothing NEMO specific. Any node (fixed, mobile, or otherwise) with multiple path access to its router will enjoy the same benefit. /rgds /cwng From nemo-bounces@ietf.org Fri Oct 22 00:39:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11814 for ; Fri, 22 Oct 2004 00:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKrBW-0000pi-Cj; Fri, 22 Oct 2004 00:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKr3F-0005Vu-KE; Fri, 22 Oct 2004 00:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11155; Fri, 22 Oct 2004 00:29:13 -0400 (EDT) Received: from [12.16.56.39] (helo=afir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrFy-0005Dn-6N; Fri, 22 Oct 2004 00:42:27 -0400 Received: from mail pickup service by afir with Microsoft SMTPSVC; Fri, 22 Oct 2004 00:26:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by afir with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Oct 2004 22:15:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIRB-0007H4-4k; Wed, 20 Oct 2004 11:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHmP-00020B-IY; Wed, 20 Oct 2004 10:49:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11434; Wed, 20 Oct 2004 10:49:30 -0400 (EDT) Message-Id: <200410201449.KAA11434@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:49:30 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 21 Oct 2004 02:15:57.0703 (UTC) FILETIME=[E6C33170:01C4B713] X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-mib-00.txt X-BeenThere: nemo@ietf.org Reply-To: internet-drafts@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-nemo-mib-00.txt Pages : 36 Date : 2004-10-19 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB , for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile IPv6 node with NEMO Basic Support functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20105441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105441.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From nemo-bounces@ietf.org Fri Oct 22 03:38:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08950 for ; Fri, 22 Oct 2004 03:38:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtsz-0002lV-M7; Fri, 22 Oct 2004 03:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtqW-0000ld-BB for nemo@megatron.ietf.org; Fri, 22 Oct 2004 03:28:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08155 for ; Fri, 22 Oct 2004 03:28:18 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKu3F-0008HM-Uv for nemo@ietf.org; Fri, 22 Oct 2004 03:41:31 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2004 09:43:34 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9M7RTSr007659; Fri, 22 Oct 2004 09:27:43 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:27:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks Date: Fri, 22 Oct 2004 09:27:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC344FFC@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NAT/PAT transfersal over IPv4 networks Thread-Index: AcS3agsNznGBNPQTShS/H9ZkbuPyJQAbXgsgAAvr1eA= From: "Pascal Thubert \(pthubert\)" To: "Soliman, Hesham" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 22 Oct 2004 07:27:29.0860 (UTC) FILETIME=[9691C040:01C4B808] X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Hesham: 1) doors was not discussed in any WG. It was initiated at NEMO, then = proposed to MIP6 which pointed to v6Ops. Where it was explicitly = rejected because of IPR. So the loop was tried and done. Let's not start = it again. 2) doors is based on to MIP/NEMO. That's an other reason why it has been = bouncing back and forth.=20 3) doors is a small addition to NEMO, since most of the tooling is = already there; it does the job well, and arguably has more coverage then = some other solutions; but it has been lost in procedures for 2 years in = between IETF WGs. From that pitiful history, I'm afraid that either it = happens in NEMO or not at all. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Soliman, Hesham > Sent: vendredi 22 octobre 2004 03:38 > To: Thierry Ernst; nemo > Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks >=20 > Thierry, all, >=20 > I don't understand why this issue should be discussed > in nemo. There are certainly migration scenarios that > are specific to mobility and are not usually addresed > by current mechanisms. We had this discussion in v6ops and > mip6 and I think this discussion should happen in those groups. > Let's not discuss the same problem in many groups. >=20 > Hesham >=20 > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On > > Behalf Of > > Thierry Ernst > > Sent: Wednesday, October 20, 2004 10:58 PM > > To: nemo > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > Dear all, > > > > There was this discussion in early August, so I wonder if there is > > anything that we should do in the NEMO WG regarding this, > > and otherwise > > if there is anyone in our group willing to take a close look > > at the work > > done in v6ops. > > > > Thanks, > > Thierry. > > > > > > > > > > > > On Wed, 4 Aug 2004 07:30:03 +0100 > > Tim Chown wrote: > > > > > I think NAT is a consideration for the assisted tunneling > > requirements > > > analysis that is happening in v6ops. Have you read that? > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted > > -tunneling-requirements-00.txt > > > > > > It is NAT-PT that is pushed to the "last resort" status in > > v6ops (there is > > > a new push to write up why in an applicability statement, > > agreed this week). > > > > > > I can't find any active reference to "doors" - could you > > provide a pointer? > > > Looks like nemo should be talking to v6ops here :) > > > > > > thanks, > > > tim > > > > > > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert > > (pthubert) wrote: > > > > Well, as I understand the work being done at the MIP6 or > > v6Ops, Doors is not considered because of IPR. On the other > > hand, since the IPR encumbering is the basically same as > > that of nemo basic support, doors should be acceptable > > within Nemo. So there IS something that is Nemo specific after all. > > > > > > > > There was a discussion in Seoul about NAT traversal (I > > asked Hesham over the mike) - correct me if I'm wrong - they > > are not covering NAT in the current ipv4/IPv6 > > interoperability solutions. So we end up with in one hand a > > non standard thing (doors) that has now been thoroughly > > tested and goes though all sorts of NAT including reverse > > and symmetrical, or in the other end the beginning of what > > may be a MIP remake of v6ops transition story. > > > > > > > > Could we just standardize doors so we can deliver > > something efficient to our customers? And then if alternates > > pop up, they'll have to prove they are better in that space. > > > > > > > > Pascal > > > > > > > > > > > > > -----Original Message----- > > > > > From: nemo-bounces@ietf.org > > [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > > > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > > > To: nemo > > > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > > > > > > > Hi Will, > > > > > > > > > > Actually, the draft-iett-nemo-requirements mention NAT > > traversal and > > > > > IPv4-IPv6 transitin, so that is something we do care > > about. This said, > > > > > we concluded last year that there wasn't NEMO-specific > > issues. If there > > > > > is one, I think the WG should defintely address it. If > > these are issues > > > > > not specific to NEMO, we need to make sure these > > issues are addressed by > > > > > the relefvant WG. > > > > > > > > > > In any case, I agree with your statement. > > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > > > ivancic wrote: > > > > > > > > > > > Thierry and/or TJ asked if there was additional work > > that NEMO should > > > > > > address prior to closing or rechartering. > > > > > > > > > > > > I strongly believe that the group should standardize > > on a NAT/PAT > > > > > > transversal over IPv4 backbones. This will greatly > > increase the > > > > > > ability to deploy NEMO IPv6 networks. The US DoD, > > Japan, Korea, the > > > > > > European Nations and just about any Industrial > > nations is trying to help > > > > > > kick-start IPv6 deployments. However, the ISP's and > > industry do not yet > > > > > > have a good business case. Making the transission > > easier will help ALL > > > > > > of IPv6 deployments. I used some of Pascal's IPv6 > > NEMO code with the > > > > > > "Doors" protocol and demonstrated this to the CIO of > > the US DoD. The > > > > > > ability to run IPv6 over IPv4 and mix networks was > > very very important. > > > > > > > > > > > > See: > > > > > > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > > Note, the "off-site demonstrations in Washington D.C. area" = was for the > > > > > Office of Secretary of Defense in order to show a migration = path from > > > > > IPv4 to IPv6. > > > > > > > > > > > > > > > Will > > > > > > > > > > -- > > > > > ****************************** > > > > > William D. Ivancic > > > > > Phone 216-433-3494 > > > > > Fax 216-433-8705 > > > > > Lab 216-433-2620 > > > > > Mobile 440-503-4892 > > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material for the = sole use > of the intended recipient. Any review or distribution by others is = strictly > prohibited. If you are not the intended recipient please contact the = sender > and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From nemo-bounces@ietf.org Fri Oct 22 04:17:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11408 for ; Fri, 22 Oct 2004 04:17:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuXU-0002SE-Ed; Fri, 22 Oct 2004 04:12:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuKu-0004vL-Oi for nemo@megatron.ietf.org; Fri, 22 Oct 2004 03:59:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10327 for ; Fri, 22 Oct 2004 03:59:42 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuXf-0000St-Hy for nemo@ietf.org; Fri, 22 Oct 2004 04:12:56 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2004 10:14:59 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9M7x3Sh013045; Fri, 22 Oct 2004 09:59:06 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:59:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal overIPv4 networks) Date: Fri, 22 Oct 2004 09:58:57 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC345025@xmb-ams-337.emea.cisco.com> Thread-Topic: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal overIPv4 networks) Thread-Index: AcS31SiyNRJsXT1dQDyAyOFJnZME9wAM5veQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Thierry Ernst" X-OriginalArrivalTime: 22 Oct 2004 07:59:02.0374 (UTC) FILETIME=[FE987860:01C4B80C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: quoted-printable Cc: nemo , "Daniel Shell \(dshell\)" , ryuji@sfc.wide.ad.jp, "T.J.Kniveton" , pthubert@cisco.ccom.cnri.reston.va.us, William.D.Ivancic@nasa.gov X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Vijay: At least we start the discussion ... and we can discuss pro/cons, applicability, things like that, and improve the solutions. Note that for the specifics of the tunnel overhead, it is possible to apply some header compression technique, this is nothing new. It specially make sense in the specific case where the door gateway is collocated to the HA, since that makes the gateway stateful anyway; but it might still be a requirement to split them and keep separated states. So if squeezing the tunnel pverhead is a requirement, it is surely not a show stopper for doors, but an addition we have to make for the final solution.=20 Actually we have discussed header compression internally long ago. But improving the draft requires the group attention. Otherwise it's moot. This is why we stopped the writing up for so long. Now in terms of requirement, NEMO might consider: - we have to support NAT or plain public, and if so, which types of NATs. I'm afraid that this is REALLY important.=20 - whether it's acceptable to force that the IPv4 be terminated physically at the HA. Surely it is in some cases as of today. Still it's a limitation, which might have its own deployment and security consequences. I believe it's better if it is just an option for the deployement. - If we want the solution to be deployable incrementally to MIP6/NEMO, and if there's value that the solution might be deployed with no change to the HA. The IPv4 NAT/PAT traversal question has been there for quite some time. I believe that at this point, we can take the time to understand what we have on the table, and if it's possible, take the best of it all and make that a standard. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vijay Devarapalli > Sent: jeudi 21 octobre 2004 23:09 > To: Thierry Ernst > Cc: nemo; Daniel Shell (dshell); ryuji@sfc.wide.ad.jp; T.J.Kniveton; > pthubert@cisco.ccom.cnri.reston.va.us; William.D.Ivancic@nasa.gov > Subject: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal overIPv4 networks) >=20 > Thierry, >=20 > I personally prefer a solution based on Ryuji's draft > http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-v4tunnel-00.txt >=20 > the Mobile Router basically registers its IPv4 CoA with its Home Agent > which supports both IPv4 and IPv6. the outer tunnel would be between > the MR's IPv4 CoA and HA's IPv4 address. the inner tunnel would be > between the MR's IPv6 HoA (MNN's IPv6 address) and the CN's IPv6 > address. for traffic between the MR and the HA, the inner tunnel would > be between the MR's IPv6 HoA and HA's IPv6 address. >=20 > this eliminates double tunneling. with "Doors", for example you end > up with a NEMO tunnel inside a Doors tunnel. with the above solution, > you end up with a single NEMO tunnel with outer IPv4 header and inner > IPv6 header. >=20 > I was planning to write up something on this, but didnt get to do it > before the ID cutt-off deadline. if its okay with the chairs, I would > like to present a couple of slides at the next meeting. >=20 > Vijay >=20 >=20 > Thierry Ernst wrote: >=20 > > Dear all, > > > > There was this discussion in early August, so I wonder if there is > > anything that we should do in the NEMO WG regarding this, and otherwise > > if there is anyone in our group willing to take a close look at the work > > done in v6ops. > > > > Thanks, > > Thierry. > > > > > > > > > > > > On Wed, 4 Aug 2004 07:30:03 +0100 > > Tim Chown wrote: > > > > > >>I think NAT is a consideration for the assisted tunneling requirements > >>analysis that is happening in v6ops. Have you read that? > >>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunnelin g-requirements-00.txt > >> > >>It is NAT-PT that is pushed to the "last resort" status in v6ops (there is > >>a new push to write up why in an applicability statement, agreed this week). > >> > >>I can't find any active reference to "doors" - could you provide a pointer? > >>Looks like nemo should be talking to v6ops here :) > >> > >>thanks, > >>tim > >> > >>On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) wrote: > >> > >>>Well, as I understand the work being done at the MIP6 or v6Ops, Doors is not considered > because of IPR. On the other hand, since the IPR encumbering is the basically same as that of > nemo basic support, doors should be acceptable within Nemo. So there IS something that is > Nemo specific after all. > >>> > >>>There was a discussion in Seoul about NAT traversal (I asked Hesham over the mike) - > correct me if I'm wrong - they are not covering NAT in the current ipv4/IPv6 interoperability > solutions. So we end up with in one hand a non standard thing (doors) that has now been > thoroughly tested and goes though all sorts of NAT including reverse and symmetrical, or in > the other end the beginning of what may be a MIP remake of v6ops transition story. > >>> > >>>Could we just standardize doors so we can deliver something efficient to our customers? > And then if alternates pop up, they'll have to prove they are better in that space. > >>> > >>>Pascal > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > >>>>Sent: mercredi 4 ao{t 2004 01:41 > >>>>To: nemo > >>>>Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > >>>> > >>>> > >>>>Hi Will, > >>>> > >>>>Actually, the draft-iett-nemo-requirements mention NAT traversal and > >>>>IPv4-IPv6 transitin, so that is something we do care about. This said, > >>>>we concluded last year that there wasn't NEMO-specific issues. If there > >>>>is one, I think the WG should defintely address it. If these are issues > >>>>not specific to NEMO, we need to make sure these issues are addressed by > >>>>the relefvant WG. > >>>> > >>>>In any case, I agree with your statement. > >>>> > >>>>Thierry. > >>>> > >>>> > >>>> > >>>> > >>>>On Tue, 03 Aug 2004 18:21:37 -0400 > >>>>ivancic wrote: > >>>> > >>>> > >>>>>Thierry and/or TJ asked if there was additional work that NEMO should > >>>>>address prior to closing or rechartering. > >>>>> > >>>>>I strongly believe that the group should standardize on a NAT/PAT > >>>>>transversal over IPv4 backbones. This will greatly increase the > >>>>>ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the > >>>>>European Nations and just about any Industrial nations is trying to help > >>>>>kick-start IPv6 deployments. However, the ISP's and industry do not yet > >>>>>have a good business case. Making the transission easier will help ALL > >>>>>of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with the > >>>>>"Doors" protocol and demonstrated this to the CIO of the US DoD. The > >>>>>ability to run IPv6 over IPv4 and mix networks was very very important. > >>>>> > >>>>>See: > >>>>>http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > >>>>>Note, the "off-site demonstrations in Washington D.C. area" was for the > >>>>>Office of Secretary of Defense in order to show a migration path from > >>>>>IPv4 to IPv6. > >>>>> > >>>>> > >>>>>Will > >>>>> > >>>>>-- > >>>>>****************************** > >>>>>William D. Ivancic > >>>>>Phone 216-433-3494 > >>>>>Fax 216-433-8705 > >>>>>Lab 216-433-2620 > >>>>>Mobile 440-503-4892 > >>>>>http://roland.grc.nas.gov/~ivancic > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > >=20 >=20 >=20 From nemo-bounces@ietf.org Fri Oct 22 10:19:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07775 for ; Fri, 22 Oct 2004 10:19:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL06U-000162-Tv; Fri, 22 Oct 2004 10:09:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL00k-00058G-Tf for nemo@megatron.ietf.org; Fri, 22 Oct 2004 10:03:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05248 for ; Fri, 22 Oct 2004 10:03:15 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0DY-0006sW-Ba for nemo@ietf.org; Fri, 22 Oct 2004 10:16:32 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id 6D7CD10C461; Fri, 22 Oct 2004 10:02:42 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id 5EB07338D99; Fri, 22 Oct 2004 10:02:42 -0400 (EDT) Received: from grc.nasa.gov (gr2138224.grc.nasa.gov [139.88.111.45]) by webmail.grc.nasa.gov (Postfix) with ESMTP id 69B5C338D98; Fri, 22 Oct 2004 10:02:41 -0400 (EDT) Message-ID: <41791304.7080702@grc.nasa.gov> Date: Fri, 22 Oct 2004 10:02:44 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks References: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> <20040804063003.GA2030@login.ecs.soton.ac.uk> <20041021115803.0218035d.ernst@sfc.wide.ad.jp> In-Reply-To: <20041021115803.0218035d.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-104.2 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: 7bit Cc: nemo , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I was one of the people suggesting that the Doors work or something functionally similar be standardized for NEMO. That is, NAT/PAT transversal needs to be done for initial deployments. In the US, I have run over Sprint, Verizon and T-Mobile. All were using IPv4 in the backbone for GPRS and 1xRTT wireless networks at the time. In addition, T-Mobile was doing administrative filtering which acted just like a NAT. The Doors implementation worked well. I looked at what v6ops was doing regarding transitions, and, to the best of my knowledge and interpretation, they are not addressing mobility issues at this time. In addition, how quickly or if this draft will result in anything is anyones guess. Requirements for assisted tunneling Pascal already has working code. It seems to me that the v6ops group could learn much from the Doors work, at least regarding functional aspects - assuming they want to stay away from the IPR issues. Regardless, IMHO, if one wants to really deploy nemo implementations throughout the world, integrating NAT Transversal and IPv4 tunneling is necessary. Obviously, a direct IPv6 connection is desired, but, if you only have IPv4 connectivity at you WAN attachment points, you really do not have much choice. Will ****************************** William D. Ivancic Thierry Ernst wrote: >quoted-printable >MIME-Version: 1.0 >Content-Type: text/plain; charset="ISO-8859-1" >Content-Transfer-Encoding: quoted-printable >quoted-printable > > >Dear all, > >There was this discussion in early August, so I wonder if there is >anything that we should do in the NEMO WG regarding this, and otherwise >if there is anyone in our group willing to take a close look at the = >work >done in v6ops.=20 > >Thanks, >Thierry. > > > > > >On Wed, 4 Aug 2004 07:30:03 +0100 >Tim Chown wrote: > > > >>I think NAT is a consideration for the assisted tunneling = >> >> >requirements > > >>analysis that is happening in v6ops. Have you read that? >>= >> >> >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-= >requirements-00.txt > > >>=20 >>It is NAT-PT that is pushed to the "last resort" status in v6ops = >> >> >(there is > > >>a new push to write up why in an applicability statement, agreed this = >> >> >week). > > >>=20 >>I can't find any active reference to "doors" - could you provide a = >> >> >pointer? > > >>Looks like nemo should be talking to v6ops here :)=20 >>=20 >>thanks, >>tim >>=20 >>On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) = >> >> >wrote: > > >>>Well, as I understand the work being done at the MIP6 or v6Ops, = >>> >>> >Doors is not considered because of IPR. On the other hand, since the = >IPR encumbering is the basically same as that of nemo basic support, = >doors should be acceptable within Nemo. So there IS something that is = >Nemo specific after all. > > >>>=20 >>>There was a discussion in Seoul about NAT traversal (I asked Hesham = >>> >>> >over the mike) - correct me if I'm wrong - they are not covering NAT in = >the current ipv4/IPv6 interoperability solutions. So we end up with in = >one hand a non standard thing (doors) that has now been thoroughly = >tested and goes though all sorts of NAT including reverse and = >symmetrical, or in the other end the beginning of what may be a MIP = >remake of v6ops transition story. > > >>>=20 >>>Could we just standardize doors so we can deliver something = >>> >>> >efficient to our customers? And then if alternates pop up, they'll have = >to prove they are better in that space. > > >>>=20 >>>Pascal >>>=20 >>>=20 >>> >>> >>>>-----Original Message----- >>>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On = >>>> >>>> >Behalf Of Thierry Ernst > > >>>>Sent: mercredi 4 ao=FBt 2004 01:41 >>>>To: nemo >>>>Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >>>>=20 >>>>=20 >>>>Hi Will, >>>>=20 >>>>Actually, the draft-iett-nemo-requirements mention NAT traversal = >>>> >>>> >and > > >>>>IPv4-IPv6 transitin, so that is something we do care about. This = >>>> >>>> >said, > > >>>>we concluded last year that there wasn't NEMO-specific issues. If = >>>> >>>> >there > > >>>>is one, I think the WG should defintely address it. If these are = >>>> >>>> >issues > > >>>>not specific to NEMO, we need to make sure these issues are = >>>> >>>> >addressed by > > >>>>the relefvant WG. >>>>=20 >>>>In any case, I agree with your statement. >>>>=20 >>>>Thierry. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>On Tue, 03 Aug 2004 18:21:37 -0400 >>>>ivancic wrote: >>>>=20 >>>> >>>> >>>>>Thierry and/or TJ asked if there was additional work that NEMO = >>>>> >>>>> >should > > >>>>>address prior to closing or rechartering. >>>>> >>>>>I strongly believe that the group should standardize on a = >>>>> >>>>> >NAT/PAT > > >>>>>transversal over IPv4 backbones. This will greatly increase = >>>>> >>>>> >the > > >>>>>ability to deploy NEMO IPv6 networks. The US DoD, Japan, = >>>>> >>>>> >Korea, the > > >>>>>European Nations and just about any Industrial nations is = >>>>> >>>>> >trying to help > > >>>>>kick-start IPv6 deployments. However, the ISP's and industry = >>>>> >>>>> >do not yet > > >>>>>have a good business case. Making the transission easier will = >>>>> >>>>> >help ALL > > >>>>>of IPv6 deployments. I used some of Pascal's IPv6 NEMO code = >>>>> >>>>> >with the > > >>>>>"Doors" protocol and demonstrated this to the CIO of the US = >>>>> >>>>> >DoD. The > > >>>>>ability to run IPv6 over IPv4 and mix networks was very very = >>>>> >>>>> >important. > > >>>>>See: >>>>>= >>>>> >>>>> >http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > >>>>>Note, the "off-site demonstrations in Washington D.C. area" was = >>>>> >>>>> >for the > > >>>>>Office of Secretary of Defense in order to show a migration = >>>>> >>>>> >path from > > >>>>>IPv4 to IPv6. >>>>> >>>>> >>>>>Will >>>>> >>>>>-- >>>>>****************************** >>>>>William D. Ivancic >>>>>Phone 216-433-3494 >>>>>Fax 216-433-8705 >>>>>Lab 216-433-2620 >>>>>Mobile 440-503-4892 >>>>>http://roland.grc.nas.gov/~ivancic >>>>> >>>>> >>>>> >>>>> >>>>> >>>>=20 >>>> >>>> >>>=20 >>>=20 >>> >>> >>=20 >>=20 >> >> > > > > From nemo-bounces@ietf.org Fri Oct 22 11:30:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14101 for ; Fri, 22 Oct 2004 11:30:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1Gb-0006qx-C7; Fri, 22 Oct 2004 11:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1AK-00042W-29 for nemo@megatron.ietf.org; Fri, 22 Oct 2004 11:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12885 for ; Fri, 22 Oct 2004 11:17:12 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1N4-0000D0-J8 for nemo@ietf.org; Fri, 22 Oct 2004 11:30:30 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Oct 2004 11:16:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks Date: Fri, 22 Oct 2004 11:16:26 -0400 Message-ID: Thread-Topic: [nemo] NAT/PAT transfersal over IPv4 networks Thread-Index: AcS3agsNznGBNPQTShS/H9ZkbuPyJQAbXgsgAAvr1eAAEI37QA== From: "Soliman, Hesham" To: "Pascal Thubert \(pthubert\)" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 22 Oct 2004 15:16:36.0824 (UTC) FILETIME=[1F779D80:01C4B84A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > 1) doors was not discussed in any WG. It was initiated at=20 > NEMO, then proposed to MIP6 which pointed to v6Ops. Where it=20 > was explicitly rejected because of IPR. So the loop was=20 > tried and done. Let's not start it again. =3D> So it was rejected in v6ops because of IPR and this is=20 the "all IPRs are welcome" WG ;) ?? The loop was tried and=20 done doesn't mean we do it here. If I have an MPLS draft=20 rejected by the MPLS WG I won't bring it to nemo. >=20 > 2) doors is based on to MIP/NEMO. That's an other reason why=20 > it has been bouncing back and forth.=20 =3D> I know this is a hard administrative problem (I don't know why though may be no one considered transition issues for mobility). But I don't think it's appropriate to avoid it by taking this issue to the wrong WG. There is no such thing as "based on nemo" AFAICS. nemo runs an extended (sometimes) version of MIPv6. So doors is based on MIPv6. It does work for mobile hosts doesn't it ? >=20 > 3) doors is a small addition to NEMO, since most of the=20 > tooling is already there; it does the job well, and arguably=20 > has more coverage then some other solutions; but it has been=20 > lost in procedures for 2 years in between IETF WGs. From=20 > that pitiful history, I'm afraid that either it happens in=20 > NEMO or not at all. =3D> It is a pitiful story, I agree. But I don't think doing it=20 in nemo, where there is not much transition expertise, and=20 where the charter is not designed for this, is the right way to go. Hesham >=20 > Pascal >=20 > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]=20 > On Behalf Of Soliman, Hesham > > Sent: vendredi 22 octobre 2004 03:38 > > To: Thierry Ernst; nemo > > Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks > >=20 > > Thierry, all, > >=20 > > I don't understand why this issue should be discussed > > in nemo. There are certainly migration scenarios that > > are specific to mobility and are not usually addresed > > by current mechanisms. We had this discussion in v6ops and > > mip6 and I think this discussion should happen in those groups. > > Let's not discuss the same problem in many groups. > >=20 > > Hesham > >=20 > > > -----Original Message----- > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On > > > Behalf Of > > > Thierry Ernst > > > Sent: Wednesday, October 20, 2004 10:58 PM > > > To: nemo > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > > > > Dear all, > > > > > > There was this discussion in early August, so I wonder=20 > if there is > > > anything that we should do in the NEMO WG regarding this, > > > and otherwise > > > if there is anyone in our group willing to take a close look > > > at the work > > > done in v6ops. > > > > > > Thanks, > > > Thierry. > > > > > > > > > > > > > > > > > > On Wed, 4 Aug 2004 07:30:03 +0100 > > > Tim Chown wrote: > > > > > > > I think NAT is a consideration for the assisted tunneling > > > requirements > > > > analysis that is happening in v6ops. Have you read that? > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted > > > -tunneling-requirements-00.txt > > > > > > > > It is NAT-PT that is pushed to the "last resort" status in > > > v6ops (there is > > > > a new push to write up why in an applicability statement, > > > agreed this week). > > > > > > > > I can't find any active reference to "doors" - could you > > > provide a pointer? > > > > Looks like nemo should be talking to v6ops here :) > > > > > > > > thanks, > > > > tim > > > > > > > > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert > > > (pthubert) wrote: > > > > > Well, as I understand the work being done at the MIP6 or > > > v6Ops, Doors is not considered because of IPR. On the other > > > hand, since the IPR encumbering is the basically same as > > > that of nemo basic support, doors should be acceptable > > > within Nemo. So there IS something that is Nemo=20 > specific after all. > > > > > > > > > > There was a discussion in Seoul about NAT traversal (I > > > asked Hesham over the mike) - correct me if I'm wrong - they > > > are not covering NAT in the current ipv4/IPv6 > > > interoperability solutions. So we end up with in one hand a > > > non standard thing (doors) that has now been thoroughly > > > tested and goes though all sorts of NAT including reverse > > > and symmetrical, or in the other end the beginning of what > > > may be a MIP remake of v6ops transition story. > > > > > > > > > > Could we just standardize doors so we can deliver > > > something efficient to our customers? And then if alternates > > > pop up, they'll have to prove they are better in that space. > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: nemo-bounces@ietf.org > > > [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > > > > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > > > > To: nemo > > > > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > > > > > > > > > > Hi Will, > > > > > > > > > > > > Actually, the draft-iett-nemo-requirements mention NAT > > > traversal and > > > > > > IPv4-IPv6 transitin, so that is something we do care > > > about. This said, > > > > > > we concluded last year that there wasn't NEMO-specific > > > issues. If there > > > > > > is one, I think the WG should defintely address it. If > > > these are issues > > > > > > not specific to NEMO, we need to make sure these > > > issues are addressed by > > > > > > the relefvant WG. > > > > > > > > > > > > In any case, I agree with your statement. > > > > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > > > > ivancic wrote: > > > > > > > > > > > > > Thierry and/or TJ asked if there was additional work > > > that NEMO should > > > > > > > address prior to closing or rechartering. > > > > > > > > > > > > > > I strongly believe that the group should standardize > > > on a NAT/PAT > > > > > > > transversal over IPv4 backbones. This will greatly > > > increase the > > > > > > > ability to deploy NEMO IPv6 networks. The US DoD, > > > Japan, Korea, the > > > > > > > European Nations and just about any Industrial > > > nations is trying to help > > > > > > > kick-start IPv6 deployments. However, the ISP's and > > > industry do not yet > > > > > > > have a good business case. Making the transission > > > easier will help ALL > > > > > > > of IPv6 deployments. I used some of Pascal's IPv6 > > > NEMO code with the > > > > > > > "Doors" protocol and demonstrated this to the CIO of > > > the US DoD. The > > > > > > > ability to run IPv6 over IPv4 and mix networks was > > > very very important. > > > > > > > > > > > > > > See: > > > > > > > > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > > > Note, the "off-site demonstrations in Washington=20 > D.C. area" was for the > > > > > > Office of Secretary of Defense in order to show a=20 > migration path from > > > > > > IPv4 to IPv6. > > > > > > > > > > > > > > > > > > Will > > > > > > > > > > > > -- > > > > > > ****************************** > > > > > > William D. Ivancic > > > > > > Phone 216-433-3494 > > > > > > Fax 216-433-8705 > > > > > > Lab 216-433-2620 > > > > > > Mobile 440-503-4892 > > > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > contact the sender > > and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 >=20 >=20 From nemo-bounces@ietf.org Fri Oct 22 12:51:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19923 for ; Fri, 22 Oct 2004 12:51:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2WU-00007M-RC; Fri, 22 Oct 2004 12:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2SQ-0007JG-Cp for nemo@megatron.ietf.org; Fri, 22 Oct 2004 12:40:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19142 for ; Fri, 22 Oct 2004 12:39:58 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2fE-0001t3-6Y for nemo@ietf.org; Fri, 22 Oct 2004 12:53:17 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9MGfJG2009669; Fri, 22 Oct 2004 09:41:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i9MGcfZl006237; Fri, 22 Oct 2004 11:38:41 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B91B28A3A67; Fri, 22 Oct 2004 18:39:54 +0200 (CEST) Message-ID: <417937D5.9000207@motorola.com> Date: Fri, 22 Oct 2004 18:39:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, introductory References: <41785F25.8020303@sun.com> In-Reply-To: <41785F25.8020303@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF8270653BC861873306742A" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF8270653BC861873306742A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > Comments on draft-ietf-nemo-basic-support-03.txt > > Overall the draft is quite good. > > Some comments and questions below: > > 1. Section 3 is doesn't talk about authorization for a MR routing a > specific > prefix. I suggest adding text after > Update. The Home Agent sets up forwarding for each of these prefixes > to the Mobile Router's Care-of Address. > saying: > , once it has verified that the mobile router is authorized to route to > those prefixes. The mobile IPv6 mechanisms [1] provides for > authentication > and the authorization might be performed by maintaining a list of the > prefixes which each MR (i.e., Home Address) is allowed to route. I agree with this text. > Note that this is merely an example. Another example would be that the > class of > MRs (identified by e.g. the CA+certificate name string in the cert used to > setup IPsec) are associated with a set of allowed prefixes. > I don't know if folks want to add a new section with multiple examples of > how authorization checks can be performed. If not, the above example > should > at least point out to implementors that some checks are required. I do not want to add such a new section; other draft may be ok. > > 2. Section 1 says > The Home Agent acknowledges the Binding Update by sending a Binding > Acknowledgment to the Mobile Router. A positive acknowledgment > means that the Home Agent has set up forwarding for the mobile > network. > I suggest clarifying the second sentence to say > A positive acknowledgment with the R bit set > means that the Home Agent has set up forwarding for the mobile > network. I agree with this modification, it is more precise (Vijay: it's section 3 not 1). Alex --------------enigEF8270653BC861873306742A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBeTfaMmC0w56zj54RAqN5AKC1pkim7kXclaNIJpH1sG23hsZgSgCdExeE e+FtXhgDNWzkfh2xXVWVOqg= =QpMb -----END PGP SIGNATURE----- --------------enigEF8270653BC861873306742A-- From nemo-bounces@ietf.org Fri Oct 22 13:11:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21304 for ; Fri, 22 Oct 2004 13:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2pc-0006li-S4; Fri, 22 Oct 2004 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2my-00059M-Ei for nemo@megatron.ietf.org; Fri, 22 Oct 2004 13:01:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20568 for ; Fri, 22 Oct 2004 13:01:12 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2zn-0002FN-DL for nemo@ietf.org; Fri, 22 Oct 2004 13:14:31 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9MH2YG2000682; Fri, 22 Oct 2004 10:02:34 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i9MH0r6I013470; Fri, 22 Oct 2004 12:00:54 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CDB868A3A67; Fri, 22 Oct 2004 19:01:09 +0200 (CEST) Message-ID: <41793CCF.1060801@motorola.com> Date: Fri, 22 Oct 2004 19:01:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, error processing References: <41785F25.8020303@sun.com> In-Reply-To: <41785F25.8020303@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14E8C3E35E89A6241D064064" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14E8C3E35E89A6241D064064 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > 3. Section 4.2 has > 140 Mobile Router Operation not permitted > > 141 Invalid Prefix > > 142 Not Authorized for Prefix > > 143 Forwarding Setup failed > I understood the meaning of all but 143. From the text it looks like > the meaning is "Prefix missing"/"Can't do implicit mode" > so why not name the error something along those lines? Another meaning we've discussed was that 143 could be sent by HA when its routing table was full. Here 130 Insufficient resources could be used though (but with or without the R bit?). Or if an existing route existed already (towards a different Gateway). Otherwise I agree with the naming, it's good to be explicit about implicit mode's error codes. > 4. Multiple prefixes and errors > I don't know exactly where it makes sense to clarify this, > but the document should say that if one prefix can't be setup, > the the HA will not setup any of them. > Perhaps saying "if any prefix fails, then all of them will fail" in > section 4.3? > Also, adding this to the 5th paragraph in section 6.6? Do we want the behaviour that "if any prefix fails then all of them will fail" or do we want the behaviour "set as many prefixes as you can, please". > 5.Section 5.4.1 and 5.4.2 has these sentences with > The Mobile Router MUST discard Binding > Acknowledgments with status ... > I can understand that the error codes don't make sense in the specific > case, > but silently ignoring them seems wrong; after all a binding ack with such > an error indicates that the HA didn't set things up, and pretending that > the > BA wasn't received by discarding it isn't useful. > Thus I think you want to say something like > Since Binding Acknowledgments with status ... should not happen in > implicit mode, the Mobile Router will treat them as fatal errors > (just like most >=128 are fatal errors). Ok, it makes sense. Instead of discarding, just treat as other BAck fatal errors (128-139). I'm not sure how RFC3775 reuires this to be. Alex --------------enig14E8C3E35E89A6241D064064 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBeTzVMmC0w56zj54RAh8FAJsHTHwt4XK163l41Me5kJE/PONfywCeNk22 CSy9wGxbRXasl0liC1Hcr7A= =wjx8 -----END PGP SIGNATURE----- --------------enig14E8C3E35E89A6241D064064-- From nemo-bounces@ietf.org Fri Oct 22 13:29:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22902 for ; Fri, 22 Oct 2004 13:29:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL32H-0002MY-R5; Fri, 22 Oct 2004 13:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2yX-0000x6-KS for nemo@megatron.ietf.org; Fri, 22 Oct 2004 13:13:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21364 for ; Fri, 22 Oct 2004 13:13:09 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3BL-0002Ru-Kw for nemo@ietf.org; Fri, 22 Oct 2004 13:26:28 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i9MH5bJC007227; Fri, 22 Oct 2004 10:05:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i9MHCn6I028756; Fri, 22 Oct 2004 12:12:50 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 076578A3A67; Fri, 22 Oct 2004 19:13:06 +0200 (CEST) Message-ID: <41793F9B.4030300@motorola.com> Date: Fri, 22 Oct 2004 19:12:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, enc limit References: <41785F25.8020303@sun.com> In-Reply-To: <41785F25.8020303@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigED03846488034FE1B6C65CFF" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED03846488034FE1B6C65CFF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > 6. Section 5.5 suggests using the Tunnel Encapsulation Limit, but I > don't think it has the suggested effect. A MR can use the option to > limit how much nesting occurs "above" the router i.e. between the MR > and the Internet, but can't use it to limit how much nesting is > "below" it i.e. how deep chains of nested MRs attach to the MR, which > is what the text suggests. I guess this is right. I think the current text is wrong. MR adding a DO with the Enc Limit option EL has the effect the MR's above it will further encapsulate (or not) this originating packet; a certain MR adding a DO EL has no effect on limiting the number of nested MR's below it. That single paragraph (A Mobile Router MAY limit...) can be removed. A certain MR may limit how much nesting occurs above it. If this needs to be explicitely stated or not - I'd say no. > The MR could limit the amount of nesting "below" it by parsing the > packet to see how many IP headers are present, but this fails if ESP > tunnels are used. Yep. I don't think it needs to be said here at all. Alex --------------enigED03846488034FE1B6C65CFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBeT+hMmC0w56zj54RAl6WAJ9gFcOcjLzfPj5lS5Zw+MTpYtx+nQCgyTd7 5LMS8ix1m0TNV4RxvRodTTY= =3yBI -----END PGP SIGNATURE----- --------------enigED03846488034FE1B6C65CFF-- From nemo-bounces@ietf.org Fri Oct 22 13:36:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23369 for ; Fri, 22 Oct 2004 13:36:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Fy-0007LN-35; Fri, 22 Oct 2004 13:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3CH-0005bB-Em for nemo@megatron.ietf.org; Fri, 22 Oct 2004 13:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22728 for ; Fri, 22 Oct 2004 13:27:20 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3P6-0002jM-GU for nemo@ietf.org; Fri, 22 Oct 2004 13:40:40 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i9MHRLb6006928; Fri, 22 Oct 2004 10:27:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i9MHOsNM004353; Fri, 22 Oct 2004 12:24:55 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8BE828A3A67; Fri, 22 Oct 2004 19:27:18 +0200 (CEST) Message-ID: <417942F0.8000503@motorola.com> Date: Fri, 22 Oct 2004 19:27:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, ND, prefix BAck and R-DHAAD References: <41785F25.8020303@sun.com> In-Reply-To: <41785F25.8020303@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC1F94635D3EB3F1BE98BF869" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC1F94635D3EB3F1BE98BF869 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > 7. Section 5.6 says > when that interface is attached to a visited link. However, the > Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface, for topologically > correct addresses. > and I have no idea what "topologically correct" means in this context. > Shouldn't the MR just reply for the addresses it has assigned to the egress > interface, just like any other node? It's never been clear to me by RFC3775. But I'm sure MR must not reply for the Home Address if MR not on the home link, hence "topologically correct". Maybe removing "topologically correct". > Or is this trying to hint at some form of proxy ND? No. Proxy ND of what to what? > 8. When multiple prefixes are included, then the status in the > binding ack signaling an unauthorized prefix doesn't help tell the MR > which is the bad prefix. > Is this something that has been discussed? > If one wanted to provide this information, one could make the Binding Ack > carry prefix options, either for all the failed or for all the acceptable > prefixes. This has not been discussed, IIRC. It occured to me once, but did not want to complicate things. This is all in Error Processing. This must be as simple as possible. I was lazy. If more people think we should include this feature, ok. Including prefixes maybe it's too long, maybe indexing them and exchange indexes to point the errors. > 10. I don't understand how the R bit in the DHAD request and replies help. > First of all, when all the HAs on the home link are upgraded to support > MRs, > which is likely to be the common case, it isn't needed. > When some HAs support it and others do not, then in some cases the > anycast DHAD request will reach an HA which doesn't understand the R bit. > Hence the MR needs to be prepared to handle the reply without the R bit, > by trying all the listed HAs. Hence the R bit is an optimization for this > "not all support it" case when the anycast happens by chance to reach a > HA which supports MRs. It doesn't seem worth while to add the R bit > to optimize this infrequent case. It boils down to deciding whether upgrading all-at-once is more probable than just adding a new HA that supports MR's. I do not know. I personally think test deployments will happen where NEMO-enabled HA's and non-NEMO-enabled HA's exist on the same link, but that's just me maybe. Alex --------------enigC1F94635D3EB3F1BE98BF869 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBeUL2MmC0w56zj54RAhchAKCeCLmXd8XpfHHqBb1yEGslCHzzfQCglyYt FqA1edCEM6N20o21IeR9UVc= =y31O -----END PGP SIGNATURE----- --------------enigC1F94635D3EB3F1BE98BF869-- From nemo-bounces@ietf.org Fri Oct 22 18:34:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04458 for ; Fri, 22 Oct 2004 18:34:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7i6-0005zw-Cz; Fri, 22 Oct 2004 18:16:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6sP-00058E-GH for nemo@megatron.ietf.org; Fri, 22 Oct 2004 17:23:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19593 for ; Fri, 22 Oct 2004 17:23:05 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL75F-0001jF-Qw for nemo@ietf.org; Fri, 22 Oct 2004 17:36:26 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9MLN37q029878; Fri, 22 Oct 2004 14:23:04 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9MLN1JQ006718; Fri, 22 Oct 2004 23:23:01 +0200 (MEST) Message-ID: <41797A61.8030301@sun.com> Date: Fri, 22 Oct 2004 14:23:45 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Erik Nordmark Subject: [nemo] RO taxonomy X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks for writing the RO taxonomy draft - it introduces some issues which makes it easier to discuss them without diving into the solutions. I have a couple of high-level comments and concerns. The draft concludes, without any motivation, that the RR test prevents having a MR "proxy" mobility signalling for a LFN. I don't see why this would be the case. To perform such proxying one needs know that there is at most on MR being the proxy i.e. can't have two MRs serve the mobile network with some packets to/from the LFN passing through one and some through the other. And then the MR needs to - determine when to perform RO (e.g. by counting packets in the flows) - send CoTI and HoTI on behalf of the LFN - receive the CoT (which is trivial since it is address to the MR) - receive the HoT (which requires packet inspection of the packets addressed to the LFN) - send the BU and receive the BA - insert the HAO in packets from the LFN - remove the RH type 2 in packets to the LFN - adjust ICMP packet too big to account for the inserts and removes it performs - both the MTU and the "packet in error" needs to be adjusted I can see how such a proxy can be built, and I don't see it being much harder with RR then with other forms of security like CGA or infrastructure based ones. The draft seems to both assume that it is ok to modify CNs to handle Nemo, and that it is necessary to do such modifications. I think it is possible to do both MR proxy RO (for LFNs) and VMN RO without any modifications to the CNs; they would just do MIPv6 CN as currently defined. Thus the text which says 2) The RR test has no negotiable option and is not open for extension, and is pointing out a feature and not a bug. In section 2, the paragraph This section covers the case where the Route Optimization is performed between the MR and the correspondent nodes which mobile network nodes (MNNs) are communicating with. This scenario is useful when a lot of MNNs in a mobile network is communicating with a few corresponding nodes. In such cases the MR only needs to send one binding update (BU) to optimized the route between CN and a few MNNs. seems to imply that a BU to a CN for a prefix is somehow possible. When the CN and mobile network are in different administrations it is extremely unlikely that there would be an infrastructure which would allow the CN to make reasonable authorization decisions for a full prefix. For instance, the current RR scheme could only derive such authorization without loss of security if the RR test is applied to all of the 2^N addresses in the prefix. Similarely for CGA scheme, each individual address would need to be verified. So why are you implicitly assuming that this is feasible and desirable? Section 7 says: 3) The HaO and RH type 2 are designed for a collocated CareOf Address. More specifically, they are not designed to be multi-hop as RRH is, and not extensible, though RRH can be considered as an extension of HAO. I think somebody pointed that out in draft-nordmark-mobileip-mipv6-hindsight-00.txt :-) I think there is important consideration which has a large effect on the possible solutions for both VMNs and for nesting; whether or not the AR will delegate a prefix to the MR. If the MR receives a single address from the AR, then this has to be used as a "shared CoA" for all devices in the mobile network which wishes their packets to travel directly to the mobile network. But if the MR receives a prefix from the AR that it delegates to the non-LFN nodes, then each such Nemo aware node can have its own CoA which represents the shortest path via the MR. It might be useful to represent this somehow in the taxonomy. Erik From nemo-bounces@ietf.org Fri Oct 22 19:05:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10752 for ; Fri, 22 Oct 2004 19:05:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7s6-0001M3-9l; Fri, 22 Oct 2004 18:26:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7ch-0001YN-MK for nemo@megatron.ietf.org; Fri, 22 Oct 2004 18:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29964 for ; Fri, 22 Oct 2004 18:10:54 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7pX-00052Y-3c for nemo@ietf.org; Fri, 22 Oct 2004 18:24:15 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9MMAqui001050; Fri, 22 Oct 2004 16:10:53 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9MMAoJQ009821; Sat, 23 Oct 2004 00:10:51 +0200 (MEST) Message-ID: <41798596.9070900@sun.com> Date: Fri, 22 Oct 2004 15:11:34 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Comments on basic support, error processing References: <41785F25.8020303@sun.com> <41793CCF.1060801@motorola.com> In-Reply-To: <41793CCF.1060801@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Another meaning we've discussed was that 143 could be sent by HA when > its routing table was full. Here 130 Insufficient resources could be > used though (but with or without the R bit?). Or if an existing route > existed already (towards a different Gateway). If you use 143 for this, then it would have the effect that the MR migh try again while specifying prefix option(s), which wouldn't be useful. So I don't think you want to do that. > Do we want the behaviour that "if any prefix fails then all of them will > fail" or do we want the behaviour "set as many prefixes as you can, > please". I think we should pick one choice and make that work. Receiving an error (>=128) would presumably imply that no state change occured on the HA. So if we want "as many as you can", I think there should be - a status < 128 - an indication (by including the prefix options in the ack?) which ones failed But I think it is simpler to make it an atomic all or nothing. Perhaps the binding ack should indicate which one(s) were bad to make it easier to debug this during interoperability testing etc. Erik From nemo-bounces@ietf.org Fri Oct 22 19:05:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10956 for ; Fri, 22 Oct 2004 19:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7yz-0006Qw-CU; Fri, 22 Oct 2004 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7jy-0007cw-25 for nemo@megatron.ietf.org; Fri, 22 Oct 2004 18:18:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02057 for ; Fri, 22 Oct 2004 18:18:25 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7wo-0005a0-Pm for nemo@ietf.org; Fri, 22 Oct 2004 18:31:47 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9MMINs3024331; Fri, 22 Oct 2004 15:18:24 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9MMILJQ010284; Sat, 23 Oct 2004 00:18:22 +0200 (MEST) Message-ID: <41798759.5000303@sun.com> Date: Fri, 22 Oct 2004 15:19:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Comments on basic support, ND, prefix BAck and R-DHAAD References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> In-Reply-To: <417942F0.8000503@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > It's never been clear to me by RFC3775. But I'm sure MR must not reply > for the Home Address if MR not on the home link, hence "topologically > correct". Maybe removing "topologically correct". I'd suggest replacing it with "the CoA" or "the addresses assigned to the egress interface". I don't think there is any harm in responding for the HoA while away from home, since nobody should be sending NSs for it. And RFC 3775 leaves that open. So some implementations might, and others might not because they have assigned the HoA to some tunnel interface when they moved away from home. > This has not been discussed, IIRC. It occured to me once, but did not > want to complicate things. This is all in Error Processing. This must > be as simple as possible. I was lazy. If more people think we should > include this feature, ok. Including prefixes maybe it's too long, maybe > indexing them and exchange indexes to point the errors. I think it might be a benefit in debugging during interop testing, but I don't think it would be useful in operational settings. >> 10. I don't understand how the R bit in the DHAD request and replies >> help. >> First of all, when all the HAs on the home link are upgraded to >> support MRs, >> which is likely to be the common case, it isn't needed. >> When some HAs support it and others do not, then in some cases the >> anycast DHAD request will reach an HA which doesn't understand the R bit. >> Hence the MR needs to be prepared to handle the reply without the R bit, >> by trying all the listed HAs. Hence the R bit is an optimization for this >> "not all support it" case when the anycast happens by chance to reach a >> HA which supports MRs. It doesn't seem worth while to add the R bit >> to optimize this infrequent case. > > > It boils down to deciding whether upgrading all-at-once is more probable > than just adding a new HA that supports MR's. I do not know. I > personally think test deployments will happen where NEMO-enabled HA's > and non-NEMO-enabled HA's exist on the same link, but that's just me maybe. I don't have a problem with incremental upgrade of HAs. It is just that the R bit isn't very useful since the MR must be prepared to try all the HAs when it gets a DHAD reply with no R-bit. So why not have it do this all the time? You are optimizing for the case when the DHAD request reaches an upgraded HA, and IMHO this is not worth optimizing for. Erik From nemo-bounces@ietf.org Fri Oct 22 19:21:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12637 for ; Fri, 22 Oct 2004 19:21:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8WG-0005eg-02; Fri, 22 Oct 2004 19:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8B6-00061i-Bb for nemo@megatron.ietf.org; Fri, 22 Oct 2004 18:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06326 for ; Fri, 22 Oct 2004 18:46:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8O0-0006nw-9U for nemo@ietf.org; Fri, 22 Oct 2004 18:59:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MMIaZ30319; Fri, 22 Oct 2004 15:18:36 -0700 X-mProtect: <200410222218> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdu88MGC; Fri, 22 Oct 2004 15:18:34 PDT Message-ID: <41798D9F.9040309@iprg.nokia.com> Date: Fri, 22 Oct 2004 15:45:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> In-Reply-To: <41785F25.8020303@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi Erik, thanks for the review. Erik Nordmark wrote: > > Comments on draft-ietf-nemo-basic-support-03.txt > > Overall the draft is quite good. > > Some comments and questions below: > > 1. Section 3 is doesn't talk about authorization for a MR routing a > specific > prefix. I suggest adding text after > Update. The Home Agent sets up forwarding for each of these prefixes > to the Mobile Router's Care-of Address. > saying: > , once it has verified that the mobile router is authorized to route to > those prefixes. The mobile IPv6 mechanisms [1] provides for > authentication > and the authorization might be performed by maintaining a list of the > prefixes which each MR (i.e., Home Address) is allowed to route. we do talk about it in section 6.1.2. for section 3, how about just the following The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address, once it has verified that the mobile router is authorized to route to those prefixes. > 2. Section 1 says > The Home Agent acknowledges the Binding Update by sending a Binding > Acknowledgment to the Mobile Router. A positive acknowledgment > means that the Home Agent has set up forwarding for the mobile > network. > I suggest clarifying the second sentence to say > A positive acknowledgment with the R bit set > means that the Home Agent has set up forwarding for the mobile > network. okay. > > 3. Section 4.2 has > 140 Mobile Router Operation not permitted > > 141 Invalid Prefix > > 142 Not Authorized for Prefix > > 143 Forwarding Setup failed > I understood the meaning of all but 143. From the text it looks like > the meaning is "Prefix missing"/"Can't do implicit mode" > so why not name the error something along those lines? I am fine with the change, but this might mean sending the document back to IANA. IANA has already done the assignments. http://www.iana.org/assignments/mobility-parameters. and they call it "Forwarding Setup failed". maybe we can avoid this change. (?) > > 4. Multiple prefixes and errors > I don't know exactly where it makes sense to clarify this, > but the document should say that if one prefix can't be setup, > the the HA will not setup any of them. > Perhaps saying "if any prefix fails, then all of them will fail" in > section 4.3? > Also, adding this to the 5th paragraph in section 6.6? we have some text in section 6.2 - If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the Mobile Network Prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all of the Mobile Network Prefixes. If the Home Agent fails to setup forwarding to all the prefixes listed in the Binding Update, then it MUST NOT forward traffic to any of the prefixes, reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix). dont you think this is enough? > 5.Section 5.4.1 and 5.4.2 has these sentences with > The Mobile Router MUST discard Binding > Acknowledgments with status ... > I can understand that the error codes don't make sense in the specific > case, > but silently ignoring them seems wrong; after all a binding ack with such > an error indicates that the HA didn't set things up, and pretending that > the > BA wasn't received by discarding it isn't useful. > Thus I think you want to say something like > Since Binding Acknowledgments with status ... should not happen in > implicit mode, the Mobile Router will treat them as fatal errors > (just like most >=128 are fatal errors). this is fine with me. proposed text section 5.4.1 In Implicit mode, the Mobile Router interprets only error status '140' (Mobile Router Operation not permitted) and '143' (Forwarding Setup failed). The Mobile Router MUST treat Binding Acknowledgements with status '141' and '142' as fatal errors, since they should not be sent by the Home Agent in implicit mode. section 5.4.2 If the Mobile Router sent a Binding Update to Home Agent in explicit mode then the Mobile Router interprets only error status '140' (Mobile Router Operation not permitted), '141' (Invalid Prefix) and '142' (Not Authorized for Prefix). The Mobile Router MUST treat Binding Acknowledgements with status '143' as a fatal error, since it should not sent by the Home Agent in explicit mode. > > 6. Section 5.5 suggests using the Tunnel Encapsulation Limit, > but I don't think it has the suggested effect. > A MR can use the option to limit how much nesting occurs "above" the router > i.e. between the MR and the Internet, but can't use it to limit how > much nesting is "below" it i.e. how deep chains of nested MRs attach to > the MR, which is what the text suggests. > Or am I the one who is confused? this is embarassing. we should have caught this before. you are right, Eric. this will not help the MR in limiting the number of nested levels. maybe we need to delete the entire paragraph. > 7. Section 5.6 says > when that interface is attached to a visited link. However, the > Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface, for topologically > correct addresses. > and I have no idea what "topologically correct" means in this context. > Shouldn't the MR just reply for the addresses it has assigned to the egress > interface, just like any other node? well, this was put for the MR to avoid replying to any addresses that make no sense on the visited link. for example if the MR has a HoA and CoA configured on the egress interface, we want the MR to respond to neighbor solicitations only for the CoA and not for the HoA. > 8. When multiple prefixes are included, then the status in the > binding ack signaling an unauthorized prefix doesn't help tell the MR > which is the bad prefix. > Is this something that has been discussed? > If one wanted to provide this information, one could make the Binding Ack > carry prefix options, either for all the failed or for all the acceptable > prefixes. I will send a separate mail on this. > > 9. Section 6.2 has a suboptimal order. > After the discussion of the prefix checks, it has the paragraph for > unregistering. Since the unregistering check ignores the prefixes > it would be clearer if that paragraph was placed earlier in section 6.2. you are right. fixed this. > > 10. I don't understand how the R bit in the DHAD request and replies help. > First of all, when all the HAs on the home link are upgraded to support > MRs, > which is likely to be the common case, it isn't needed. > When some HAs support it and others do not, then in some cases the > anycast DHAD request will reach an HA which doesn't understand the R bit. > Hence the MR needs to be prepared to handle the reply without the R bit, > by trying all the listed HAs. Hence the R bit is an optimization for this > "not all support it" case when the anycast happens by chance to reach a > HA which supports MRs. It doesn't seem worth while to add the R bit > to optimize this infrequent case. have you already looked at the discussion in issues #15 and #16? http://people.nokia.net/vijayd/nemo/issues.html. if the MR gets a reply from a Home Agent with the R bit set, it doesnt have to try anymore HAs. > > 11. Section 9 says > In case the Mobile > Router receives a IP-in-IP tunneled packet from a node in the Mobile > Network and the Mobile Router has to forward the decapsulated packet, > it SHOULD perform the above mentioned checks on the source address of > the inner packet. > In don't understand why this restriction is in place. > Wouldn't it prevent nested mobile networks where the "lower" one will use > its home address, which the upper MR has no knowledge of, in the inner > header? please see issue 23. http://people.nokia.net/vijayd/nemo/issue23.txt. it should be possible for the "lower" MR to send a packet you want by setting the destination address on the outer IP header to its own HA, instead of the "upper" MR. > 12. Section 9 should say something about authorization checks before the MR > can cause routes to be injected by the HA, whether this is done using > prefix > options or running a routing protocol. if the MR and the HA are running a routing protocol, Alex Zinin didnt want any text about authorization checks. he said, the routing protocols take care of it. for example, if all the routers in a domain are using a shared key to authenticate routing protocol messages, the fact that the shared key was used should be enough to authorize the routing messages. he didnt want separate checks specified by NEMO. there was a long discussion captured in Issue 31. I guess we need to add the following sentence to the security considerations section. If the Mobile Router sends a Binding Update with a one or more multiple Mobile Network Prefix options, the Home Agent MUST be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes. > 13. Appendix B.2 says: > The following should be considered when the Home Network is > configured for running OSPF. > > - The entire Home domain SHOULD NOT be configured as a single area > if a Home Agent supports Mobile Routers. At least the Home > Network should be configured as a separate area. > > - The bi-directional tunnel interfaces to the Mobile Routers should > never be included in the same area as the backbone links. > > I don't understand the motivation for this? Is it performance related? yes. see issue 31 again. otherwise, if there is a change in routing in one Mobile Network, the entire Home Domain would get to know about it. if there is a change in routing in the home domain, all the mobile routers get a link state message. > If I run a flat (no areas defined) OSPF routing domain > with 4 links and 4 prefixes, the above "SHOULD" appears to force me to > configure areas. At a minimum the text should explain the basis for > the considerations, and perhaps also say that they apply to large routing > domains. I can add some text to justify the two bullet points. The above is necessary to restrict the routing protocol messages to the Home Network, instead of sending the messages to the entire Home domain. > > 14. Since the IETF has been notified of IPR, I think that form of > "Intellectual property statement" should be used. I am a bit ignorant here. is it missing the following text? The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Vijay From nemo-bounces@ietf.org Fri Oct 22 20:09:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15610 for ; Fri, 22 Oct 2004 20:09:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9J7-0001e4-AC; Fri, 22 Oct 2004 19:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL99Y-0005Kr-HT for nemo@megatron.ietf.org; Fri, 22 Oct 2004 19:49:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14645 for ; Fri, 22 Oct 2004 19:48:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9MS-0000yo-Ft for nemo@ietf.org; Fri, 22 Oct 2004 20:02:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MNL1N25903; Fri, 22 Oct 2004 16:21:01 -0700 X-mProtect: <200410222321> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdeXTtq8; Fri, 22 Oct 2004 16:20:59 PDT Message-ID: <41799C40.9000201@iprg.nokia.com> Date: Fri, 22 Oct 2004 16:48:16 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, ND, prefix BAck and R-DHAAD References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> In-Reply-To: <41798759.5000303@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > I don't have a problem with incremental upgrade of HAs. It is just that > the R bit isn't very useful since the MR must be prepared to try all the > HAs when it gets a DHAD reply with no R-bit. So why not have it do this > all the time? without the 'R' bit in the DHAAD reply, a MR does not know that the HA does not support Mobile Routers, until it sends a Binding Update and gets a Binding Ack without the 'R' bit. it would be a good idea for the MR to know this a bit earlier. :) Vijay > > You are optimizing for the case when the DHAD request reaches an > upgraded HA, and IMHO this is not worth optimizing for. > > Erik > From nemo-bounces@ietf.org Fri Oct 22 22:14:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28612 for ; Fri, 22 Oct 2004 22:14:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBMy-00056R-HS; Fri, 22 Oct 2004 22:11:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBIl-0003WS-E6 for nemo@megatron.ietf.org; Fri, 22 Oct 2004 22:06:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23148 for ; Fri, 22 Oct 2004 22:06:37 -0400 (EDT) Received: from bb219-74-21-66.singnet.com.sg ([219.74.21.66] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLBVg-0003A3-7r for nemo@ietf.org; Fri, 22 Oct 2004 22:20:01 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 729B31237AD; Sat, 23 Oct 2004 10:06:15 +0800 (SGT) Subject: Re: [nemo] RO taxonomy From: Chan-Wah NG To: Erik Nordmark In-Reply-To: <41797A61.8030301@sun.com> References: <41797A61.8030301@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1098497174.24034.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 23 Oct 2004 10:06:15 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Erik, Thank you for the comments, as we currently updating the draft (almost a complete re-structuring), and your comments are very useful. More responses below inline. /rgds /cwng On Sat, 2004-10-23 at 05:23, Erik Nordmark wrote: > Thanks for writing the RO taxonomy draft - it introduces some issues > which makes it easier to discuss them without diving into the solutions. > > I have a couple of high-level comments and concerns. > > The draft concludes, without any motivation, that the RR test prevents > having a MR "proxy" mobility signalling for a LFN. > I don't see why this would be the case. To perform such proxying one > needs know that there is at most on MR being the proxy i.e. can't have > two MRs serve the mobile network with some packets to/from the LFN > passing through one and some through the other. And then the MR needs to > - determine when to perform RO (e.g. by counting packets in the flows) > - send CoTI and HoTI on behalf of the LFN > - receive the CoT (which is trivial since it is address to the MR) > - receive the HoT (which requires packet inspection of the > packets addressed to the LFN) > - send the BU and receive the BA > - insert the HAO in packets from the LFN > - remove the RH type 2 in packets to the LFN > - adjust ICMP packet too big to account for the inserts and removes it > performs > - both the MTU and the "packet in error" needs to be adjusted > > I can see how such a proxy can be built, and I don't see it being much > harder with RR then with other forms of security like CGA or > infrastructure based ones. > Okay, that's thus far the most detailed description of a "RO-proxy" that I have read, I will try to include your text into the drat if you don't mind? However, off-hand, one concern for this is security-related. The modification of data packets (i.e. removing RH2): wouldn't it have impact if IPSec is also used (eg. AH)? > > The draft seems to both assume that it is ok to modify CNs to handle > Nemo, and that it is necessary to do such modifications. > I think it is possible to do both MR proxy RO (for LFNs) and VMN RO > without any modifications to the CNs; they would just do MIPv6 CN as > currently defined. > Thus the text which says > 2) The RR test has no negotiable option and is not open for > extension, and > is pointing out a feature and not a bug. > OK. > > In section 2, the paragraph > This section covers the case where the Route Optimization is > performed between the MR and the correspondent nodes which mobile > network nodes (MNNs) are communicating with. This scenario is useful > when a lot of MNNs in a mobile network is communicating with a few > corresponding nodes. In such cases the MR only needs to send one > binding update (BU) to optimized the route between CN and a few MNNs. > seems to imply that a BU to a CN for a prefix is somehow possible. > > When the CN and mobile network are in different administrations it is > extremely unlikely that there would be an infrastructure which would > allow the CN to make reasonable authorization decisions for a full prefix. > For instance, the current RR scheme could only derive such authorization > without loss of security if the RR test is applied to all of the 2^N > addresses in the prefix. Similarely for CGA scheme, each individual > address would need to be verified. > So why are you implicitly assuming that this is feasible and desirable? > In the upcoming version of the draft, we indeed will point out this concern of verification of prefix "ownership". Side-tracking a bit, I have written another draft (draft-ng-nemo-rrnp) on this. Should you be not too busy, a comment or two from you would be invaluable and appreciated. > Section 7 says: > 3) The HaO and RH type 2 are designed for a collocated CareOf > Address. More specifically, they are not designed to be multi-hop as > RRH is, and not extensible, though RRH can be considered as an > extension of HAO. > I think somebody pointed that out in > draft-nordmark-mobileip-mipv6-hindsight-00.txt :-) > Ok. > > I think there is important consideration which has a large effect on > the possible solutions for both VMNs and for nesting; whether or not the > AR will delegate a prefix to the MR. > If the MR receives a single address from the AR, then this has to be > used as a "shared CoA" for all devices in the mobile network which > wishes their packets to travel directly to the mobile network. > But if the MR receives a prefix from the AR that it delegates to the > non-LFN nodes, then each such Nemo aware node can have its own CoA which > represents the shortest path via the MR. > It might be useful to represent this somehow in the taxonomy. > Right, with the recent exchanges of mails on prefix delegation, I am starting to think that this class of approach may deserve its own separate section in the taxonomy. Previously, it was mentioned as one approach in "Nested Network Optimization". /rgds /cwng From nemo-bounces@ietf.org Sun Oct 24 10:30:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03324 for ; Sun, 24 Oct 2004 10:30:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLjMN-0000L8-0D; Sun, 24 Oct 2004 10:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLjKX-00007w-PS for nemo@megatron.ietf.org; Sun, 24 Oct 2004 10:26:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02928 for ; Sun, 24 Oct 2004 10:26:40 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLjXj-0006xv-Tb for nemo@ietf.org; Sun, 24 Oct 2004 10:40:24 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EF0702F768; Sun, 24 Oct 2004 16:26:06 +0200 (CEST) Received: from [163.117.252.226] (vpn-252-226.uc3m.es [163.117.252.226]) by smtp03.uc3m.es (Postfix) with ESMTP id 791982F763; Sun, 24 Oct 2004 16:26:05 +0200 (CEST) In-Reply-To: <1098356821.9179.34.camel@localhost> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] Date: Sun, 24 Oct 2004 16:26:14 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable El 21/10/2004, a las 13:07, Chan-Wah Ng escribi=F3: >> >> I mean, i understand that it makes sense to have a BU that affects a >> prefix with the HA, since all the packets addressed to the addresses =20= >> in >> the prefix will be routed through the HA. >> However, in the case of the CN, the CN wwill be probably = communicating >> with a few nodes within the nemo (probably in most cases with only =20= >> one) >> In this case, the benefit of having a bu that affects a prefix seems >> really reduced, since it only provides benefits in those cases when >> more than one MNN of the nemo is communicating with the same CN. Do =20= >> you >> think this is worth the effort? (i mean changing the BU implies >> modifying all CNs) >> > > I understand your line of thinking. But firstly, I am assuming a RO > solution requires MR to send prefix to someone (except its own HA) in i would challenge that, see below (in the alternatives part) > the BU, not necessarily CN. For instance, a correspondent router. = Then > the RRNP can be used by that "somebody" to check the validity. > agree > Secondly your argument is more on arguing against a RO solution that > requires new functionality be implemented on CN. I am not promoting > one. I am just anticipating that should such a RO solution =20 > materialize, > my RRNP proposal may be useful. ok > > Thirdly, the RRNP is an extension, not a change in the original RR > procedure. We don't require all CN to understand the new RR = procedure. > well, all RO approaches are an optimizaion aren't they? we can always =20= fall back to basic support, so i don't buy this one. > Fourthly, addressing your comment on BU with a prefix to CN where = there > is only one MNN communicating with the CN. But what is the > alternative? By sending only normal BU, it is not enough to establish > optimized route. Why not? in the most cases (AFAICS) a given CN will only be communicating with a =20= single MNN of a given nemo. so in this case, you only need to tell that =20= CN which is the CoA of the MNN (i.e. present the CoA of the MR as the =20= CoA of the MNN using MIP) for that the BU of MIP is enough. So i would say that you could simply use mip BU unchanged. I see the prefix scoped BU as an optimization of the mip BU which only =20= benefit is to reduce the number of messages when the CN is =20 communicating with more than one MNN of the same nemo simoultaneously. =20= My question is if such optimzation worth the deployment effort. > > Of-course, I understand that there is other approaches to route > optimization that will keep CN untouched. If the final solution > selected by the WG (after re-charter) does not require the = verification > of a network prefix, then fine, I treat my RRNP as a useful classroom > exercise. As i already mention, i think that the RRNP is a nice approach to use =20= RR to verify a prefix BU. However, i am not sure that the CN should do =20= this. Summarizing: imho the RRNP is an interesting tool to verify a prefix imho implementing this at the CN level is not worth the effort (i.e. =20 the obtained benefits doesn't seems so much imho) Regards, marcelo > Otherwise, I suspect that my RRNP may prove useful. > > /rgds > /cwng > >> Regards, marcelo >> >> El 20/10/2004, a las 4:34, Chan-Wah Ng escribi=F3: >> >>> Hello Alex & all, >>> >>> As I have mentioned earlier in the thread on RO Taxonomy Draft, I = was >>> thinking about the issue of return routability procedure when = applied >>> in >>> NEMO. Well, the thought process manifest itself into a draft for =20= >>> your >>> reading pleasure, information of which you can find in the forwarded >>> announcement below. >>> >>> One thing I like to highlight is that this draft is NOT a route >>> optimization solution. I view it as identifying a potential = security >>> problem of NEMO-RO, and then proposing a mechanism to address this >>> problem. This mechanism may be incorporated in future NEMO Extended >>> Support should there be a need. >>> >>> As always, comments, criticism, suggestions welcomed (regardless of >>> harsh or not :)). >>> >>> Thanks. >>> >>> /rgds >>> /cwng >>> >>> >>> -----Forwarded Message----- >>> From: Internet-Drafts@ietf.org >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-ng-nemo-rrnp-00.txt >>> Date: Tue, 19 Oct 2004 07:47:00 -0400 >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Extending Return Routability Procedure for = Network >>> Prefix (RRNP) >>> Author(s) : C. Ng, J. Hirano >>> Filename : draft-ng-nemo-rrnp-00.txt >>> Pages : 24 >>> Date : 2004-10-18 >>> =09 >>> This memo highlights the inadequacy of existing return routability >>> procedure when one takes network prefix into consideration under =20= >>> the >>> context of route optimization with Network Mobility (NEMO). An >>> extended return routability procedure, called Return Routability >>> with >>> Network Prefix (RRNP), is thus proposed to address this problem. >>> With RRNP, a correspondent node can verify the collocation of >>> care-of >>> address, home address, and network prefix(es) specified in a =20 >>> binding >>> update message. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body =20= >>> of >>> the message. >>> You can also visit =20 >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ng-nemo-rrnp-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt". >>> =09 >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail = readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> =09 >>> =09 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> = _____________________________________________________________________=20 >>> __ >>> _ >>> Content-Type: text/plain >>> Content-ID: <2004-10-18172904.I-D@ietf.org> >>> >>> >>> = _____________________________________________________________________=20 >>> __ >>> _ >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>> Content-Type: text/plain >>> Content-ID: <2004-10-18172904.I-D@ietf.org> >>> >>> ENCODING mime >>> FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt >>> Content-Type: text/plain >>> Content-ID: <2004-10-18172904.I-D@ietf.org> >>> >>> >> ------------------------------------------ >> Please note that my former email address >> mbagnulo@ing.uc3m.es is no longer in use >> Please send mail to: >> marcelo at it dot uc3m dot es >> ------------------------------------------ >> >> >> > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Sun Oct 24 11:41:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07567 for ; Sun, 24 Oct 2004 11:41:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLkS7-0007AQ-OM; Sun, 24 Oct 2004 11:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLkRI-00074g-QY for nemo@megatron.ietf.org; Sun, 24 Oct 2004 11:37:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07398 for ; Sun, 24 Oct 2004 11:37:46 -0400 (EDT) Received: from bb219-74-22-112.singnet.com.sg ([219.74.22.112] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLkeY-0008Ar-KT for nemo@ietf.org; Sun, 24 Oct 2004 11:51:31 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 61EB52D785C; Sun, 24 Oct 2004 23:37:26 +0800 (SGT) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] From: Chan-Wah NG To: marcelo bagnulo braun In-Reply-To: References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1098632245.534.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 24 Oct 2004 23:37:26 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Marcelo, On Sun, 2004-10-24 at 22:26, marcelo bagnulo braun wrote: > > > > I understand your line of thinking. But firstly, I am assuming a RO > > solution requires MR to send prefix to someone (except its own HA) in > > i would challenge that, see below (in the alternatives part) again, I am not saying an RO solution must. I am just anticipating one, if if things really go this way, I foresee a problem. Hence a solution for a problem I foresee. > > > > Thirdly, the RRNP is an extension, not a change in the original RR > > procedure. We don't require all CN to understand the new RR procedure. > > > > well, all RO approaches are an optimizaion aren't they? we can always > fall back to basic support, so i don't buy this one. you are absolutely correct, so the same logic that applies to MIPv6 RO applies here. If CN don't implement RRNP, they don't enjoy optimized route. Things don't break because CN don't want to implement something new, which is my point. > > > Fourthly, addressing your comment on BU with a prefix to CN where there > > is only one MNN communicating with the CN. But what is the > > alternative? By sending only normal BU, it is not enough to establish > > optimized route. > > Why not? > > in the most cases (AFAICS) a given CN will only be communicating with a > single MNN of a given nemo. so in this case, you only need to tell that > CN which is the CoA of the MNN (i.e. present the CoA of the MR as the > CoA of the MNN using MIP) > for that the BU of MIP is enough. > Yes, but whose HoA should the MR use? If MR uses its own HoA, its not going to achieve anything. MR needs to tell CN more information (i.e HoA of MNN), and CN will need to verify this new info. In an extreme way of looking at it, the HoA of MNN can be treated as a prefix with length 128. Alternatively, we can go the Proxy approach, where MR send the BU on behalf of MNN (it pretends to be the MNN). Personally, something doesn't feel right to me with this approach (reminds me of NAT), but I concede that this will keep the CN unchanged. > So i would say that you could simply use mip BU unchanged. > > I see the prefix scoped BU as an optimization of the mip BU which only > benefit is to reduce the number of messages when the CN is > communicating with more than one MNN of the same nemo simoultaneously. > My question is if such optimzation worth the deployment effort. > > > > > Of-course, I understand that there is other approaches to route > > optimization that will keep CN untouched. If the final solution > > selected by the WG (after re-charter) does not require the verification > > of a network prefix, then fine, I treat my RRNP as a useful classroom > > exercise. > > > As i already mention, i think that the RRNP is a nice approach to use > RR to verify a prefix BU. However, i am not sure that the CN should do > this. > > Summarizing: > > imho the RRNP is an interesting tool to verify a prefix > imho implementing this at the CN level is not worth the effort (i.e. > the obtained benefits doesn't seems so much imho) > Thank you! Then I presume that you are all for a RO solution that will keep CN untouch. That's fine, I would want one with that feature too. However, if a RO solution impact CN, then I see no reason why CN should implement RRNP alongside with the "new RO functioanlity". /rgds /cwng From nemo-bounces@ietf.org Sun Oct 24 11:58:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08622 for ; Sun, 24 Oct 2004 11:58:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLkiZ-0000Ia-CY; Sun, 24 Oct 2004 11:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLkhr-0000DN-9D for nemo@megatron.ietf.org; Sun, 24 Oct 2004 11:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08517 for ; Sun, 24 Oct 2004 11:54:52 -0400 (EDT) Received: from bb219-74-22-112.singnet.com.sg ([219.74.22.112] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLkv6-0008Tv-Ug for nemo@ietf.org; Sun, 24 Oct 2004 12:08:38 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 254282D7861; Sun, 24 Oct 2004 23:54:33 +0800 (SGT) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] From: Chan-Wah NG To: marcelo bagnulo braun In-Reply-To: <1098632245.534.21.camel@localhost> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1098633273.534.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 24 Oct 2004 23:54:33 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit > Thank you! Then I presume that you are all for a RO solution that will > keep CN untouch. That's fine, I would want one with that feature too. > However, if a RO solution impact CN, then I see no reason why CN should > implement RRNP alongside with the "new RO functioanlity". > Sorry, the "should" in the last sentence should read "shouldn't" instead. /rgds /cwng From nemo-bounces@ietf.org Sun Oct 24 20:08:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12096 for ; Sun, 24 Oct 2004 20:08:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLsNk-0004zt-65; Sun, 24 Oct 2004 20:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLsM2-0004ne-Cx for nemo@megatron.ietf.org; Sun, 24 Oct 2004 20:04:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11850 for ; Sun, 24 Oct 2004 20:04:52 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLsZM-0008G6-02 for nemo@ietf.org; Sun, 24 Oct 2004 20:18:41 -0400 Received: from iseran.local (L071099.ppp.dion.ne.jp [211.126.71.99]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 16D1B4C0A6 for ; Mon, 25 Oct 2004 09:04:08 +0900 (JST) Date: Mon, 25 Oct 2004 08:42:33 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks Message-Id: <20041025084233.7f5b3401.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, OK, then. So, back to my question: who can involve himself to launch the discussion on the issue to the v6ops WG ML, possibly ask a slot at Washington, and reports to the NEMO WG ? If nobody does, I guess that either TJ or myself, as chairs, should do that; but I would be relieved if someone else has the interest to do so. Thierry. On Fri, 22 Oct 2004 11:16:26 -0400 "Soliman, Hesham" wrote: >=20 >=20 > > 1) doors was not discussed in any WG. It was initiated at=20 > > NEMO, then proposed to MIP6 which pointed to v6Ops. Where it=20 > > was explicitly rejected because of IPR. So the loop was=20 > > tried and done. Let's not start it again. >=20 > =3D> So it was rejected in v6ops because of IPR and this is=20 > the "all IPRs are welcome" WG ;) ?? The loop was tried and=20 > done doesn't mean we do it here. If I have an MPLS draft=20 > rejected by the MPLS WG I won't bring it to nemo. >=20 > >=20 > > 2) doors is based on to MIP/NEMO. That's an other reason why=20 > > it has been bouncing back and forth.=20 >=20 > =3D> I know this is a hard administrative problem (I don't > know why though may be no one considered transition > issues for mobility). But I don't think it's appropriate > to avoid it by taking this issue to the wrong WG. There is no > such thing as "based on nemo" AFAICS. nemo runs an extended (sometimes) > version of MIPv6. So doors is based on MIPv6. It does work for mobile > hosts doesn't it ? >=20 > >=20 > > 3) doors is a small addition to NEMO, since most of the=20 > > tooling is already there; it does the job well, and arguably=20 > > has more coverage then some other solutions; but it has been=20 > > lost in procedures for 2 years in between IETF WGs. From=20 > > that pitiful history, I'm afraid that either it happens in=20 > > NEMO or not at all. >=20 > =3D> It is a pitiful story, I agree. But I don't think doing it=20 > in nemo, where there is not much transition expertise, and=20 > where the charter is not designed for this, is the right way to > go. >=20 > Hesham >=20 > >=20 > > Pascal > >=20 > > > -----Original Message----- > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]=20 > > On Behalf Of Soliman, Hesham > > > Sent: vendredi 22 octobre 2004 03:38 > > > To: Thierry Ernst; nemo > > > Subject: RE: [nemo] NAT/PAT transfersal over IPv4 networks > > >=20 > > > Thierry, all, > > >=20 > > > I don't understand why this issue should be discussed > > > in nemo. There are certainly migration scenarios that > > > are specific to mobility and are not usually addresed > > > by current mechanisms. We had this discussion in v6ops and > > > mip6 and I think this discussion should happen in those groups. > > > Let's not discuss the same problem in many groups. > > >=20 > > > Hesham > > >=20 > > > > -----Original Message----- > > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On > > > > Behalf Of > > > > Thierry Ernst > > > > Sent: Wednesday, October 20, 2004 10:58 PM > > > > To: nemo > > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > > > > > > > > Dear all, > > > > > > > > There was this discussion in early August, so I wonder=20 > > if there is > > > > anything that we should do in the NEMO WG regarding this, > > > > and otherwise > > > > if there is anyone in our group willing to take a close look > > > > at the work > > > > done in v6ops. > > > > > > > > Thanks, > > > > Thierry. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 4 Aug 2004 07:30:03 +0100 > > > > Tim Chown wrote: > > > > > > > > > I think NAT is a consideration for the assisted tunneling > > > > requirements > > > > > analysis that is happening in v6ops. Have you read that? > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted > > > > -tunneling-requirements-00.txt > > > > > > > > > > It is NAT-PT that is pushed to the "last resort" status in > > > > v6ops (there is > > > > > a new push to write up why in an applicability statement, > > > > agreed this week). > > > > > > > > > > I can't find any active reference to "doors" - could you > > > > provide a pointer? > > > > > Looks like nemo should be talking to v6ops here :) > > > > > > > > > > thanks, > > > > > tim > > > > > > > > > > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert > > > > (pthubert) wrote: > > > > > > Well, as I understand the work being done at the MIP6 or > > > > v6Ops, Doors is not considered because of IPR. On the other > > > > hand, since the IPR encumbering is the basically same as > > > > that of nemo basic support, doors should be acceptable > > > > within Nemo. So there IS something that is Nemo=20 > > specific after all. > > > > > > > > > > > > There was a discussion in Seoul about NAT traversal (I > > > > asked Hesham over the mike) - correct me if I'm wrong - they > > > > are not covering NAT in the current ipv4/IPv6 > > > > interoperability solutions. So we end up with in one hand a > > > > non standard thing (doors) that has now been thoroughly > > > > tested and goes though all sorts of NAT including reverse > > > > and symmetrical, or in the other end the beginning of what > > > > may be a MIP remake of v6ops transition story. > > > > > > > > > > > > Could we just standardize doors so we can deliver > > > > something efficient to our customers? And then if alternates > > > > pop up, they'll have to prove they are better in that space. > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: nemo-bounces@ietf.org > > > > [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > > > > > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > > > > > To: nemo > > > > > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > > > > > > > > > > > > > Hi Will, > > > > > > > > > > > > > > Actually, the draft-iett-nemo-requirements mention NAT > > > > traversal and > > > > > > > IPv4-IPv6 transitin, so that is something we do care > > > > about. This said, > > > > > > > we concluded last year that there wasn't NEMO-specific > > > > issues. If there > > > > > > > is one, I think the WG should defintely address it. If > > > > these are issues > > > > > > > not specific to NEMO, we need to make sure these > > > > issues are addressed by > > > > > > > the relefvant WG. > > > > > > > > > > > > > > In any case, I agree with your statement. > > > > > > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > > > > > ivancic wrote: > > > > > > > > > > > > > > > Thierry and/or TJ asked if there was additional work > > > > that NEMO should > > > > > > > > address prior to closing or rechartering. > > > > > > > > > > > > > > > > I strongly believe that the group should standardize > > > > on a NAT/PAT > > > > > > > > transversal over IPv4 backbones. This will greatly > > > > increase the > > > > > > > > ability to deploy NEMO IPv6 networks. The US DoD, > > > > Japan, Korea, the > > > > > > > > European Nations and just about any Industrial > > > > nations is trying to help > > > > > > > > kick-start IPv6 deployments. However, the ISP's and > > > > industry do not yet > > > > > > > > have a good business case. Making the transission > > > > easier will help ALL > > > > > > > > of IPv6 deployments. I used some of Pascal's IPv6 > > > > NEMO code with the > > > > > > > > "Doors" protocol and demonstrated this to the CIO of > > > > the US DoD. The > > > > > > > > ability to run IPv6 over IPv4 and mix networks was > > > > very very important. > > > > > > > > > > > > > > > > See: > > > > > > > > > > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > > > > Note, the "off-site demonstrations in Washington=20 > > D.C. area" was for the > > > > > > > Office of Secretary of Defense in order to show a=20 > > migration path from > > > > > > > IPv4 to IPv6. > > > > > > > > > > > > > > > > > > > > > Will > > > > > > > > > > > > > > -- > > > > > > > ****************************** > > > > > > > William D. Ivancic > > > > > > > Phone 216-433-3494 > > > > > > > Fax 216-433-8705 > > > > > > > Lab 216-433-2620 > > > > > > > Mobile 440-503-4892 > > > > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This email may contain confidential and privileged=20 > > material for the sole use > > > of the intended recipient. Any review or distribution by=20 > > others is strictly > > > prohibited. If you are not the intended recipient please=20 > > contact the sender > > > and delete all copies. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > >=20 > >=20 >=20 From nemo-bounces@ietf.org Mon Oct 25 00:27:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29125 for ; Mon, 25 Oct 2004 00:27:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwPT-0000a6-9M; Mon, 25 Oct 2004 00:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwML-0000Ow-3E for nemo@megatron.ietf.org; Mon, 25 Oct 2004 00:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28780 for ; Mon, 25 Oct 2004 00:21:25 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwZf-0004Ik-Dt for nemo@ietf.org; Mon, 25 Oct 2004 00:35:18 -0400 Received: by wproxy.gmail.com with SMTP id 55so65562wri for ; Sun, 24 Oct 2004 21:20:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=iJDoM8sSxv0gNRL81xx8G44lbl9+ihCvmvovphrxiWmzno5AGK2EIGhPtPZ8ghW7zD0dOBdUEpN0e5OyVhWD5FDoKrwsr4lRr0I4X4mPxhnbHqt8JXC9syX3eJ8VzvGDY6fv7Czz9ewZPe2TbZiYlOUylHBUMhQo4Ps2m429i0o= Received: by 10.54.25.37 with SMTP id 37mr75794wry; Sun, 24 Oct 2004 21:20:52 -0700 (PDT) Received: by 10.54.39.17 with HTTP; Sun, 24 Oct 2004 21:20:52 -0700 (PDT) Message-ID: <2cbceb1604102421204a9a4183@mail.gmail.com> Date: Mon, 25 Oct 2004 09:50:52 +0530 From: Vikrant Kaulgud To: IETF NEMO WG Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO multihoming X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vikrant Kaulgud List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Ubiquity is one of the benefits mentioned in the draft and rightly so. Over the last few months, IEEE 802.21 has shown lot of activity in addressing media independent handoff between heterogeneous networks (http://www.ieee802.org/21) Although 802.21 work is directed towards the MN, the basic concepts would still apply to multihoming in mobile networks also. ~~~~~~~~ Regards Vikrant From nemo-bounces@ietf.org Mon Oct 25 00:51:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01548 for ; Mon, 25 Oct 2004 00:51:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwoG-0002Kf-Kq; Mon, 25 Oct 2004 00:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwlU-0001vf-PP for nemo@megatron.ietf.org; Mon, 25 Oct 2004 00:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01365 for ; Mon, 25 Oct 2004 00:47:25 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwys-0004sZ-5H for nemo@ietf.org; Mon, 25 Oct 2004 01:01:18 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9P4lP7q009952; Sun, 24 Oct 2004 21:47:26 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P4lNJQ027018; Mon, 25 Oct 2004 06:47:24 +0200 (MEST) Message-ID: <417C8586.7070203@sun.com> Date: Sun, 24 Oct 2004 21:48:06 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> In-Reply-To: <41798D9F.9040309@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Erik, > > thanks for the review. > > Erik Nordmark wrote: >> 1. Section 3 is doesn't talk about authorization for a MR routing a >> specific >> prefix. I suggest adding text after >> Update. The Home Agent sets up forwarding for each of these prefixes >> to the Mobile Router's Care-of Address. >> saying: >> , once it has verified that the mobile router is authorized to >> route to >> those prefixes. The mobile IPv6 mechanisms [1] provides for >> authentication >> and the authorization might be performed by maintaining a list of the >> prefixes which each MR (i.e., Home Address) is allowed to route. > > > we do talk about it in section 6.1.2. Yes, but in the interest of gradual disclosure as you read the document, I think it should be mentioned in section 3 as well. And, FWIW, section 6.1.2 doesn't have the word "authorized" which I think is the key concept to make clear to the reader here. > for section 3, how about just the following > > The Home Agent sets up forwarding for each of these prefixes to the > Mobile Router's Care-of Address, once it has verified that the > mobile router is authorized to route to those prefixes. Given that subsequent sections are a bit poor at using "authorized" I think it would be hard for the reader to connect the dots. If we could use "authorized", or have forward references to the relevant sections, then this would be ok. > > I am fine with the change, but this might mean sending the document > back to IANA. IANA has already done the assignments. > http://www.iana.org/assignments/mobility-parameters. and they call it > "Forwarding Setup failed". maybe we can avoid this change. (?) I don't know what the overhead would be; the IANA needs to edit the registry anyhow to enter the RFC number so perhaps they can change the name at the same time. The registry currently says 143 Forwarding Setup failed [draft-ietf-nemo-basic-support-03.txt] If it is hard to get that edit to the IANA, how about making the I-D/RFC add a parenthesis e.g. 143 Forwarding Setup Failed (prefixes missing) > we have some text in section 6.2 > > - If a Mobile Network Prefix Option is present in the Binding > Update, the prefix information for the Mobile Network Prefix is > retrieved from the Mobile Network Prefix field and the Prefix > Length field of the option. If the Binding Update contains more > than one option, the Home Agent MUST set up forwarding for all of > the Mobile Network Prefixes. If the Home Agent fails to setup > forwarding to all the prefixes listed in the Binding Update, then > it MUST NOT forward traffic to any of the prefixes, reject the > Binding Update and send a Binding Acknowledgement with status set > to 141 (Invalid Prefix). > > dont you think this is enough? I did see that text, but is it less than clear. It doesn't say "do not add the prefix to the list" but instead it says "do not forward traffic". So perhaps the reader will think it should be added to the list but not used? And this is the only place where it talks about the behavior under failure. So changing the above to say "do not add to the list" would be an improvement, but it would also make sense to state the "all or nothing" aspect of the list of prefixes earlier in the document - perhaps where the prefix option is defined. > this is fine with me. proposed text > > section 5.4.1 > > In Implicit mode, the Mobile Router interprets only error status > '140' (Mobile Router Operation not permitted) and '143' (Forwarding > Setup failed). The Mobile Router MUST treat Binding Acknowledgements > with status '141' and '142' as fatal errors, since they should not be > sent by the Home Agent in implicit mode. > > section 5.4.2 > > If the Mobile Router sent a Binding Update to Home Agent in explicit > mode then the Mobile Router interprets only error status '140' > (Mobile Router Operation not permitted), '141' (Invalid Prefix) and > '142' (Not Authorized for Prefix). The Mobile Router MUST treat > Binding Acknowledgements with status '143' as a fatal error, since it > should not sent by the Home Agent in explicit mode. ok >> when that interface is attached to a visited link. However, the >> Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor >> Solicitations received on the egress interface, for topologically >> correct addresses. >> and I have no idea what "topologically correct" means in this context. >> Shouldn't the MR just reply for the addresses it has assigned to the >> egress >> interface, just like any other node? > > well, this was put for the MR to avoid replying to any addresses that > make no sense on the visited link. for example if the MR has a HoA and > CoA configured on the egress interface, we want the MR to respond to > neighbor solicitations only for the CoA and not for the HoA. The text doesn't say that. If you want to say "SHOULD respond for the CoA and MAY respond for the HoA" you should be explicit about it. (I'm assuming you don't want to prohibit implementations from responding for the HoA, since it would be harmless.) > have you already looked at the discussion in issues #15 and #16? > http://people.nokia.net/vijayd/nemo/issues.html. Those issues are about BU/BAck - my comment was about DHAD request and reply. > if the MR gets a reply from a Home Agent with the R bit set, it doesnt > have to try anymore HAs. And what does this have to do with DHAD? My point is that the R-bit in DHAD request/reply doesn't seem to be of my use, since the MR needs to be prepared to try all the listed HAs when the R bit is not set in the reply. It is worth complicating the protocol by adding the R-bit with DHAD when the MR still needs to have code to try all HAs? I don't think so. But if this has been discussed already, I'll go read the discussion. >> >> 11. Section 9 says >> In case the Mobile >> Router receives a IP-in-IP tunneled packet from a node in the Mobile >> Network and the Mobile Router has to forward the decapsulated packet, >> it SHOULD perform the above mentioned checks on the source address of >> the inner packet. >> In don't understand why this restriction is in place. >> Wouldn't it prevent nested mobile networks where the "lower" one will use >> its home address, which the upper MR has no knowledge of, in the inner >> header? > > > please see issue 23. http://people.nokia.net/vijayd/nemo/issue23.txt. > it should be possible for the "lower" MR to send a packet you want > by setting the destination address on the outer IP header to its own > HA, instead of the "upper" MR. But the text in the draft doesn't say that this check only applies to packets addressed to one of the MRs address; I read it as applying to all IP-in-IP packets that the MR forwards. So I suspect some clarification would be helpful. >> 12. Section 9 should say something about authorization checks before >> the MR >> can cause routes to be injected by the HA, whether this is done using >> prefix >> options or running a routing protocol. > > > if the MR and the HA are running a routing protocol, Alex Zinin didnt > want any text about authorization checks. he said, the routing protocols > take care of it. for example, if all the routers in a domain are using > a shared key to authenticate routing protocol messages, the fact that > the shared key was used should be enough to authorize the routing > messages. he didnt want separate checks specified by NEMO. ok. > there was a long discussion captured in Issue 31. > > I guess we need to add the following sentence to the security > considerations section. > > If the Mobile Router sends a Binding Update with a one or more > multiple Mobile Network Prefix options, the Home Agent MUST be able > to verify that the Mobile Router is authorized for the prefixes > before setting up forwarding for the prefixes. Apart from the extra "multiple" above, it looks ok. >> 13. Appendix B.2 says: >> The following should be considered when the Home Network is >> configured for running OSPF. >> >> - The entire Home domain SHOULD NOT be configured as a single area >> if a Home Agent supports Mobile Routers. At least the Home >> Network should be configured as a separate area. >> >> - The bi-directional tunnel interfaces to the Mobile Routers should >> never be included in the same area as the backbone links. >> >> I don't understand the motivation for this? Is it performance related? > > > yes. see issue 31 again. Sorry, the RFC needs to capture and explain an issue like this. > otherwise, if there is a change in routing in one Mobile Network, the > entire Home Domain would get to know about it. if there is a change > in routing in the home domain, all the mobile routers get a link state > message. > >> If I run a flat (no areas defined) OSPF routing domain >> with 4 links and 4 prefixes, the above "SHOULD" appears to force me to >> configure areas. At a minimum the text should explain the basis for >> the considerations, and perhaps also say that they apply to large routing >> domains. > > > I can add some text to justify the two bullet points. Thanks. > The above is necessary to restrict the routing protocol messages to > the Home Network, instead of sending the messages to the entire Home > domain. With with my 4 link OSPF routing domain that would be perfectly acceptable. So the note needs to be about the increased load especially for large IGP domains. (And I think IS-IS and RIPv2 has the same issue as OSPF here.) >> 14. Since the IETF has been notified of IPR, I think that form of >> "Intellectual property statement" should be used. > > > I am a bit ignorant here. is it missing the following text? > > The IETF has been notified of intellectual property rights claimed in > regard to some or all of the specification contained in this > document. For more information consult the online list of claimed > rights. That's the gist of it (I didn't check the above text against the boilerplate). Erik From nemo-bounces@ietf.org Mon Oct 25 00:54:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01857 for ; Mon, 25 Oct 2004 00:54:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwqW-0002o0-1c; Mon, 25 Oct 2004 00:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwog-0002NG-Bf for nemo@megatron.ietf.org; Mon, 25 Oct 2004 00:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01509 for ; Mon, 25 Oct 2004 00:50:43 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLx23-0004vO-SF for nemo@ietf.org; Mon, 25 Oct 2004 01:04:36 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9P4oh7q010776; Sun, 24 Oct 2004 21:50:44 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P4ofJQ027132; Mon, 25 Oct 2004 06:50:42 +0200 (MEST) Message-ID: <417C864D.3060706@sun.com> Date: Sun, 24 Oct 2004 21:51:25 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Comments on basic support, ND, prefix BAck and R-DHAAD References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> <41799C40.9000201@iprg.nokia.com> In-Reply-To: <41799C40.9000201@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > without the 'R' bit in the DHAAD reply, a MR does not know that the > HA does not support Mobile Routers, until it sends a Binding Update > and gets a Binding Ack without the 'R' bit. it would be a good idea > for the MR to know this a bit earlier. :) So the semantics are two-fold: - the router sending the DHAD reply supports MRs - all the listed HAs support MRs? That wasn't obvious from reading the draft. Erik From nemo-bounces@ietf.org Mon Oct 25 01:03:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02345 for ; Mon, 25 Oct 2004 01:03:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwyE-0003Vw-H5; Mon, 25 Oct 2004 01:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwwF-0003Np-FC for nemo@megatron.ietf.org; Mon, 25 Oct 2004 00:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02078 for ; Mon, 25 Oct 2004 00:58:23 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLx9T-00054f-EL for nemo@ietf.org; Mon, 25 Oct 2004 01:12:16 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P4wKNH024330; Sun, 24 Oct 2004 22:58:20 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P4wHJQ027358; Mon, 25 Oct 2004 06:58:18 +0200 (MEST) Message-ID: <417C8816.2080703@sun.com> Date: Sun, 24 Oct 2004 21:59:02 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] RO taxonomy References: <41797A61.8030301@sun.com> <1098497174.24034.17.camel@localhost> In-Reply-To: <1098497174.24034.17.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Chan-Wah NG wrote: > Okay, that's thus far the most detailed description of a "RO-proxy" that > I have read, I will try to include your text into the drat if you don't > mind? Fine with me. > However, off-hand, one concern for this is security-related. The > modification of data packets (i.e. removing RH2): wouldn't it have > impact if IPSec is also used (eg. AH)? Maybe, but that has nothing to do with whether RR or something else is used for securing the signaling. If AH is used, then presumably the presence of the destination options header with the HAO is also part of the integrity check. So it would be symmetric that a proxy needs work when AH is in use??? The proxy could advance the RH2 instead of removing it, which would make the destination happy and AH would verify correctly. But that doesn't handle the need to insert the HAO for packets in the reverse direction; I guess a proxy could be built so that a packet from a LMN which has AH after the IP header will be reverse tunneled instead of having the HAO added. > Side-tracking a bit, I have written another draft (draft-ng-nemo-rrnp) > on this. Should you be not too busy, a comment or two from you would be > invaluable and appreciated. I'll have a look. Erik From nemo-bounces@ietf.org Mon Oct 25 01:19:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03675 for ; Mon, 25 Oct 2004 01:19:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxFS-00069W-Tr; Mon, 25 Oct 2004 01:18:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxE0-0005vv-MQ for nemo@megatron.ietf.org; Mon, 25 Oct 2004 01:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03599 for ; Mon, 25 Oct 2004 01:16:55 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxRO-0005Ps-JC for nemo@ietf.org; Mon, 25 Oct 2004 01:30:46 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P5GsNH001749; Sun, 24 Oct 2004 23:16:54 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P5GpJQ027887; Mon, 25 Oct 2004 07:16:52 +0200 (MEST) Message-ID: <417C8C6F.8070705@sun.com> Date: Sun, 24 Oct 2004 22:17:35 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> In-Reply-To: <1098632245.534.21.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun , IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Chan-Wah NG wrote: I had a quick look at the draft. Trying a random address in the prefix is neat, but might be insufficient. For instance, if a MR is assigned a /64 prefix, then with probability 1/2 it can use the /63 prefix (and steal its "neighbors" packets). So it is only a question of how many times it needs to try before it is succesful. If we believe "try a random" is in general good enough, then we can modify the random calculation to be less random: If the prefix is N bits, then form the test address by inverting the N+1'th bit and making the remainder of the test address be random. Thus in the above /63 example, the test address would always come from the "neighbors" /64 prefix and the attacker would never succeed. This still makes it possible for two friends with different prefixes to claim a the whole range of addresses between them; If A has prefix 1:2:3:0xyz:/64 and B has prefix 1:2:3:8abc:64 then with some non-zero probability, when B sends a HoTI for the /48 prefix with a non-zero probability the NPT would be sent to A, who can forward it to B. We can reduce that probability by sending more than one NPT for different addresses in the prefix. But until we understand the utility of CNs receiving BUs for prefixes, this is rather academic. Erik From nemo-bounces@ietf.org Mon Oct 25 03:04:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25068 for ; Mon, 25 Oct 2004 03:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLysL-0005oA-DP; Mon, 25 Oct 2004 03:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyrT-0005kU-BQ for nemo@megatron.ietf.org; Mon, 25 Oct 2004 03:01:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24866 for ; Mon, 25 Oct 2004 03:01:45 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLz4o-0007J3-WC for nemo@ietf.org; Mon, 25 Oct 2004 03:15:38 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 032B96217; Sun, 24 Oct 2004 23:59:59 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39569-06; Sun, 24 Oct 2004 23:59:58 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 167D26229; Sun, 24 Oct 2004 23:59:58 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id DB6156217; Sun, 24 Oct 2004 23:59:46 -0700 (PDT) In-Reply-To: <2cbceb1604102421204a9a4183@mail.gmail.com> References: <2cbceb1604102421204a9a4183@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] NEMO multihoming Date: Mon, 25 Oct 2004 00:01:12 -0700 To: Vikrant Kaulgud X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Are you making some sort of suggestion, or what is the goal of pointing out this work? 802.21 and NEMO are not working at solving the same problem, and I don't see how media-independent handovers relate to NEMO multihoming. -TJ On Oct 24, 2004, at 9:20 PM, Vikrant Kaulgud wrote: > Hi, > > Ubiquity is one of the benefits mentioned in the draft and rightly so. > Over the last few months, IEEE 802.21 has shown lot of activity in > addressing media independent handoff between heterogeneous networks > (http://www.ieee802.org/21) > > Although 802.21 work is directed towards the MN, the basic concepts > would still apply to multihoming in mobile networks also. > > ~~~~~~~~ > Regards > Vikrant > > From nemo-bounces@ietf.org Mon Oct 25 03:09:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25385 for ; Mon, 25 Oct 2004 03:09:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyxC-0006Bp-4P; Mon, 25 Oct 2004 03:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLywx-00069G-I8 for nemo@megatron.ietf.org; Mon, 25 Oct 2004 03:07:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25258 for ; Mon, 25 Oct 2004 03:07:25 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzAM-0007PT-Aq for nemo@ietf.org; Mon, 25 Oct 2004 03:21:18 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2004 09:23:39 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9P76TT1011253; Mon, 25 Oct 2004 09:06:52 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 09:06:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Radio interface and Tree Discovery [wasRE: [nemo] NEMO multihoming] Date: Mon, 25 Oct 2004 09:06:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC345405@xmb-ams-337.emea.cisco.com> Thread-Topic: Radio interface and Tree Discovery [wasRE: [nemo] NEMO multihoming] Thread-Index: AcS6SwfuA+TbVSx8QcGfePytG4Vs5QAE48Jw From: "Pascal Thubert \(pthubert\)" To: "Vikrant Kaulgud" , "IETF NEMO WG" , "Gupta, Vivek G" X-OriginalArrivalTime: 25 Oct 2004 07:06:48.0445 (UTC) FILETIME=[31DE1AD0:01C4BA61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Vikrant: As I understand it, 802.21 is defining a super radio layer (2.5 or less :) that would perform intelligent handover over various radio technologies. At the moment, though: L3 triggers (e.g. RAs in the NEMO case, or IGP messages) are ill/not defined. There is no way for the access router to push them to the AP, for APs to send the RAs as class1 on .11, or for the MN to know about APs other then the one it is associated to. Even if that was available (MN can get RAs from all APs in range), there's no control from L3 to force an association to the best AP, in terms of reachability, from MN standpoint. Say there was, there's still a missing link for NEMO basic support to operate efficiently. That's extended reachability information, inside the RAs, besides plain ND. IMHO, there are 2 drafts that provide for this in different contexts: - For plain MN and multihoming, we have draft-ietf-ipv6-router-selection-03.txt that gives us reachability information in a routed topology. - For Nested NEMO, we have draft-thubert-tree-discovery-01.txt that enables the selection of the AR that builds the shallowest tree of Mobile Routers to the Infrastructure (and much more :) My thinking is that it's good for us to interact with 802.21 to get the complete picture. But also and mostly, our responsibility is to move forward with our own side of the 2.5 boundary, and in particular for NEMO, there's work to do on the TD technology. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vikrant Kaulgud > Sent: lundi 25 octobre 2004 06:21 > To: IETF NEMO WG > Subject: [nemo] NEMO multihoming >=20 > Hi, >=20 > Ubiquity is one of the benefits mentioned in the draft and rightly so. > Over the last few months, IEEE 802.21 has shown lot of activity in > addressing media independent handoff between heterogeneous networks > (http://www.ieee802.org/21) >=20 > Although 802.21 work is directed towards the MN, the basic concepts > would still apply to multihoming in mobile networks also. >=20 > ~~~~~~~~ > Regards > Vikrant From nemo-bounces@ietf.org Mon Oct 25 03:43:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27702 for ; Mon, 25 Oct 2004 03:43:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzUF-0000DV-VH; Mon, 25 Oct 2004 03:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzTt-0000Ah-KG for nemo@megatron.ietf.org; Mon, 25 Oct 2004 03:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27578 for ; Mon, 25 Oct 2004 03:41:27 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzhI-0007xW-BJ for nemo@ietf.org; Mon, 25 Oct 2004 03:55:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2004 09:57:39 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9P7eKT7017508; Mon, 25 Oct 2004 09:40:52 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 09:40:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO taxonomy Date: Mon, 25 Oct 2004 09:40:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC345429@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS4pPFHUVSv2UAWQJGxfCX20o2frQBvi4xA From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah NG" , "Erik Nordmark" X-OriginalArrivalTime: 25 Oct 2004 07:40:49.0784 (UTC) FILETIME=[F299B780:01C4BA65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Chan-Wah, Erik: What I meant here is that the RR test and the RH2 support are meant to = check and use the collocation of the HoA and the CoA in a same box. The = best the test operates, the less chances this proxying has to work. If = the test was perfect, it would not.=20 What Erik describes here is very close (if not identical) to the MIRON = project (copying Carlos). There's a good chance it works in many cases, = at least with the current RR test. I do not want to start again all the = discussion we had on this ML. The thread was "RO between MR and CN", and = I listed my concerns on the 10th of October. In short, I believe that the devil is in the details. I like the wording = "packet inspection" ;) , but the words snooping and hacking apply very = well too. I see it falling short after some time. The MR will end up = having to lookup every packets for source and destination, and modify = all the RO'ed packets. Also, it has to sort out whether the MNN is = managing its own mobility or security, or if there's another MR or RO = solution of some sorts that would defeat its action. I'm not too positive on the approach. I think that at least we should = allow normal tunnelling between MR and CN to get there, and I agree with = CW that we should revisit the RR test. RR is a Work In Progress anyway. = So I'm not necessarily for keeping the CN unchanged whatever the cost. ITOH, there are alternatives to the end-to-end RO. For instance, global = HAHA proposes a 'pth improvement" between fixed proxies, distributed in = the Internet, as an alternate to RO. No Home address or RH2, but route = projections and tunnels. This also protects the MNN and the CN. In fact, = they both are plain non MIP nodes. You might want to have a glance at: http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt= =20 Note that this is only a draft 00 and there's still a lot of work to do. = Pascal > -----Original Message----- > From: Chan-Wah NG [mailto:cwng@psl.com.sg] > Sent: samedi 23 octobre 2004 04:06 > To: Erik Nordmark > Cc: Pascal Thubert (pthubert); IETF NEMO WG > Subject: Re: [nemo] RO taxonomy >=20 > Hello Erik, >=20 > Thank you for the comments, as we currently updating the draft (almost = a > complete re-structuring), and your comments are very useful. >=20 > More responses below inline. >=20 > /rgds > /cwng >=20 > On Sat, 2004-10-23 at 05:23, Erik Nordmark wrote: > > Thanks for writing the RO taxonomy draft - it introduces some issues > > which makes it easier to discuss them without diving into the = solutions. > > > > I have a couple of high-level comments and concerns. > > > > The draft concludes, without any motivation, that the RR test = prevents > > having a MR "proxy" mobility signalling for a LFN. > > I don't see why this would be the case. To perform such proxying one > > needs know that there is at most on MR being the proxy i.e. can't = have > > two MRs serve the mobile network with some packets to/from the LFN > > passing through one and some through the other. And then the MR = needs to > > - determine when to perform RO (e.g. by counting packets in the = flows) > > - send CoTI and HoTI on behalf of the LFN > > - receive the CoT (which is trivial since it is address to the MR) > > - receive the HoT (which requires packet inspection of the > > packets addressed to the LFN) > > - send the BU and receive the BA > > - insert the HAO in packets from the LFN > > - remove the RH type 2 in packets to the LFN > > - adjust ICMP packet too big to account for the inserts and = removes it > > performs > > - both the MTU and the "packet in error" needs to be adjusted > > > > I can see how such a proxy can be built, and I don't see it being = much > > harder with RR then with other forms of security like CGA or > > infrastructure based ones. > > >=20 > Okay, that's thus far the most detailed description of a "RO-proxy" = that > I have read, I will try to include your text into the drat if you = don't > mind? >=20 > However, off-hand, one concern for this is security-related. The > modification of data packets (i.e. removing RH2): wouldn't it have > impact if IPSec is also used (eg. AH)? >=20 > > > > The draft seems to both assume that it is ok to modify CNs to handle > > Nemo, and that it is necessary to do such modifications. > > I think it is possible to do both MR proxy RO (for LFNs) and VMN RO > > without any modifications to the CNs; they would just do MIPv6 CN as > > currently defined. > > Thus the text which says > > 2) The RR test has no negotiable option and is not open for > > extension, and > > is pointing out a feature and not a bug. > > > OK. >=20 > > > > In section 2, the paragraph > > This section covers the case where the Route Optimization is > > performed between the MR and the correspondent nodes which = mobile > > network nodes (MNNs) are communicating with. This scenario is = useful > > when a lot of MNNs in a mobile network is communicating with a = few > > corresponding nodes. In such cases the MR only needs to send = one > > binding update (BU) to optimized the route between CN and a few = MNNs. > > seems to imply that a BU to a CN for a prefix is somehow possible. > > > > When the CN and mobile network are in different administrations it = is > > extremely unlikely that there would be an infrastructure which would > > allow the CN to make reasonable authorization decisions for a full = prefix. > > For instance, the current RR scheme could only derive such = authorization > > without loss of security if the RR test is applied to all of the 2^N > > addresses in the prefix. Similarely for CGA scheme, each individual > > address would need to be verified. > > So why are you implicitly assuming that this is feasible and = desirable? > > >=20 > In the upcoming version of the draft, we indeed will point out this > concern of verification of prefix "ownership". >=20 > Side-tracking a bit, I have written another draft (draft-ng-nemo-rrnp) > on this. Should you be not too busy, a comment or two from you would = be > invaluable and appreciated. >=20 > > Section 7 says: > > 3) The HaO and RH type 2 are designed for a collocated CareOf > > Address. More specifically, they are not designed to be = multi-hop as > > RRH is, and not extensible, though RRH can be considered as an > > extension of HAO. > > I think somebody pointed that out in > > draft-nordmark-mobileip-mipv6-hindsight-00.txt :-) > > > Ok. >=20 > > > > I think there is important consideration which has a large effect on > > the possible solutions for both VMNs and for nesting; whether or not = the > > AR will delegate a prefix to the MR. > > If the MR receives a single address from the AR, then this has to be > > used as a "shared CoA" for all devices in the mobile network which > > wishes their packets to travel directly to the mobile network. > > But if the MR receives a prefix from the AR that it delegates to the > > non-LFN nodes, then each such Nemo aware node can have its own CoA = which > > represents the shortest path via the MR. > > It might be useful to represent this somehow in the taxonomy. > > > Right, with the recent exchanges of mails on prefix delegation, I am > starting to think that this class of approach may deserve its own > separate section in the taxonomy. Previously, it was mentioned as one > approach in "Nested Network Optimization". >=20 > /rgds > /cwng From nemo-bounces@ietf.org Mon Oct 25 05:08:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02835 for ; Mon, 25 Oct 2004 05:08:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0oS-0006sw-AZ; Mon, 25 Oct 2004 05:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0o2-0006pI-JQ for nemo@megatron.ietf.org; Mon, 25 Oct 2004 05:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02734 for ; Mon, 25 Oct 2004 05:06:12 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM11L-00014Y-0w for nemo@ietf.org; Mon, 25 Oct 2004 05:20:07 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9P97bG2024394; Mon, 25 Oct 2004 02:07:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i9P950Jv021228; Mon, 25 Oct 2004 04:05:00 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E9CB985C461; Mon, 25 Oct 2004 11:06:10 +0200 (CEST) Message-ID: <417CC1FD.1050009@motorola.com> Date: Mon, 25 Oct 2004 11:06:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, ND, prefix-BAck References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> In-Reply-To: <41798759.5000303@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig158985FCFFABBBC1BC96D523" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig158985FCFFABBBC1BC96D523 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Alexandru Petrescu wrote: > >> It's never been clear to me by RFC3775. But I'm sure MR must not >> reply for the Home Address if MR not on the home link, hence >> "topologically correct". Maybe removing "topologically correct". > > I'd suggest replacing it with "the CoA" or "the addresses assigned to > the egress interface". > > I don't think there is any harm in responding for the HoA while away > from home, since nobody should be sending NSs for it. A host sending periodic NA's for the Home Address while away from home has the effect that its neighbours on the visited link fill their cache with this address. Further effect is that when such a neighbour writes to the Home Address the communication doesn't go to MR's HA, but directly to the MR. Anyways, if we let MR send NA's for HoA on the visited link these should at least have R-bit unset (while at home it should be set). > And RFC 3775 leaves that open. So some implementations might, and > others might not because they have assigned the HoA to some tunnel > interface when they moved away from home. I see this. >> This has not been discussed, IIRC. It occured to me once, but did >> not want to complicate things. This is all in Error Processing. >> This must be as simple as possible. I was lazy. If more people >> think we should include this feature, ok. Including prefixes maybe >> it's too long, maybe indexing them and exchange indexes to point >> the errors. > > I think it might be a benefit in debugging during interop testing, > but I don't think it would be useful in operational settings. So do you mean (1) we should enhance the BAck to put prefixes in it, or (2) should we enhance the BU first with prefix indexing and then put indexes in the BAck? I think the latter method saves on bandwidth but the former method maybe it is more helpful to have prefixes visible in packet dumpers. Should this be in a Binding Error instead. The prefix-BAck is supposedly used only in Explicit mode. Alex --------------enig158985FCFFABBBC1BC96D523 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfMICMmC0w56zj54RAnMIAKCxZ/7zD4Xil+AExN8Mb1aN7R6ohACdF2HN eHqE7IpTpWhKmPYhcx//Uck= =y5Dk -----END PGP SIGNATURE----- --------------enig158985FCFFABBBC1BC96D523-- From nemo-bounces@ietf.org Mon Oct 25 05:25:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04254 for ; Mon, 25 Oct 2004 05:25:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM14t-0001U6-OY; Mon, 25 Oct 2004 05:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM14V-0001R3-KC for nemo@megatron.ietf.org; Mon, 25 Oct 2004 05:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04158 for ; Mon, 25 Oct 2004 05:23:21 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM1Hu-0001Ry-O5 for nemo@ietf.org; Mon, 25 Oct 2004 05:37:16 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id i9P9OMQT022028; Mon, 25 Oct 2004 02:24:22 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i9P9KqNM029230; Mon, 25 Oct 2004 04:20:53 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 53C8085C461; Mon, 25 Oct 2004 11:23:17 +0200 (CEST) Message-ID: <417CC5FE.6010709@motorola.com> Date: Mon, 25 Oct 2004 11:23:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> In-Reply-To: <417C8C6F.8070705@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9454474A5CC2EEC1F736007F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: marcelo bagnulo braun , IETF NEMO WG , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9454474A5CC2EEC1F736007F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > We can reduce that probability by sending more than one NPT for > different addresses in the prefix. Or we can reserve an address out of a prefix as _the_ address that corresponds to testing that entire prefix. > But until we understand the utility of CNs receiving BUs for prefixes, > this is rather academic. One utility would be to get rid of encapsulation MR-CN. This encapsulation happens supposedly because MR can not modify the source address of packets from LFN to CN after the enhanced-RR procedure (the one adding the DO and RH). Or am I wrong to think this encapsulation is absolutely necessary? Alex --------------enig9454474A5CC2EEC1F736007F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfMYFMmC0w56zj54RAoojAJoDgR/wDV7InRcALna+i5sUfDub8wCbBXbl sSEBhQDvDD/LeXoNbsU5f4s= =n9h3 -----END PGP SIGNATURE----- --------------enig9454474A5CC2EEC1F736007F-- From nemo-bounces@ietf.org Mon Oct 25 08:20:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20079 for ; Mon, 25 Oct 2004 08:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3o8-0007ws-3i; Mon, 25 Oct 2004 08:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3m9-0007qy-5h for nemo@megatron.ietf.org; Mon, 25 Oct 2004 08:16:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19829 for ; Mon, 25 Oct 2004 08:16:35 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3zU-0005JH-Ci for nemo@ietf.org; Mon, 25 Oct 2004 08:30:30 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9PCD4Sk003748; Mon, 25 Oct 2004 20:13:04 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 14809B240CF; Mon, 25 Oct 2004 20:19:02 +0800 (SGT) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <417CC5FE.6010709@motorola.com> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> <417CC5FE.6010709@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1098706741.10461.77.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 25 Oct 2004 20:19:01 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun , IETF NEMO WG , Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2004-10-25 at 17:23, Alexandru Petrescu wrote: > Erik Nordmark wrote: > > We can reduce that probability by sending more than one NPT for > > different addresses in the prefix. > > Or we can reserve an address out of a prefix as _the_ address that > corresponds to testing that entire prefix. > One address might not be enough, if we allow variable length prefix. But that is a good point. Question is if the verification of some specific addresses can ensure the whole prefix. One must consider the scenario Erik points out where the attacker and some friends collaborate to snoop part of a /48 prefix, where they only own some of the /64 prefixes out of the /48 prefix. > > But until we understand the utility of CNs receiving BUs for prefixes, > > this is rather academic. > > One utility would be to get rid of encapsulation MR-CN. Now, that is one utility I have not thought of. Care to share with us what you have in mind? /rgds /cwng From nemo-bounces@ietf.org Mon Oct 25 10:06:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27387 for ; Mon, 25 Oct 2004 10:06:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5Sh-0003ZY-Ln; Mon, 25 Oct 2004 10:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5SR-0003RE-HX for nemo@megatron.ietf.org; Mon, 25 Oct 2004 10:04:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27175 for ; Mon, 25 Oct 2004 10:04:20 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5ft-0007Kg-OK for nemo@ietf.org; Mon, 25 Oct 2004 10:18:18 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i9PDukJC000633; Mon, 25 Oct 2004 06:56:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i9PC3sgr023812; Mon, 25 Oct 2004 07:03:55 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2051A8859AE; Mon, 25 Oct 2004 16:04:17 +0200 (CEST) Message-ID: <417D07DA.3090207@motorola.com> Date: Mon, 25 Oct 2004 16:04:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> <417CC5FE.6010709@motorola.com> <1098706741.10461.77.camel@localhost> In-Reply-To: <1098706741.10461.77.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig003C323E80FB7827D7FF93A1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: marcelo bagnulo braun , IETF NEMO WG , Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig003C323E80FB7827D7FF93A1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: >> Erik Nordmark wrote: >> >>> We can reduce that probability by sending more than one NPT for >>> different addresses in the prefix. >> >> Or we can reserve an address out of a prefix as _the_ address that >> corresponds to testing that entire prefix. >> > One address might not be enough, if we allow variable length prefix. > But that is a good point. Question is if the verification of some > specific addresses can ensure the whole prefix. One must consider > the scenario Erik points out where the attacker and some friends > collaborate to snoop part of a /48 prefix, where they only own some > of the /64 prefixes out of the /48 prefix. I'm just vehiculating the idea that out of any prefix a "dedicated" "IANA-reserved" address can be used for RR verification. It is only an idea and Erik's point is right. >>> But until we understand the utility of CNs receiving BUs for >>> prefixes, this is rather academic. >> >> One utility would be to get rid of encapsulation MR-CN. > > Now, that is one utility I have not thought of. Care to share with > us what you have in mind? Sorry, I did not mean to be laconic and I've probably not identified the exact utility as perceived in your context. I meant that if CN has a pair in a cache with a prefix matching the address of LFN (LFN has only one address) and the CoA of MR then CN would not need to encapsulate (adding a new base header) when writing to LFN, just use the RH. Mobile IPv6 uses RH from CN to MN (MH!) so it would be also better to use it from CN to MR, instead of new-base-header encapsulation. Also meant that it would be more efficient to have a unique entry in this cache, of the form prefix-MRCoA, that would be used for all LFN's instead of several entries, one per LFN. I hope I'm not far away from the discussion, sorry if that's the case. Alex --------------enig003C323E80FB7827D7FF93A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfQfgMmC0w56zj54RAolYAKDmu3I+NAxG88g3rbCfbQTRf8IuJACfaFwQ Ji0zWIJ3kgSVWDrY6a3AMxA= =Gtny -----END PGP SIGNATURE----- --------------enig003C323E80FB7827D7FF93A1-- From nemo-bounces@ietf.org Mon Oct 25 10:27:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29384 for ; Mon, 25 Oct 2004 10:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5jd-0007fW-Ct; Mon, 25 Oct 2004 10:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5ib-0007Vt-Bu for nemo@megatron.ietf.org; Mon, 25 Oct 2004 10:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28799 for ; Mon, 25 Oct 2004 10:21:02 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5w0-0007c4-By for nemo@ietf.org; Mon, 25 Oct 2004 10:34:59 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id D517D2D319; Mon, 25 Oct 2004 16:20:35 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id 06C1E2D319; Mon, 25 Oct 2004 16:20:34 +0200 (CEST) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <417D07DA.3090207@motorola.com> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> <417CC5FE.6010709@motorola.com> <1098706741.10461.77.camel@localhost> <417D07DA.3090207@motorola.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Y+1IyJR31MFd2yxSbFUp" Organization: Universidad Carlos III de Madrid Message-Id: <1098714065.2432.113.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 25 Oct 2004 16:21:06 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: marcelo bagnulo braun , IETF NEMO WG , Erik Nordmark , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Y+1IyJR31MFd2yxSbFUp Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, > Sorry, I did not mean to be laconic and I've probably not identified the > exact utility as perceived in your context. >=20 > I meant that if CN has a pair in a cache with a prefix matching the > address of LFN (LFN has only one address) and the CoA of MR then CN > would not need to encapsulate (adding a new base header) when writing to > LFN, just use the RH. >=20 > Mobile IPv6 uses RH from CN to MN (MH!) so it would be also better to > use it from CN to MR, instead of new-base-header encapsulation. I think that the same RH can be used in this case too, so you don't need to introduce changes in the CN operation. >=20 > Also meant that it would be more efficient to have a unique entry in > this cache, of the form prefix-MRCoA, that would be used for all LFN's > instead of several entries, one per LFN. In order to do that you'd need to change the CN operation. Do you think it's worth to do that? IMHO, maybe there are not many cases in which a CN is talking to many LFNs belonging to the same NEMO. What do you think? Kind Regards, Carlos >=20 > I hope I'm not far away from the discussion, sorry if that's the case. >=20 > Alex --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-Y+1IyJR31MFd2yxSbFUp Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBfQvR5vKyPtrWqkARAmKRAKCbhMIgoFs7lKz5s/loqYpxyVzFvwCgkPNH GpQ20CdoDoONkM6Qb72EAkI= =aVh5 -----END PGP SIGNATURE----- --=-Y+1IyJR31MFd2yxSbFUp-- From nemo-bounces@ietf.org Mon Oct 25 12:27:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11780 for ; Mon, 25 Oct 2004 12:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7eR-0005bx-34; Mon, 25 Oct 2004 12:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7WD-0003cE-KC for nemo@megatron.ietf.org; Mon, 25 Oct 2004 12:16:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10601 for ; Mon, 25 Oct 2004 12:16:22 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7jh-0001yk-5z for nemo@ietf.org; Mon, 25 Oct 2004 12:30:21 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9PGGNs3025593; Mon, 25 Oct 2004 09:16:23 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGGKJQ012176; Mon, 25 Oct 2004 18:16:21 +0200 (MEST) Message-ID: <417D2701.1060602@sun.com> Date: Mon, 25 Oct 2004 09:17:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Comments on basic support, ND, prefix-BAck References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> <417CC1FD.1050009@motorola.com> In-Reply-To: <417CC1FD.1050009@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > A host sending periodic NA's for the Home Address while away from home > has the effect that its neighbours on the visited link fill their cache > with this address. Further effect is that when such a neighbour writes > to the Home Address the communication doesn't go to MR's HA, but > directly to the MR. > > Anyways, if we let MR send NA's for HoA on the visited link these should > at least have R-bit unset (while at home it should be set). Are we changing the subject? The previous subject was responding to Neighbor Solicitations for the HoA while away from home, which I argue is harmless. On the subject of periodic unsolicited NAs for the HoA (which is NOT what the text in the draft is about) I think periodic unsolicited NAs is a bad idea in general (but they are not explicitly prohibited in RFC 2461 I think), and it would be bad to do those for a HoA while away from home as you point out. > So do you mean (1) we should enhance the BAck to put prefixes in it, or > (2) should we enhance the BU first with prefix indexing and then put > indexes in the BAck? I think the latter method saves on bandwidth but > the former method maybe it is more helpful to have prefixes visible in > packet dumpers. *If* you want to add this, putting the prefix options that failed in the BAck would be the easiest and it doesn't make any packet any larger when things are working (since it that case all prefixes were ok). > Should this be in a Binding Error instead. I don't think so, since that is today only sent in response to data packets and not in response to Binding Updates. Erik > The prefix-BAck is supposedly used only in Explicit mode. > > Alex From nemo-bounces@ietf.org Mon Oct 25 12:48:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13101 for ; Mon, 25 Oct 2004 12:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7os-0006zt-Dh; Mon, 25 Oct 2004 12:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7iY-00061I-GT for nemo@megatron.ietf.org; Mon, 25 Oct 2004 12:29:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11866 for ; Mon, 25 Oct 2004 12:29:07 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7w2-0002H5-E8 for nemo@ietf.org; Mon, 25 Oct 2004 12:43:06 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9PGT6s3002754; Mon, 25 Oct 2004 09:29:07 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGT3JQ013671; Mon, 25 Oct 2004 18:29:04 +0200 (MEST) Message-ID: <417D29FD.2040907@sun.com> Date: Mon, 25 Oct 2004 09:29:49 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> <417CC5FE.6010709@motorola.com> In-Reply-To: <417CC5FE.6010709@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun , IETF NEMO WG , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Or we can reserve an address out of a prefix as _the_ address that > corresponds to testing that entire prefix. For every of the 127 possible prefix lengths and for all parts of the IPv6 address space? So if I want to do a BU for 0::/3, you need to reserve how much of the address space? Seems like a lot. >> But until we understand the utility of CNs receiving BUs for prefixes, >> this is rather academic. > > > One utility would be to get rid of encapsulation MR-CN. This > encapsulation happens supposedly because MR can not modify the source > address of packets from LFN to CN after the enhanced-RR procedure (the > one adding the DO and RH). Or am I wrong to think this encapsulation is > absolutely necessary? I don't understand. The source address needs to be correct with respect to the place where the packets are injected in the network to prevent it being filtered *and* the source address needs to match the ULP (e.g. TCP) connection state at the receiver. Thus the only way to avoid carrying two IPv6 addresses for the sender is that the receiver is aware of which address the ULP needs (based on some state setup between the two endpoints) - this was first suggested for MIPv6 in the ZOD draft. And multi6 is looking at exactly that approach. But I don't see what this has to do with a BU per prefix since the state setup must be for each pair of hosts in order to be robust against packet loss and node failures/state loss. Erik From nemo-bounces@ietf.org Mon Oct 25 13:15:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15026 for ; Mon, 25 Oct 2004 13:15:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8Jn-0005AR-0K; Mon, 25 Oct 2004 13:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8AQ-0003zS-Fz for nemo@megatron.ietf.org; Mon, 25 Oct 2004 12:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13695 for ; Mon, 25 Oct 2004 12:57:55 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Nt-0002pI-F1 for nemo@ietf.org; Mon, 25 Oct 2004 13:11:54 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PGuhNH024513; Mon, 25 Oct 2004 10:56:44 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PGueJQ015568; Mon, 25 Oct 2004 18:56:41 +0200 (MEST) Message-ID: <417D3076.2020109@sun.com> Date: Mon, 25 Oct 2004 09:57:26 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC345429@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC345429@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > What I meant here is that the RR test and the RH2 support are meant to check and use the collocation of the HoA and the CoA in a same box. The best the test operates, the less chances this proxying has to work. If the test was perfect, it would not. I disagree because the IETF doesn't specify the behavior of "boxes" - it specifies functional behavior. Ignoring Nemo, for instance there is nothing that prevents the logical notion of a "host" to have its TCP/IP stack in one box (separate power supply etc) 10 meters away from the processors where the applications run. The RR test is fundamentally about authorization, where we assume that the host (again, a function and not a box) to which the HoA is assigned is authorized to send packets for the HoA somewhere else. That doesn't mean that it isn't (and shouldn't be) possible for the host to delegate the MIPv6 handling to a proxy function, which might be running in a different box. But this is fundamental to the authorization issue; has nothing to do with the actual mechanism to show authorization whether RR, CGA, some manually per-established keys. > What Erik describes here is very close (if not identical) to the MIRON project (copying Carlos). There's a good chance it works in many cases, at least with the current RR test. I do not want to start again all the discussion we had on this ML. The thread was "RO between MR and CN", and I listed my concerns on the 10th of October. I'll go have a peek at MIRON. > In short, I believe that the devil is in the details. I like the wording "packet inspection" ;) , but the words snooping and hacking apply very well too. I see it falling short after some time. The MR will end up having to lookup every packets for source and destination, and modify all the RO'ed packets. I agree that any three-party approach, i.e. anything involving proxies, is more complex than a two party approach. But if we want to solve RO between a LFN (vanilla IPv6 with no mobility support) and a vanilla MIPv6 CN, then it is clear that something in between those two needs to do some work i.e. a proxy of some form is necessary. So the first question is how important it is solve this aspect of the problem, and then we can see how to construct the best (but perhaps not perfect) proxy solution. And if you can modify the LFN then you can probably design things to avoid a proxy. > Also, it has to sort out whether the MNN is managing its own mobility or security, or if there's another MR or RO solution of some sorts that would defeat its action. A MNN wouldn't in general know that there is a MR; it is only for Nemo-aware nodes that this question comes up. I think this can be handled without interference from the proxy function. The Nemo-aware node has two choices in terms of its CoA; it can share the MR's CoA or it can get a CoA for itself (from some prefix delegated from the AR to the MR and advertised to the Nemo-aware nodes for instance). If it shares the CoA then the node needs to do some signaling with the MR (because the MR would need to know where to forward the packets it receives on its CoA and the HoA of the MNN might not be sufficient for this in the case of a VMN). Thus, some form of binding update needs to be sent from the MNN to the MR. As a result the MR knows not to apply the proxy function for that HoA. If the MNN has its own CoA, then the proxy function shouldn't be triggered because the packets are from an address space the MR delegated from the AR to the mobile network. > I'm not too positive on the approach. I think that at least we should allow normal tunnelling between MR and CN to get there, Of course. What we are talking about is RO which is a performance optimization and not a way to accomplish basic connectivity. > and I agree with CW that we should revisit the RR test. RR is a Work In Progress anyway. So I'm not necessarily for keeping the CN unchanged whatever the cost. I think you are barking up the wrong proverbial tree. Your issue isn't with the RR test - it is with the explicit assumption that the "owner" of the HoA is the node authorized to say where packets for its HoA are sent. So replacing the RR test with something that still has at least the same strength would never make the fundamental issue you have go away. One could attempt to build solutions which makes delegating the authorization to a 3rd party easier, but that still only solves the authorization aspect of the proxy and does nothing about its impact on the data path with HAO and RH2. Note that I'm not saying proxies are easy or a good idea; there is a long list of things they need to do correctly and things probably will not work when there are multiple paths so that a single proxy do not see all packets between a LFN and CN. What I am saying is that no matter what you replace the RR test with you will have the same fundamental issues with proxies. Erik From nemo-bounces@ietf.org Mon Oct 25 13:31:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16645 for ; Mon, 25 Oct 2004 13:31:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8Yl-0007pN-N7; Mon, 25 Oct 2004 13:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8Wx-0007G4-TN for nemo@megatron.ietf.org; Mon, 25 Oct 2004 13:21:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15532 for ; Mon, 25 Oct 2004 13:21:12 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8kS-0003JQ-Bp for nemo@ietf.org; Mon, 25 Oct 2004 13:35:12 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9PHMbG2023992; Mon, 25 Oct 2004 10:22:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i9PHLCbs025796; Mon, 25 Oct 2004 12:21:12 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id ADD9D8859AE; Mon, 25 Oct 2004 19:21:11 +0200 (CEST) Message-ID: <417D3602.5050105@motorola.com> Date: Mon, 25 Oct 2004 19:21:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, ND, prefix-BAck References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> <417CC1FD.1050009@motorola.com> <417D2701.1060602@sun.com> In-Reply-To: <417D2701.1060602@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig89D6B6ED344E1F7E62644031" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89D6B6ED344E1F7E62644031 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Are we changing the subject? The previous subject was responding to > Neighbor Solicitations for the HoA while away from home, which I > argue is harmless. No, I'm not changing subject, I stay within the section of how MR acts ND-wise. I see your point, capacity of responding to NS's for the HoA is harmless in the visited network simply because there are no such NS's. So yes, I agree the current text "for topologically correct addresses" appears superfluous. So I think it is still good to forbid MR to send NA's for any address assigned on the egress interface other than the Care-of Address valid on the visited link. > *If* you want to add this, putting the prefix options that failed in > the BAck would be the easiest and it doesn't make any packet any > larger when things are working (since it that case all prefixes were > ok). I see. I personally do not need this feature because I favor a lot the implicit mode. If on the other hand the group feels this is needed I can understand why: prefix-BAck may help a lot in debugging when using explicit mode. However, IMHO, prefixes in BU/BAck is duplicating functionality of routing protocols, and in the OSPF particular case the Links State Acknowledgements include the acknowledged LSA's, which is to me similar to putting prefixes in the BAck. Alex --------------enig89D6B6ED344E1F7E62644031 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfTYHMmC0w56zj54RAu1ZAKDyTNFUG/PmXGWcyNWPbIdeaxj8zgCeKTEy BslZOy2NvhaZQzBTVj6Pf0M= =Y2Up -----END PGP SIGNATURE----- --------------enig89D6B6ED344E1F7E62644031-- From nemo-bounces@ietf.org Mon Oct 25 13:57:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18623 for ; Mon, 25 Oct 2004 13:57:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM93O-0003Cs-04; Mon, 25 Oct 2004 13:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8yc-0002Pn-29 for nemo@megatron.ietf.org; Mon, 25 Oct 2004 13:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17966 for ; Mon, 25 Oct 2004 13:49:47 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9C5-00041F-1K for nemo@ietf.org; Mon, 25 Oct 2004 14:03:46 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9PHp5G2022288; Mon, 25 Oct 2004 10:51:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9PHndZX008188; Mon, 25 Oct 2004 12:49:40 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 594698859AE; Mon, 25 Oct 2004 19:49:39 +0200 (CEST) Message-ID: <417D3CAD.3050809@motorola.com> Date: Mon, 25 Oct 2004 19:49:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> <417C8C6F.8070705@sun.com> <417CC5FE.6010709@motorola.com> <417D29FD.2040907@sun.com> In-Reply-To: <417D29FD.2040907@sun.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58667DE0727D46A40D35C668" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: marcelo bagnulo braun , IETF NEMO WG , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58667DE0727D46A40D35C668 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> One utility would be to get rid of encapsulation MR-CN. This >> encapsulation happens supposedly because MR can not modify the >> source address of packets from LFN to CN after the enhanced-RR >> procedure (the one adding the DO and RH). Or am I wrong to think >> this encapsulation is absolutely necessary? > > I don't understand. The source address needs to be correct with > respect to the place where the packets are injected in the network to > prevent it being filtered Ah yes, that again, correct, sorry. Alex --------------enig58667DE0727D46A40D35C668 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfTyzMmC0w56zj54RAgHOAKC/nC3VkTMPWC/AsEk7MewEKx93OQCgvOyz 4yBDkkdqCuc3WNqoSJi8SFA= =N0ch -----END PGP SIGNATURE----- --------------enig58667DE0727D46A40D35C668-- From nemo-bounces@ietf.org Mon Oct 25 19:54:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20195 for ; Mon, 25 Oct 2004 19:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEOS-0007vt-Ft; Mon, 25 Oct 2004 19:36:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCEH-0003hM-Oh for nemo@megatron.ietf.org; Mon, 25 Oct 2004 17:18:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11578 for ; Mon, 25 Oct 2004 17:18:10 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCRl-0001VJ-7v for nemo@ietf.org; Mon, 25 Oct 2004 17:32:12 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9PLI77q018686; Mon, 25 Oct 2004 14:18:07 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PLI5JQ005941; Mon, 25 Oct 2004 23:18:05 +0200 (MEST) Message-ID: <417D6DBA.1070709@sun.com> Date: Mon, 25 Oct 2004 14:18:50 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Comments on basic support, ND, prefix-BAck References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> <417CC1FD.1050009@motorola.com> <417D2701.1060602@sun.com> <417D3602.5050105@motorola.com> In-Reply-To: <417D3602.5050105@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > So I think it is still good to forbid MR to send NA's for any address > assigned on the egress interface other than the Care-of Address valid on > the visited link. *If* that's what the WG wants to do I suggest being very specific in the text by saying something like this: While away from home the MR MUST NOT send any NA for the Home Address on the visited link. In addition, it MUST NOT use the Home Address as the source address for any Neighbor Discovery packet sent on the visited link. The reason for these restrictions is to prevent the creation of a Neighbor Cache entry for the HoA on the neighbors on the visited link; the neighbors should communicate with the MR via its Home Agent. Note that these restrictions apply to Neighbor Discovery on the visited link and do not apply to the link which is the tunnel between the MR and the HA. Erik From nemo-bounces@ietf.org Mon Oct 25 19:57:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20577 for ; Mon, 25 Oct 2004 19:57:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMESF-0006r2-O7; Mon, 25 Oct 2004 19:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCy3-0006iJ-GJ for nemo@megatron.ietf.org; Mon, 25 Oct 2004 18:05:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24245 for ; Mon, 25 Oct 2004 18:05:28 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDBZ-0005K6-V7 for nemo@ietf.org; Mon, 25 Oct 2004 18:19:30 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C0B842F7CA; Tue, 26 Oct 2004 00:05:00 +0200 (CEST) Received: from [163.117.252.214] (vpn-252-214.uc3m.es [163.117.252.214]) by smtp03.uc3m.es (Postfix) with ESMTP id C84A72F7C5; Tue, 26 Oct 2004 00:04:59 +0200 (CEST) In-Reply-To: <1098632245.534.21.camel@localhost> References: <1098239668.9236.11.camel@localhost> <5055FCEC-234D-11D9-AF09-000D93ACD0FE@it> <1098356821.9179.34.camel@localhost> <1098632245.534.21.camel@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt] Date: Tue, 26 Oct 2004 00:04:45 +0200 To: Chan-Wah NG X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit >> >>> Fourthly, addressing your comment on BU with a prefix to CN where >>> there >>> is only one MNN communicating with the CN. But what is the >>> alternative? By sending only normal BU, it is not enough to >>> establish >>> optimized route. >> >> Why not? >> >> in the most cases (AFAICS) a given CN will only be communicating with >> a >> single MNN of a given nemo. so in this case, you only need to tell >> that >> CN which is the CoA of the MNN (i.e. present the CoA of the MR as the >> CoA of the MNN using MIP) >> for that the BU of MIP is enough. >> > > Yes, but whose HoA should the MR use? I was thinking in the MIRON approach (sent to the list by Carlos Jesus) In this case, the MIP CN capability is used, using the MNN address as the HoA and the CoA of the MR as the CoA of the BU > If MR uses its own HoA, its not > going to achieve anything. MR needs to tell CN more information (i.e > HoA of MNN), and CN will need to verify this new info. In an extreme > way of looking at it, the HoA of MNN can be treated as a prefix with > length 128. > > Alternatively, we can go the Proxy approach, where MR send the BU on > behalf of MNN (it pretends to be the MNN). Personally, something > doesn't feel right to me with this approach (reminds me of NAT), but I > concede that this will keep the CN unchanged. > >> So i would say that you could simply use mip BU unchanged. >> >> I see the prefix scoped BU as an optimization of the mip BU which only >> benefit is to reduce the number of messages when the CN is >> communicating with more than one MNN of the same nemo simoultaneously. >> My question is if such optimzation worth the deployment effort. >> >>> >>> Of-course, I understand that there is other approaches to route >>> optimization that will keep CN untouched. If the final solution >>> selected by the WG (after re-charter) does not require the >>> verification >>> of a network prefix, then fine, I treat my RRNP as a useful classroom >>> exercise. >> >> >> As i already mention, i think that the RRNP is a nice approach to use >> RR to verify a prefix BU. However, i am not sure that the CN should do >> this. >> >> Summarizing: >> >> imho the RRNP is an interesting tool to verify a prefix >> imho implementing this at the CN level is not worth the effort (i.e. >> the obtained benefits doesn't seems so much imho) >> > > Thank you! Then I presume that you are all for a RO solution that will > keep CN untouch. That's fine, I would want one with that feature too. > However, if a RO solution impact CN, then I see no reason why CN should > implement RRNP alongside with the "new RO functioanlity". > agree (with the shouldn't of course) regards, marcelo > > /rgds > /cwng > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Mon Oct 25 20:07:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22019 for ; Mon, 25 Oct 2004 20:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEXV-0005PB-AR; Mon, 25 Oct 2004 19:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDqb-0001DB-Iy for nemo@megatron.ietf.org; Mon, 25 Oct 2004 19:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08903 for ; Mon, 25 Oct 2004 19:01:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CME48-00019p-58 for nemo@ietf.org; Mon, 25 Oct 2004 19:15:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9PMY9526965; Mon, 25 Oct 2004 15:34:09 -0700 X-mProtect: <200410252234> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdco7MRQ; Mon, 25 Oct 2004 15:34:07 PDT Message-ID: <417D85C5.7050005@iprg.nokia.com> Date: Mon, 25 Oct 2004 16:01:25 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> <417C8586.7070203@sun.com> In-Reply-To: <417C8586.7070203@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>> 1. Section 3 is doesn't talk about authorization for a MR routing a >>> specific >>> prefix. I suggest adding text after >>> Update. The Home Agent sets up forwarding for each of these prefixes >>> to the Mobile Router's Care-of Address. >>> saying: >>> , once it has verified that the mobile router is authorized to >>> route to >>> those prefixes. The mobile IPv6 mechanisms [1] provides for >>> authentication >>> and the authorization might be performed by maintaining a list of the >>> prefixes which each MR (i.e., Home Address) is allowed to route. >> >> we do talk about it in section 6.1.2. > > Yes, but in the interest of gradual disclosure as you read the document, > I think it should be mentioned in section 3 as well. > > And, FWIW, section 6.1.2 doesn't have the word "authorized" which I > think is the key concept to make clear to the reader here. > >> for section 3, how about just the following >> >> The Home Agent sets up forwarding for each of these prefixes to the >> Mobile Router's Care-of Address, once it has verified that the >> mobile router is authorized to route to those prefixes. > > Given that subsequent sections are a bit poor at using "authorized" > I think it would be hard for the reader to connect the dots. > If we could use "authorized", or have forward references to the relevant > sections, then this would be ok. okay. here is the text The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address, once it has verified that the Mobile Router is authorized to route to those prefixes. Section 6.1.2 describes a mechanism by which the Home Agent can verify if a Mobile Router is authorized for a prefix. >> >> I am fine with the change, but this might mean sending the document >> back to IANA. IANA has already done the assignments. >> http://www.iana.org/assignments/mobility-parameters. and they call it >> "Forwarding Setup failed". maybe we can avoid this change. (?) > > > I don't know what the overhead would be; the IANA needs to edit the with the recent delays we have had with IANA assignments, I am not sure I want to do this. > registry anyhow to enter the RFC number so perhaps they can change the > name at the same time. The registry currently says > 143 Forwarding Setup failed [draft-ietf-nemo-basic-support-03.txt] > > If it is hard to get that edit to the IANA, how about making the I-D/RFC > add a parenthesis e.g. > 143 Forwarding Setup Failed (prefixes missing) this is fine with me. > >> we have some text in section 6.2 >> >> - If a Mobile Network Prefix Option is present in the Binding >> Update, the prefix information for the Mobile Network Prefix is >> retrieved from the Mobile Network Prefix field and the Prefix >> Length field of the option. If the Binding Update contains more >> than one option, the Home Agent MUST set up forwarding for all of >> the Mobile Network Prefixes. If the Home Agent fails to setup >> forwarding to all the prefixes listed in the Binding Update, then >> it MUST NOT forward traffic to any of the prefixes, reject the >> Binding Update and send a Binding Acknowledgement with status set >> to 141 (Invalid Prefix). >> >> dont you think this is enough? > > > I did see that text, but is it less than clear. > It doesn't say "do not add the prefix to the list" but instead it says > "do not forward traffic". So perhaps the reader will think it should be > added to the list but not used? And this is the only place where it > talks about the behavior under failure. > So changing the above to say "do not add to the list" would be an > improvement, but it would also make sense to state the "all or nothing" > aspect of the list of prefixes earlier in the document - perhaps where > the prefix option is defined. section 4.3 defines the Mobile Network Prefix. I think this text should come under processing the Binding Update. so in section 6.2 lets change the text to say the HA should not create the routes. If the Home Agent fails to setup forwarding to all the prefixes listed in the Binding Update, then it MUST NOT create routes to any of the prefixes, reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix). >>> when that interface is attached to a visited link. However, the >>> Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor >>> Solicitations received on the egress interface, for topologically >>> correct addresses. >>> and I have no idea what "topologically correct" means in this context. >>> Shouldn't the MR just reply for the addresses it has assigned to the >>> egress >>> interface, just like any other node? > > >> well, this was put for the MR to avoid replying to any addresses that >> make no sense on the visited link. for example if the MR has a HoA and >> CoA configured on the egress interface, we want the MR to respond to >> neighbor solicitations only for the CoA and not for the HoA. > > > The text doesn't say that. > If you want to say "SHOULD respond for the CoA and MAY respond for the > HoA" you should be explicit about it. > (I'm assuming you don't want to prohibit implementations from responding > for the HoA, since it would be harmless.) how about we change the text to the following However, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface only for addresses valid on the visited link. while I agree it is harmless, is there a use of allowing the MR to send a solicited NA for the HoA on the visited link? if some MR really wants to do it, maybe it can ignore the 'SHOULD' and do it? >>> >>> 11. Section 9 says >>> In case the Mobile >>> Router receives a IP-in-IP tunneled packet from a node in the Mobile >>> Network and the Mobile Router has to forward the decapsulated packet, >>> it SHOULD perform the above mentioned checks on the source address of >>> the inner packet. >>> In don't understand why this restriction is in place. >>> Wouldn't it prevent nested mobile networks where the "lower" one will >>> use >>> its home address, which the upper MR has no knowledge of, in the >>> inner header? >> >> >> >> please see issue 23. http://people.nokia.net/vijayd/nemo/issue23.txt. >> it should be possible for the "lower" MR to send a packet you want >> by setting the destination address on the outer IP header to its own >> HA, instead of the "upper" MR. > > > But the text in the draft doesn't say that this check only applies to > packets addressed to one of the MRs address; I read it as applying to > all IP-in-IP packets that the MR forwards. > So I suspect some clarification would be helpful. ah.. now I understand. the current text says In case the Mobile Router receives a IP-in-IP tunneled packet from a node in the Mobile Network and the Mobile Router has to forward the decapsulated packet, the text "has to forward the decapsulated packet" means the IP-in-IP packet was addressed to the MR. that is why it is decapsulating and forwarding the inner packet. but I agree it should be made more explicit. how about the following? In case the Mobile Router receives a IP-in-IP tunneled packet from a node in the Mobile Network, with the destination address on the outer IPv6 header set to the Mobile Router and the Mobile Router has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet. >>> 13. Appendix B.2 says: >>> The following should be considered when the Home Network is >>> configured for running OSPF. >>> >>> - The entire Home domain SHOULD NOT be configured as a single area >>> if a Home Agent supports Mobile Routers. At least the Home >>> Network should be configured as a separate area. >>> >>> - The bi-directional tunnel interfaces to the Mobile Routers should >>> never be included in the same area as the backbone links. >>> >>> I don't understand the motivation for this? Is it performance related? >> >> yes. see issue 31 again. > > Sorry, the RFC needs to capture and explain an issue like this. > >> otherwise, if there is a change in routing in one Mobile Network, the >> entire Home Domain would get to know about it. if there is a change >> in routing in the home domain, all the mobile routers get a link state >> message. >> >>> If I run a flat (no areas defined) OSPF routing domain >>> with 4 links and 4 prefixes, the above "SHOULD" appears to force me to >>> configure areas. At a minimum the text should explain the basis for >>> the considerations, and perhaps also say that they apply to large >>> routing >>> domains. >> >> I can add some text to justify the two bullet points. > > Thanks. > >> The above is necessary to restrict the routing protocol messages to >> the Home Network, instead of sending the messages to the entire Home >> domain. > > With with my 4 link OSPF routing domain that would be perfectly > acceptable. So the note needs to be about the increased load especially > for large IGP domains. > (And I think IS-IS and RIPv2 has the same issue as OSPF here.) can you propose some text here? I couldnt come up with anything that satisfied even me. > >>> 14. Since the IETF has been notified of IPR, I think that form of >>> "Intellectual property statement" should be used. >> >> I am a bit ignorant here. is it missing the following text? >> >> The IETF has been notified of intellectual property rights claimed in >> regard to some or all of the specification contained in this >> document. For more information consult the online list of claimed >> rights. > > That's the gist of it (I didn't check the above text against the > boilerplate). Erik, I did some research. does not look like the above text needs to appear in the draft. RFC 3668 seems to say, it is enough if the draft points to http://www.ietf.org/ipr. it appears to me that the following two paragraphs are sufficient. in the "Status of This Memo" section By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. in the "Intellectual Property Statement" section Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. please correct me if I am wrong. Vijay From nemo-bounces@ietf.org Mon Oct 25 20:12:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22879 for ; Mon, 25 Oct 2004 20:12:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEZd-0007JU-Or; Mon, 25 Oct 2004 19:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CME8f-0007s2-30; Mon, 25 Oct 2004 19:20:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12843; Mon, 25 Oct 2004 19:20:29 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEM9-0002QA-LJ; Mon, 25 Oct 2004 19:34:32 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 19:19:58 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 19:19:58 -0400 Message-ID: Thread-Topic: MIP and transition issues Thread-Index: AcS66R10DpafzyueS8WJQO1BVKyGow== From: "Soliman, Hesham" To: , , , X-OriginalArrivalTime: 25 Oct 2004 23:19:58.0275 (UTC) FILETIME=[24EB1930:01C4BAE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Tsirtsis George Subject: [nemo] MIP and transition issues X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Folks,=20 Sorry for the cross posting, but this issue is being discussed in all WG listed.=20 I submitted the following two drafts last night: draft-tsirtsis-dsmip-problem draft-soliman-v4v6-mipv6- The first deals with the problem statement and the=20 second is one of the solution for using MIPv6 only. There is another draft that proposes using MIPv4 only: draft-tsirtsis-v4v6-mipv4 I hope we can discuss the problem statement and scenarios=20 in the next meeting. While the problem statement is on the mip6 charter, it would be useful if we can have a slot allocated for=20 this in v6ops.=20 thx Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Mon Oct 25 20:15:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23146 for ; Mon, 25 Oct 2004 20:15:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMErr-0000fY-Rc; Mon, 25 Oct 2004 20:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEXf-0005U6-Ai for nemo@megatron.ietf.org; Mon, 25 Oct 2004 19:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18968 for ; Mon, 25 Oct 2004 19:46:19 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMElB-0004SL-JN for nemo@ietf.org; Mon, 25 Oct 2004 20:00:23 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9PNkJui005571; Mon, 25 Oct 2004 17:46:20 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PNkGJQ017230; Tue, 26 Oct 2004 01:46:17 +0200 (MEST) Message-ID: <417D9074.7070804@sun.com> Date: Mon, 25 Oct 2004 16:47:00 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> <417C8586.7070203@sun.com> <417D85C5.7050005@iprg.nokia.com> In-Reply-To: <417D85C5.7050005@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > The Home Agent sets up forwarding for each of these prefixes > to the Mobile Router's Care-of Address, once it has verified that > the Mobile Router is authorized to route to those prefixes. Section > 6.1.2 describes a mechanism by which the Home Agent can verify if > a Mobile Router is authorized for a prefix. ok > section 4.3 defines the Mobile Network Prefix. I think this text > should come under processing the Binding Update. so in section 6.2 > lets change the text to say the HA should not create the routes. > > If the Home Agent fails to setup > forwarding to all the prefixes listed in the Binding Update, then > it MUST NOT create routes to any of the prefixes, reject the > Binding Update and send a Binding Acknowledgement with status set > to 141 (Invalid Prefix). > ok > how about we change the text to the following > > However, the > Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface only for addresses > valid on the visited link. > > while I agree it is harmless, is there a use of allowing the MR to > send a solicited NA for the HoA on the visited link? if some MR > really wants to do it, maybe it can ignore the 'SHOULD' and do it? Pascal brought up the issue of unsolicited NAs as well, and I added that other ND messages can create state (e.g. sending a NS with the source being the HoA). So the question is how strong does the WG want to make the prohibition. In any case, independent of what it covers and whether it is a MUST or a SHOULD, it would be useful to add a sentence about the problem the way I suggested to Pascal (that way folks know what violating e.g. a SHOULD would imply). > but I agree it should be made more explicit. how about the following? > > In case the > Mobile Router receives a IP-in-IP tunneled packet from a node in the > Mobile Network, with the destination address on the outer IPv6 header > set to the Mobile Router and the Mobile Router has to forward the > decapsulated packet, it SHOULD perform the above mentioned checks on > the source address of the inner packet. WFM >> With with my 4 link OSPF routing domain that would be perfectly >> acceptable. So the note needs to be about the increased load >> especially for large IGP domains. >> (And I think IS-IS and RIPv2 has the same issue as OSPF here.) > > > can you propose some text here? I couldnt come up with anything > that satisfied even me. When the mobile router participates in an IGP such as OSPF, the fact that the MR-HA connectivity will change over time can have a significant performance impact, especially for large IGP domains. The performance impact is two-fold: - the changes of reachability for the MR-HA tunnel can potentially be flooded to all the routers in the routing domain, causing additional load on the routers - each time the MR re-establishes the tunnel to the HA it will need to synchronize all the LSAs Therefore, it is RECOMMENDED that all-but the smallest routing domains use OSPF areas [XXX should we also say something about IS-IS?] to limit the propagation of routing information when the MRs come and go. [add rest of text in edited form] > Erik, I did some research. does not look like the above text > needs to appear in the draft. RFC 3668 seems to say, it is enough > if the draft points to http://www.ietf.org/ipr. it appears to me > that the following two paragraphs are sufficient. > > in the "Status of This Memo" section > > By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. > > in the "Intellectual Property Statement" section > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the > use of such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > please correct me if I am wrong. You're right. I'd missed that the "has been notified" language is removed from the new boilerplate. Erik From nemo-bounces@ietf.org Mon Oct 25 21:08:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27122 for ; Mon, 25 Oct 2004 21:08:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFlm-0000mj-Qp; Mon, 25 Oct 2004 21:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFik-00005H-Ez for nemo@megatron.ietf.org; Mon, 25 Oct 2004 21:01:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26642 for ; Mon, 25 Oct 2004 21:01:52 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFwI-0006Bo-Iy for nemo@ietf.org; Mon, 25 Oct 2004 21:15:55 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9Q0YC005244; Mon, 25 Oct 2004 17:34:12 -0700 X-mProtect: <200410260034> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdU3r07w; Mon, 25 Oct 2004 17:34:11 PDT Message-ID: <417DA1E9.5080102@iprg.nokia.com> Date: Mon, 25 Oct 2004 18:01:29 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> <417C8586.7070203@sun.com> <417D85C5.7050005@iprg.nokia.com> <417D9074.7070804@sun.com> In-Reply-To: <417D9074.7070804@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> how about we change the text to the following >> >> However, the >> Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor >> Solicitations received on the egress interface only for addresses >> valid on the visited link. >> >> while I agree it is harmless, is there a use of allowing the MR to >> send a solicited NA for the HoA on the visited link? if some MR >> really wants to do it, maybe it can ignore the 'SHOULD' and do it? > > > Pascal brought up the issue of unsolicited NAs as well, and I added that > other ND messages can create state (e.g. sending a NS with the source > being the HoA). So the question is how strong does the WG want to make > the prohibition. In any case, independent of what it covers and whether > it is a MUST or a SHOULD, it would be useful to add a sentence about the > problem the way I suggested to Pascal (that way folks know what > violating e.g. a SHOULD would imply). you mean Alex? I will follow up on that thread. >>> With with my 4 link OSPF routing domain that would be perfectly >>> acceptable. So the note needs to be about the increased load >>> especially for large IGP domains. >>> (And I think IS-IS and RIPv2 has the same issue as OSPF here.) >> >> >> can you propose some text here? I couldnt come up with anything >> that satisfied even me. > > When the mobile router participates in an IGP such as OSPF, the fact > that the MR-HA connectivity will change over time can have a significant > performance impact, especially for large IGP domains. > The performance impact is two-fold: > - the changes of reachability for the MR-HA tunnel can potentially be > flooded to all the routers in the routing domain, causing additional > load on the routers > - each time the MR re-establishes the tunnel to the HA it will > need to synchronize all the LSAs > > Therefore, it is RECOMMENDED that all-but the smallest routing domains > use OSPF areas [XXX should we also say something about IS-IS?] to limit > the propagation of routing information when the MRs come and go. > [add rest of text in edited form] appendix B.2 is specifically about running OSPF. I dont this we need to talk about IS-IS here. (I anyway dont know enough about IS-IS). here is the entire text. B.2. OSPF Area Considerations When the Mobile Router participates in an IGP such as OSPF with its Home Agent, the fact that the Mobile Router-Home Agent connectivity will change over time can have a significant performance impact, especially for large IGP domains. The performance impact is two-fold: - The changes in the reachability of the Mobile Network can potentially be flooded to all the routers in the routing domain, causing additional load on the routers. - Each time the Mobile Router re-establishes the tunnel to the Home Agent, the Home Agent would need to synchronize all the LSAs. Therefore, it is RECOMMENDED that all-but the smallest routing domains use OSPF areas to limit the propagation of routing information. The following should be considered when the Home Network is configured for OSPF areas. - The entire Home domain SHOULD NOT be configured as a single area if a Home Agent supports Mobile Routers. At least the Home Network should be configured as a separate area. - The bi-directional tunnel interfaces to the Mobile Routers should never be included in the same area as the backbone links. For a more detailed discussion on configuring a Home Network for NEMO Basic Support, please see [18]. One disadvantage of running OSPFv3 with NEMO Basic Support is that there is a possibility that the Mobile Networks will be told of the topology of the entire Home Network, including all the fixed and mobile routers, while the only thing the Mobile Routers might really need is a default route through the Home Agent. To reduce the amount of routing protocol messages received by a Mobile Router, one can configure each bi-directional tunnel to a Mobile Router as a separate area. But this requires that the Home Agent support a large number of OSPF areas if it supports a large number of Mobile Routers and might not be possible with most router implementations. Another option is to configure multiple areas on the Home Link and group a number of Mobile Routers into each area. This reduces the number of areas that a Home Agent needs to support, but at the same time reduces the amount of routing protocol traffic that a Mobile Router receives. From nemo-bounces@ietf.org Mon Oct 25 21:21:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28025 for ; Mon, 25 Oct 2004 21:21:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFy6-0004Ly-W8; Mon, 25 Oct 2004 21:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFqO-0002bn-48 for nemo@megatron.ietf.org; Mon, 25 Oct 2004 21:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27184 for ; Mon, 25 Oct 2004 21:09:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMG3v-0006Kn-BY for nemo@ietf.org; Mon, 25 Oct 2004 21:23:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9Q0g4J13635; Mon, 25 Oct 2004 17:42:04 -0700 X-mProtect: <200410260042> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpd1aBwZc; Mon, 25 Oct 2004 17:42:03 PDT Message-ID: <417DA3C1.1090106@iprg.nokia.com> Date: Mon, 25 Oct 2004 18:09:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [nemo] Comments on basic support, ND, prefix-BAck References: <41785F25.8020303@sun.com> <417942F0.8000503@motorola.com> <41798759.5000303@sun.com> <417CC1FD.1050009@motorola.com> <417D2701.1060602@sun.com> <417D3602.5050105@motorola.com> <417D6DBA.1070709@sun.com> In-Reply-To: <417D6DBA.1070709@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I dont think I want to prohibit MR from sending solicited NAs on the visited link for the HoA. maybe we will find a use for it. :) Erik Nordmark wrote: > Alexandru Petrescu wrote: > >> So I think it is still good to forbid MR to send NA's for any address >> assigned on the egress interface other than the Care-of Address valid on >> the visited link. > > > *If* that's what the WG wants to do I suggest being very specific in the > text by saying something like this: > While away from home the MR MUST NOT send any NA for the Home Address on > the visited link. we shouldnt add something like this. > In addition, it MUST NOT use the Home Address as the > source address for any Neighbor Discovery packet sent on the visited link. the right place for this language is RFC 3775. (I think it already talks about not using HoA as source address for packets sent to the visited link directly). I think it is enough to say However, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface only for addresses valid on the visited link. and stop there. the 'SHOULD' can be ignored if somebody wants to. Vijay > The reason for these restrictions is to prevent the creation of a > Neighbor Cache entry for the HoA on the neighbors on the visited link; > the neighbors should communicate with the MR via its Home Agent. > Note that these restrictions apply to Neighbor Discovery on the visited > link and do not apply to the link which is the tunnel between the MR and > the HA. > > Erik > From nemo-bounces@ietf.org Mon Oct 25 22:14:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01353 for ; Mon, 25 Oct 2004 22:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGpM-0002e5-Ae; Mon, 25 Oct 2004 22:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGoO-0002R9-1w for nemo@megatron.ietf.org; Mon, 25 Oct 2004 22:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00968 for ; Mon, 25 Oct 2004 22:11:45 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMH1w-0007P2-69 for nemo@ietf.org; Mon, 25 Oct 2004 22:25:49 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9Q2Bg7q002910; Mon, 25 Oct 2004 19:11:43 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9Q2BeJQ023733; Tue, 26 Oct 2004 04:11:41 +0200 (MEST) Message-ID: <417DB287.4090107@sun.com> Date: Mon, 25 Oct 2004 19:12:23 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> <417C8586.7070203@sun.com> <417D85C5.7050005@iprg.nokia.com> <417D9074.7070804@sun.com> <417DA1E9.5080102@iprg.nokia.com> In-Reply-To: <417DA1E9.5080102@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > you mean Alex? I will follow up on that thread. Yes. Sorry for the confusion. > here is the entire text. > > B.2. OSPF Area Considerations > > When the Mobile Router participates in an IGP such as OSPF with its > Home Agent, the fact that the Mobile Router-Home Agent connectivity > will change over time can have a significant performance impact, > especially for large IGP domains. The performance impact is > two-fold: > > - The changes in the reachability of the Mobile Network can > potentially be flooded to all the routers in the routing domain, > causing additional load on the routers. > > - Each time the Mobile Router re-establishes the tunnel to the Home > Agent, the Home Agent would need to synchronize all the LSAs. > > Therefore, it is RECOMMENDED that all-but the smallest routing > domains use OSPF areas to limit the propagation of routing > information. > > The following should be considered when the Home Network is > configured for OSPF areas. > > - The entire Home domain SHOULD NOT be configured as a single area > if a Home Agent supports Mobile Routers. At least the Home > Network should be configured as a separate area. > > - The bi-directional tunnel interfaces to the Mobile Routers should > never be included in the same area as the backbone links. > > For a more detailed discussion on configuring a Home Network for NEMO > Basic Support, please see [18]. > > One disadvantage of running OSPFv3 with NEMO Basic Support is that > there is a possibility that the Mobile Networks will be told of the > topology of the entire Home Network, including all the fixed and > mobile routers, while the only thing the Mobile Routers might really > need is a default route through the Home Agent. > > To reduce the amount of routing protocol messages received by a > Mobile Router, one can configure each bi-directional tunnel to a > Mobile Router as a separate area. But this requires that the Home > Agent support a large number of OSPF areas if it supports a large > number of Mobile Routers and might not be possible with most router > implementations. > > Another option is to configure multiple areas on the Home Link and > group a number of Mobile Routers into each area. This reduces the > number of areas that a Home Agent needs to support, but at the same > time reduces the amount of routing protocol traffic that a Mobile > Router receives. Good enough. Erik From nemo-bounces@ietf.org Tue Oct 26 14:07:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00007 for ; Tue, 26 Oct 2004 14:07:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVbP-0002YF-V9; Tue, 26 Oct 2004 13:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVRC-0005sX-DC for nemo@megatron.ietf.org; Tue, 26 Oct 2004 13:48:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28185 for ; Tue, 26 Oct 2004 13:48:48 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVes-0000g0-Nz for nemo@ietf.org; Tue, 26 Oct 2004 14:03:00 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i9QHmlb6023275; Tue, 26 Oct 2004 10:48:47 -0700 (MST) Received: from [10.182.46.154] (mvp-10-182-46-154.am.mot.com [10.182.46.154]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i9QHkINM005461; Tue, 26 Oct 2004 12:46:19 -0500 Message-ID: <417E8DF4.1030302@motorola.com> Date: Tue, 26 Oct 2004 19:48:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Comments on basic support References: <41785F25.8020303@sun.com> <41798D9F.9040309@iprg.nokia.com> <417C8586.7070203@sun.com> <417D85C5.7050005@iprg.nokia.com> In-Reply-To: <417D85C5.7050005@iprg.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB6ED8387D4CC7A1FCED9A6E6" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nemo@ietf.org, Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB6ED8387D4CC7A1FCED9A6E6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Erik Nordmark wrote: >>> I am fine with the change, but this might mean sending the >>> document back to IANA. IANA has already done the assignments. >>> http://www.iana.org/assignments/mobility-parameters. and they >>> call it "Forwarding Setup failed". maybe we can avoid this >>> change. (?) >> >> I don't know what the overhead would be; the IANA needs to edit the >> > > with the recent delays we have had with IANA assignments, I am not > sure I want to do this. A quick way to clarify how much impact this may have may be to talk face-to-face during IANA "office hours" at the next meeting, a suggestion. Alex > From: "IANA" > To: > Date: Wed, 20 Oct 2004 14:40:26 -0700 > Subject: IANA "Office Hours" at IETF-61 in Washington, DC. > > Greetings! > > The IANA will be holding "Office Hours" at the IETF-61 in Washington, > DC. Our experience in San Diego was a success and many people > requested we hold office hours again. This will continue to give > everyone an opportunity to discuss IANA Considerations in your > documents, as well as ask any questions that you may have. > > The IANA will have a table near the IETF registration area, staffed > during the following hours: > > Monday - Wednesday, 0900 - 1600 > > Please stop by and say hello. > > Thank you and see you in DC! > > IANA (Michelle Cotton and Doug Barton) > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --------------enigB6ED8387D4CC7A1FCED9A6E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfo37MmC0w56zj54RAsU4AJ9bdndYAP1/+LzMuqBB5C9kJ/7vlACfRm8w YWIK6Z9s+WexwQcV5YvN6bI= =d1sr -----END PGP SIGNATURE----- --------------enigB6ED8387D4CC7A1FCED9A6E6-- From nemo-bounces@ietf.org Tue Oct 26 19:32:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27044 for ; Tue, 26 Oct 2004 19:32:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ18-00052z-UG; Tue, 26 Oct 2004 17:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYM0-0006XC-QH; Tue, 26 Oct 2004 16:55:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19507; Tue, 26 Oct 2004 16:55:38 -0400 (EDT) Message-Id: <200410262055.QAA19507@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:55:38 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-requirements-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : Network Mobility Support Goals and Requirements Author(s) : T. Ernst Filename : draft-ietf-nemo-requirements-03.txt Pages : 13 Date : 2004-10-26 Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161111.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Oct 26 19:35:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27830 for ; Tue, 26 Oct 2004 19:35:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ1Z-0005Ld-0N; Tue, 26 Oct 2004 17:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYQX-0007vB-Nk; Tue, 26 Oct 2004 17:00:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20350; Tue, 26 Oct 2004 17:00:19 -0400 (EDT) Message-Id: <200410262100.RAA20350@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 17:00:19 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-02.txt Pages : 22 Date : 2004-10-26 This document defines a terminology for discussing network mobility issues and solution requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-terminology-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161118.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Oct 26 20:34:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14197 for ; Tue, 26 Oct 2004 20:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbYD-0004Du-Rc; Tue, 26 Oct 2004 20:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMa3J-00026k-N3 for nemo@megatron.ietf.org; Tue, 26 Oct 2004 18:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15919 for ; Tue, 26 Oct 2004 18:44:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMaH3-0006eV-5N for nemo@ietf.org; Tue, 26 Oct 2004 18:58:41 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9QMGkK22415 for ; Tue, 26 Oct 2004 15:16:46 -0700 X-mProtect: <200410262216> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019066129.americas.nokia.com (172.19.66.129, claiming to be "[172.19.66.129]") by darkstar.iprg.nokia.com smtpdcNtFBd; Tue, 26 Oct 2004 15:16:44 PDT Message-ID: <417ED320.1030903@iprg.nokia.com> Date: Tue, 26 Oct 2004 15:43:44 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [nemo] changes from Erik's comments X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi all, a number of changes have been made to the Basic support protocol to address Erik's comments. most of them are minor involving adding text to clarify/explain things better. the draft with the changes can be found at http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre04.txt with a diff from version 3 at http://people.nokia.net/vijayd/nemo/3to4_diff.html I havent yet addressed the one issue on including prefixes in the Binding Ack. I see this as a bigger change than the others. I have created a separate issue for it. Issue 44 at http://people.nokia.net/vijayd/nemo/issues.html. I will send a separate mail on that. Vijay From nemo-bounces@ietf.org Tue Oct 26 20:48:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15987 for ; Tue, 26 Oct 2004 20:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbl5-0002EX-3V; Tue, 26 Oct 2004 20:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbXw-0003cK-Uu for nemo@megatron.ietf.org; Tue, 26 Oct 2004 20:20:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10750 for ; Tue, 26 Oct 2004 20:20:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMblg-0006Ub-QR for nemo@ietf.org; Tue, 26 Oct 2004 20:34:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9QNqTN18755; Tue, 26 Oct 2004 16:52:29 -0700 X-mProtect: <200410262352> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdwUnlW4; Tue, 26 Oct 2004 16:52:27 PDT Message-ID: <417EE9A8.1080209@iprg.nokia.com> Date: Tue, 26 Oct 2004 17:19:52 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Erik Nordmark Subject: [nemo] issue 44 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi all, I am trying to resolve issue 44. http://people.nokia.net/vijayd/nemo/issue44.txt this error is most probably due to a mis-configuration on the MR. we have 2 options 1. do nothing. if the MR sends a BU with multiple prefix options and receives a Binding Ack with status 142, it can try sending a BU again with one prefix at a time. 2. make the change that Erik suggested. the HA includes the offending prefix(es) in the Binding Ack. the MR can send a BU again with the offending prefix(es) removed. option 2 is definitely the better one, but I think it is too big a change to do this late. I would prefer to leave it as it is and do the update later when the basic support spec is updated. comments are welcome. Vijay From nemo-bounces@ietf.org Wed Oct 27 03:50:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14199 for ; Wed, 27 Oct 2004 03:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMiYO-0001sN-PD; Wed, 27 Oct 2004 03:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMiWb-0001ez-6w for nemo@megatron.ietf.org; Wed, 27 Oct 2004 03:47:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13908 for ; Wed, 27 Oct 2004 03:47:14 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMikP-0007iw-Kw for nemo@ietf.org; Wed, 27 Oct 2004 04:01:34 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9R7G1W05589; Wed, 27 Oct 2004 00:16:01 -0700 X-mProtect: <200410270716> Nokia Silicon Valley Messaging Protection Received: from danira-pool05052.americas.nokia.com (10.241.50.52, claiming to be "[10.241.50.52]") by darkstar.iprg.nokia.com smtpdE0sVh0; Wed, 27 Oct 2004 00:15:58 PDT Message-ID: <417F5182.1040505@iprg.nokia.com> Date: Wed, 27 Oct 2004 00:42:58 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal overIPv4 networks) References: <7892795E1A87F04CADFCCF41FADD00FC345025@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC345025@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Content-Transfer-Encoding: 7bit Cc: nemo , "Daniel Shell \(dshell\)" , Thierry Ernst , ryuji@sfc.wide.ad.jp, "T.J.Kniveton" , pthubert@cisco.ccom.cnri.reston.va.us, William.D.Ivancic@nasa.gov X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Vijay: > > At least we start the discussion ... and we can discuss pro/cons, > applicability, things like that, and improve the solutions. > > Note that for the specifics of the tunnel overhead, it is possible to > apply some header compression technique, this is nothing new. yes it is. what do you have on mind? ROHC? why would I opt for a solution with a tunnel overhead, when I can use something without a tunnel overhead. > Actually we have discussed header compression internally long ago. But > improving the draft requires the group attention. Otherwise it's moot. > This is why we stopped the writing up for so long. okay. > > Now in terms of requirement, NEMO might consider: > > - we have to support NAT or plain public, and if so, which types of > NATs. I'm afraid that this is REALLY important. > > - whether it's acceptable to force that the IPv4 be terminated > physically at the HA. Surely it is in some cases as of today. Still it's > a limitation, which might have its own deployment and security > consequences. I believe it's better if it is just an option for the > deployement. > > - If we want the solution to be deployable incrementally to MIP6/NEMO, > and if there's value that the solution might be deployed with no change > to the HA. > > The IPv4 NAT/PAT traversal question has been there for quite some time. > I believe that at this point, we can take the time to understand what we > have on the table, and if it's possible, take the best of it all and > make that a standard. I agree that NEMO should consider these requirements. Vijay > > Pascal > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > > Of Vijay Devarapalli > >>Sent: jeudi 21 octobre 2004 23:09 >>To: Thierry Ernst >>Cc: nemo; Daniel Shell (dshell); ryuji@sfc.wide.ad.jp; T.J.Kniveton; >>pthubert@cisco.ccom.cnri.reston.va.us; William.D.Ivancic@nasa.gov >>Subject: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT > > transfersal overIPv4 networks) > >>Thierry, >> >>I personally prefer a solution based on Ryuji's draft >> > > http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-v4tunnel-00.txt > >>the Mobile Router basically registers its IPv4 CoA with its Home Agent >>which supports both IPv4 and IPv6. the outer tunnel would be between >>the MR's IPv4 CoA and HA's IPv4 address. the inner tunnel would be >>between the MR's IPv6 HoA (MNN's IPv6 address) and the CN's IPv6 >>address. for traffic between the MR and the HA, the inner tunnel would >>be between the MR's IPv6 HoA and HA's IPv6 address. >> >>this eliminates double tunneling. with "Doors", for example you end >>up with a NEMO tunnel inside a Doors tunnel. with the above solution, >>you end up with a single NEMO tunnel with outer IPv4 header and inner >>IPv6 header. >> >>I was planning to write up something on this, but didnt get to do it >>before the ID cutt-off deadline. if its okay with the chairs, I would >>like to present a couple of slides at the next meeting. >> >>Vijay >> >> >>Thierry Ernst wrote: >> >> >>>Dear all, >>> >>>There was this discussion in early August, so I wonder if there is >>>anything that we should do in the NEMO WG regarding this, and > > otherwise > >>>if there is anyone in our group willing to take a close look at the > > work > >>>done in v6ops. >>> >>>Thanks, >>>Thierry. >>> >>> >>> >>> >>> >>>On Wed, 4 Aug 2004 07:30:03 +0100 >>>Tim Chown wrote: >>> >>> >>> >>>>I think NAT is a consideration for the assisted tunneling > > requirements > >>>>analysis that is happening in v6ops. Have you read that? >> >>>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunnelin > > g-requirements-00.txt > >>>>It is NAT-PT that is pushed to the "last resort" status in v6ops > > (there is > >>>>a new push to write up why in an applicability statement, agreed > > this week). > >>>>I can't find any active reference to "doors" - could you provide a > > pointer? > >>>>Looks like nemo should be talking to v6ops here :) >>>> >>>>thanks, >>>>tim >>>> >>>>On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) > > wrote: > >>>>>Well, as I understand the work being done at the MIP6 or v6Ops, > > Doors is not considered > >>because of IPR. On the other hand, since the IPR encumbering is the > > basically same as that of > >>nemo basic support, doors should be acceptable within Nemo. So there > > IS something that is > >>Nemo specific after all. >> >>>>>There was a discussion in Seoul about NAT traversal (I asked Hesham > > over the mike) - > >>correct me if I'm wrong - they are not covering NAT in the current > > ipv4/IPv6 interoperability > >>solutions. So we end up with in one hand a non standard thing (doors) > > that has now been > >>thoroughly tested and goes though all sorts of NAT including reverse > > and symmetrical, or in > >>the other end the beginning of what may be a MIP remake of v6ops > > transition story. > >>>>>Could we just standardize doors so we can deliver something > > efficient to our customers? > >>And then if alternates pop up, they'll have to prove they are better > > in that space. > >>>>>Pascal >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On > > Behalf Of Thierry Ernst > >>>>>>Sent: mercredi 4 ao{t 2004 01:41 >>>>>>To: nemo >>>>>>Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >>>>>> >>>>>> >>>>>>Hi Will, >>>>>> >>>>>>Actually, the draft-iett-nemo-requirements mention NAT traversal > > and > >>>>>>IPv4-IPv6 transitin, so that is something we do care about. This > > said, > >>>>>>we concluded last year that there wasn't NEMO-specific issues. If > > there > >>>>>>is one, I think the WG should defintely address it. If these are > > issues > >>>>>>not specific to NEMO, we need to make sure these issues are > > addressed by > >>>>>>the relefvant WG. >>>>>> >>>>>>In any case, I agree with your statement. >>>>>> >>>>>>Thierry. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>On Tue, 03 Aug 2004 18:21:37 -0400 >>>>>>ivancic wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Thierry and/or TJ asked if there was additional work that NEMO > > should > >>>>>>>address prior to closing or rechartering. >>>>>>> >>>>>>>I strongly believe that the group should standardize on a NAT/PAT >>>>>>>transversal over IPv4 backbones. This will greatly increase the >>>>>>>ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, > > the > >>>>>>>European Nations and just about any Industrial nations is trying > > to help > >>>>>>>kick-start IPv6 deployments. However, the ISP's and industry do > > not yet > >>>>>>>have a good business case. Making the transission easier will > > help ALL > >>>>>>>of IPv6 deployments. I used some of Pascal's IPv6 NEMO code > > with the > >>>>>>>"Doors" protocol and demonstrated this to the CIO of the US DoD. > > The > >>>>>>>ability to run IPv6 over IPv4 and mix networks was very very > > important. > >>>>>>>See: >> >>>>>>http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm >>>>>> >>>>>>>Note, the "off-site demonstrations in Washington D.C. area" was > > for the > >>>>>>>Office of Secretary of Defense in order to show a migration path > > from > >>>>>>>IPv4 to IPv6. >>>>>>> >>>>>>> >>>>>>>Will >>>>>>> >>>>>>>-- >>>>>>>****************************** >>>>>>>William D. Ivancic >>>>>>>Phone 216-433-3494 >>>>>>>Fax 216-433-8705 >>>>>>>Lab 216-433-2620 >>>>>>>Mobile 440-503-4892 >>>>>>>http://roland.grc.nas.gov/~ivancic >>>>>>> >>>>>>> >>>>>>> >>>>>> >> >> > From nemo-bounces@ietf.org Wed Oct 27 09:38:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03711 for ; Wed, 27 Oct 2004 09:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnym-0005zR-Df; Wed, 27 Oct 2004 09:36:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnvr-0003gt-Tw for nemo@megatron.ietf.org; Wed, 27 Oct 2004 09:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03530 for ; Wed, 27 Oct 2004 09:33:41 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMo9h-0005KW-SZ for nemo@ietf.org; Wed, 27 Oct 2004 09:48:04 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2004 15:50:31 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9RDWiSx009498; Wed, 27 Oct 2004 15:33:01 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 15:32:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO taxonomy Date: Wed, 27 Oct 2004 15:32:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS6s91TVZR+imIlRGCWX5CJxmSf2QBa5TAA From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 27 Oct 2004 13:32:57.0527 (UTC) FILETIME=[788AF470:01C4BC29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > > In short, I believe that the devil is in the details. I like the = wording "packet > inspection" ;) , but the words snooping and hacking apply very well = too. I see it falling > short after some time. The MR will end up having to lookup every = packets for source and > destination, and modify all the RO'ed packets. >=20 > I agree that any three-party approach, i.e. anything involving = proxies, > is more complex than a two party approach. But if we want to solve RO > between a LFN (vanilla IPv6 with no mobility support) and a vanilla > MIPv6 CN, then it is clear that something in between those two needs = to > do some work i.e. a proxy of some form is necessary. >=20 > So the first question is how important it is solve this aspect of the > problem, and then we can see how to construct the best (but perhaps = not > perfect) proxy solution. :) I like the approach. If I'm correct, then this encompasses the global = HAHA approach as well. In HAHA, the proxies are fixed and do route = projection. In other words, they establish tunnels on demand and = exchange fine grained routes over the tunnels. >=20 > And if you can modify the LFN then you can probably design things to > avoid a proxy. >=20 By definition, can't :( We could say we do not support RO for them, but = an LFNs exist today. > > Also, it has to sort out whether the MNN is managing its own = mobility or security, or if > there's another MR or RO solution of some sorts that would defeat its = action. >=20 > A MNN wouldn't in general know that there is a MR; it is only for > Nemo-aware nodes that this question comes up. I think this can be > handled without interference from the proxy function. The Nemo-aware > node has two choices in terms of its CoA; it can share the MR's CoA or > it can get a CoA for itself (from some prefix delegated from the AR to > the MR and advertised to the Nemo-aware nodes for instance). > If it shares the CoA then the node needs to do some signaling with the > MR (because the MR would need to know where to forward the packets it > receives on its CoA and the HoA of the MNN might not be sufficient for > this in the case of a VMN). Thus, some form of binding update needs to > be sent from the MNN to the MR. As a result the MR knows not to apply > the proxy function for that HoA. Non NEMO aware nodes might be impacted, though. It comes back to the = collocation issue. The MR trying to do RR for a MNN regardless of the = MNN type could actually ATTACK a Visiting RFC 3775 MN that would try its = own RR test at the same time. And that VMN would not do any binding to = the MR.=20 Also, RRH allows a nemo aware VMN to manage -and do RO for - its own = mobility, transparently to the MR. So there no must the binding you = refer, either. > > and I agree with CW that we should revisit the RR test. RR is a = Work > In Progress anyway. So I'm not necessarily for keeping the CN = unchanged > whatever the cost. >=20 > I think you are barking up the wrong proverbial tree. Your issue isn't > with the RR test - it is with the explicit assumption that the "owner" > of the HoA is the node authorized to say where packets for its HoA are = sent. Sure. The assumption is inherited from RFC 3775. And the test was meant = to verify that assumption. And the transport (RH2 and stuff) was built = around that assumption as well. Same node, quoting: o The Home Address field in the routing header is one of the node's home addresses, if the segments left field was 1. Thus, in particular the address field is required to be a unicast routable address. Now, I understand that you could want to see MR + LFNs as a single node, = but I'm not sure that the nodes agree. I mean, it takes some bounding to = make a node out of separated boxes. Was that Wellfleet who defined the = first distributed router? I participated quite actively on the = development of the IBM 3746-950, which did that too. > So replacing the RR test with something that still has at least the = same > strength would never make the fundamental issue you have go away. Right, I understand that the new RR test would not check the collocation = of 2 addresses on a node but the collocation of a careof and the = ownership of the MNP where the target address resides. =20 > One could attempt to build solutions which makes delegating the > authorization to a 3rd party easier, but that still only solves the > authorization aspect of the proxy and does nothing about its impact on > the data path with HAO and RH2. >=20 >=20 > Note that I'm not saying proxies are easy or a good idea; there is a > long list of things they need to do correctly and things probably will > not work when there are multiple paths so that a single proxy do not = see > all packets between a LFN and CN. >=20 > What I am saying is that no matter what you replace the RR test with = you > will have the same fundamental issues with proxies. :) This is why global HAHA places the proxies in the infrastructure with = the expectation that a trust model exists between them. I'm not against = proxies...=20 Pascal From nemo-bounces@ietf.org Wed Oct 27 17:12:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15743 for ; Wed, 27 Oct 2004 17:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuoi-0004b1-Gf; Wed, 27 Oct 2004 16:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMufG-0008OI-Ro for nemo@megatron.ietf.org; Wed, 27 Oct 2004 16:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12249 for ; Wed, 27 Oct 2004 16:45:00 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMutB-0006wx-Ev for nemo@ietf.org; Wed, 27 Oct 2004 16:59:27 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9RKitNH014798; Wed, 27 Oct 2004 14:44:56 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9RKirJQ006241; Wed, 27 Oct 2004 22:44:53 +0200 (MEST) Message-ID: <418008F0.6060507@sun.com> Date: Wed, 27 Oct 2004 13:45:36 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Non NEMO aware nodes might be impacted, though. It comes back to the > collocation issue. The MR trying to do RR for a MNN regardless of the > MNN type could actually ATTACK a Visiting RFC 3775 MN that would try > its own RR test at the same time. And that VMN would not do any > binding to the MR. Would do you mean by "ATTACK"? The RR tests are independent so a proxying MR doesn't need to interfere with a VMN doing the same thing. But there is an issue with a CN seeing BUs that create "nested" bindings. Let's take an example: MN has HA(MN), HoA(MN); it configured CoA(MN) from the mobile network prefix; let's called the CoA P1::IID MR has HA(MR), HoA(MR), gets CoA(MR) from the AR and advertises P1 on the mobile network. Thus the MN would try to setup a binding in the CN from HoA(MN) to P1:IID. I doing so it would receive a HoT tunneled from its HA (which the MR can't even see if ESP is used on the tunnel) and a CoT addressed to P1::IID. Should the MR try to do a proxy RO on behalf of the MN then the only thing the MR knows is that it has a MNN with the IP address CoA(MN); it might not be able to tell that this is a VMN. For example, if the VMN does not perform RO and has a ESP tunnel with its HA, to the MR it looks like a MNN which has an ESP tunnel which could be a VPN or whatever. Thus the MR would try to route optimize by creating a binding in the CN for CoA(MN) (P1:IID) to the CoA(MR). In doing so, it would need process the CoT sent to CoA(MR), but this doesn't interfere with any CoT that the MN would trigger itself since the destination address is different. The MR would also need to intercept the HoT packet addressed to P1:IID, but this doesn't interfere with the above HoT tunneled to HoA(MN). Hence both the MR and MN can complete the BUs to the CN. If they do, it would result in two separate binding on the CN: from HoA(MN) -> P1::IID from P1:IID -> CoA(MR) When the CN sends packets to HoA(MN) it would match the first binding. I don't think RFC 3775 prescribes what a CN should do when, after applying the binding and adding RH2 to the packet, there is another binding which matches what is then in the destination field of the packet. (But it would make sense to check this in the spec). So different CN implementations might do different things such as: - ignore the second binding - apply the second binding in a recursive way i.e. add another RH2 header - fail (drop the packet or crash) Thus the conservative approach would be to try to prevent the MR's proxy binding from showing up. The MR could observe the CoTI/CoT/BU being exchanged between the MN and CN and use this as a trigger to deregister any proxy binding it has done. > Right, I understand that the new RR test would not check the > collocation of 2 addresses on a node but the collocation of a careof > and the ownership of the MNP where the target address resides. I don't understand how that can differ from the current RR and not be less secure. Erik From nemo-bounces@ietf.org Wed Oct 27 19:01:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25510 for ; Wed, 27 Oct 2004 19:01:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwlM-0001lL-Qq; Wed, 27 Oct 2004 18:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwjC-0001Oy-Gs for nemo@megatron.ietf.org; Wed, 27 Oct 2004 18:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25231 for ; Wed, 27 Oct 2004 18:57:10 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwx9-0001U3-7L for nemo@ietf.org; Wed, 27 Oct 2004 19:11:39 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 46C8180018E; Thu, 28 Oct 2004 01:56:41 +0300 (EEST) Date: Thu, 28 Oct 2004 01:56:41 +0300 (EEST) From: Ville Nuorvala To: Erik Nordmark Subject: Re: [nemo] RO taxonomy In-Reply-To: <418008F0.6060507@sun.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah NG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Wed, 27 Oct 2004, Erik Nordmark wrote: > When the CN sends packets to HoA(MN) it would match the first binding. > I don't think RFC 3775 prescribes what a CN should do when, after > applying the binding and adding RH2 to the packet, there is another > binding which matches what is then in the destination field of the > packet. (But it would make sense to check this in the spec). > So different CN implementations might do different things such as: > - ignore the second binding > - apply the second binding in a recursive way i.e. add another RH2 > header > - fail (drop the packet or crash) RFC 3775 Section 6.1.7 says: Binding Updates for a care-of address which is not a unicast routable address MUST be silently discarded. Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries). What this exactly means is open to interpretation. Strictly speaking it might mean it is ok to have several linked entries as long as they don't create a circular reference, but it is unlikely. I think the general assumption is that there will be just one RH type 2 per packet. That's at least what we assume in MIPL, but of course I can't speak on the behalf other implementations. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From nemo-bounces@ietf.org Wed Oct 27 19:43:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28563 for ; Wed, 27 Oct 2004 19:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxNk-0007V0-6j; Wed, 27 Oct 2004 19:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxM6-0007Ep-3w; Wed, 27 Oct 2004 19:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28227; Wed, 27 Oct 2004 19:37:22 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxa3-0002Mv-GO; Wed, 27 Oct 2004 19:51:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9RN9ac21731; Wed, 27 Oct 2004 16:09:36 -0700 X-mProtect: <200410272309> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdrkY4hi; Wed, 27 Oct 2004 16:09:35 PDT Message-ID: <41803123.3060901@iprg.nokia.com> Date: Wed, 27 Oct 2004 16:37:07 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ville Nuorvala Subject: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit sorry for the cross posting, but here is something to consider when RFC 3775 is revised. Ville Nuorvala wrote: > On Wed, 27 Oct 2004, Erik Nordmark wrote: > > >>When the CN sends packets to HoA(MN) it would match the first binding. >>I don't think RFC 3775 prescribes what a CN should do when, after >>applying the binding and adding RH2 to the packet, there is another >>binding which matches what is then in the destination field of the >>packet. (But it would make sense to check this in the spec). >>So different CN implementations might do different things such as: >> - ignore the second binding >> - apply the second binding in a recursive way i.e. add another RH2 >> header >> - fail (drop the packet or crash) > > > RFC 3775 Section 6.1.7 says: > > Binding Updates for a care-of address which is not a unicast routable > address MUST be silently discarded. Similarly, the Binding Update > MUST be silently discarded if the care-of address appears as a home > address in an existing Binding Cache entry, with its current location > creating a circular reference back to the home address specified in > the Binding Update (possibly through additional entries). > > What this exactly means is open to interpretation. Strictly speaking it > might mean it is ok to have several linked entries as long as they don't > create a circular reference, but it is unlikely. yes, it should be possible to have several linked binding cache entries. > > I think the general assumption is that there will be just one RH type 2 > per packet. That's at least what we assume in MIPL, but of course I can't > speak on the behalf other implementations. but we seem to have disallowed by the above by mistake in RFC 3775. RFC 3775 restricts RH Type 2 to only one address (segments left is always 1). RFC 2460 says a routing header can occur only once in a packet. (except for destinations options header, all other extension headers can appear only once in a packet). RFC 3775 should have allowed more than one address in RH type 2 and required that the desination address on the packet and the next addressed to be processed in the routing header belong to the same node. this would have allowed us to include more than one address in the routing header, but still satisfy the security requiements of Mobile IPv6. Vijay From nemo-bounces@ietf.org Thu Oct 28 01:49:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23156 for ; Thu, 28 Oct 2004 01:49:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN38S-0002Y7-Lp; Thu, 28 Oct 2004 01:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN387-0002SS-HP for nemo@megatron.ietf.org; Thu, 28 Oct 2004 01:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22984 for ; Thu, 28 Oct 2004 01:47:23 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN3M7-0000Qj-KL for nemo@ietf.org; Thu, 28 Oct 2004 02:01:52 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1CFA34C07F; Thu, 28 Oct 2004 14:46:44 +0900 (JST) Date: Thu, 28 Oct 2004 14:49:17 +0900 From: Thierry Ernst To: nemo Message-Id: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: tj Subject: [nemo] NEMO Agenda CFP X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday 13.00-15.00. At least the following items will be included in the agenda: - WG status - draft-ietf-nemo-basic-support - draft-ietf-nemo-mib - draft-ietf-nemo-home-network-models - draft-ietf-nemo-multihoming-issues - TAHI announcement - possible re-chartering - prefix delegation If you would like a timeslot for a topic not listed above, please send a request to both chairs by the end of this week showing: - topic - draft name and title if appropriate - time length - what issue do you intend to discuss - how does it fall into the above listed priorities of the WG or one of the NEMO charter item Requests will be honored based on available time, priorities of the NEMO WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In case several people want to discuss similar issues, we would rather advocate a discussion on the ML and one single person summarizing the issues during the meeting. Only drafts previously announced on the NEMO ML will be considered for slots. The NEMO WG Chairs. From nemo-bounces@ietf.org Thu Oct 28 02:34:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10077 for ; Thu, 28 Oct 2004 02:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3qK-0002aa-6p; Thu, 28 Oct 2004 02:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3np-0001u6-G2 for nemo@megatron.ietf.org; Thu, 28 Oct 2004 02:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09779 for ; Thu, 28 Oct 2004 02:30:28 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN41p-00013I-Vr for nemo@ietf.org; Thu, 28 Oct 2004 02:44:58 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 914A94C07F for ; Thu, 28 Oct 2004 15:29:54 +0900 (JST) Date: Thu, 28 Oct 2004 15:32:28 +0900 From: Thierry Ernst To: nemo Message-Id: <20041028153228.4cc33a8a.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [nemo] Issues on draft-terminology and draft-requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, You have noticed the release of new version of both the terminology and the requirements drafts. Please watch the change list in the drafts. I would like to remind everyone about the issues list available at http://www.sfc.wide.ad.jp/~ernst/nemo/ Comments which have been solved in the new version are marked "Accepted" or "Rejected"; those still open are marked "Open" or "New". Feel free to raise new issues. I will close the Open issues based on comments received/not received by next meeting. Thierry. > Title : Network Mobility Support Terminology > Author(s) : T. Ernst, H. Lach > Filename : draft-ietf-nemo-terminology-02.txt > Pages : 22 > Date : 2004-10-26 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt > Title : Network Mobility Support Goals and Requirements > Author(s) : T. Ernst > Filename : draft-ietf-nemo-requirements-03.txt > Pages : 13 > Date : 2004-10-26 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt From nemo-bounces@ietf.org Thu Oct 28 04:36:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19384 for ; Thu, 28 Oct 2004 04:36:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5Zr-0001v8-F9; Thu, 28 Oct 2004 04:24:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5Yb-0001kh-BC for nemo@megatron.ietf.org; Thu, 28 Oct 2004 04:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18416 for ; Thu, 28 Oct 2004 04:22:51 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN5mc-0003Gl-67 for nemo@ietf.org; Thu, 28 Oct 2004 04:37:23 -0400 Received: from [192.168.244.153] ([192.218.231.86]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i9S8MEnG015196; Thu, 28 Oct 2004 17:22:14 +0900 In-Reply-To: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> References: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75B37737-28BA-11D9-B2BA-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] NEMO Agenda CFP Date: Thu, 28 Oct 2004 17:22:08 +0900 To: Thierry Ernst X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: nemo , tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello WG Chairs We submitted a new draft about NEMO Route Optimisation Problem Statement. This draft discusses the nested problem from the view of MANET architecture. draft name: draft-clausen-nemo-ro-problem-statement-00.txt title: NEMO Route Optimisation Problem Statement topic: showing how manet is adequate for NEMO nested case. Can we have brief slots (at least 5 min) for this draft? thanks ryuji On 2004/10/28, at 14:49, Thierry Ernst wrote: > > Dear all, > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > 13.00-15.00. > > At least the following items will be included in the agenda: > - WG status > - draft-ietf-nemo-basic-support > - draft-ietf-nemo-mib > - draft-ietf-nemo-home-network-models > - draft-ietf-nemo-multihoming-issues > - TAHI announcement > - possible re-chartering > - prefix delegation > > > If you would like a timeslot for a topic not listed above, please send > a request to both chairs by the end of this week showing: > - topic > - draft name and title if appropriate > - time length > - what issue do you intend to discuss > - how does it fall into the above listed priorities of the WG or one of > the NEMO charter item > > Requests will be honored based on available time, priorities of the > NEMO > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > case several people want to discuss similar issues, we would rather > advocate a discussion on the ML and one single person summarizing the > issues during the meeting. > > Only drafts previously announced on the NEMO ML will be considered for > slots. > > > The NEMO WG Chairs. > From nemo-bounces@ietf.org Thu Oct 28 07:52:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04276 for ; Thu, 28 Oct 2004 07:52:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8mp-0002Qa-PE; Thu, 28 Oct 2004 07:49:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8gX-0001R5-Mm; Thu, 28 Oct 2004 07:43:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03553; Thu, 28 Oct 2004 07:43:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8ub-00078j-I5; Thu, 28 Oct 2004 07:57:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2004 14:00:25 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9SBg9TB000255; Thu, 28 Oct 2004 13:42:39 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 13:42:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Date: Thu, 28 Oct 2004 13:39:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3898BE@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcS8fs+a9tlYOP+6RVSg7dgChKCVtAARw8MA From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Ville Nuorvala" X-OriginalArrivalTime: 28 Oct 2004 11:42:11.0865 (UTC) FILETIME=[29D52890:01C4BCE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: jeudi 28 octobre 2004 01:37 > To: Ville Nuorvala > Cc: nemo@ietf.org; mip6@ietf.org; Erik Nordmark > Subject: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) >=20 > sorry for the cross posting, but here is something to=20 > consider when RFC 3775 is revised. >=20 > Ville Nuorvala wrote: > > On Wed, 27 Oct 2004, Erik Nordmark wrote: > >=20 > >=20 > >>When the CN sends packets to HoA(MN) it would match the=20 > first binding. > >>I don't think RFC 3775 prescribes what a CN should do when, after=20 > >>applying the binding and adding RH2 to the packet, there is another=20 > >>binding which matches what is then in the destination field of the=20 > >>packet. (But it would make sense to check this in the spec). > >>So different CN implementations might do different things such as: > >> - ignore the second binding > >> - apply the second binding in a recursive way i.e. add another RH2 > >> header > >> - fail (drop the packet or crash) > >=20 > >=20 > > RFC 3775 Section 6.1.7 says: > >=20 > > Binding Updates for a care-of address which is not a=20 > unicast routable > > address MUST be silently discarded. Similarly, the=20 > Binding Update > > MUST be silently discarded if the care-of address=20 > appears as a home > > address in an existing Binding Cache entry, with its=20 > current location > > creating a circular reference back to the home address=20 > specified in > > the Binding Update (possibly through additional entries). > >=20 > > What this exactly means is open to interpretation. Strictly=20 > speaking=20 > > it might mean it is ok to have several linked entries as=20 > long as they=20 > > don't create a circular reference, but it is unlikely. >=20 > yes, it should be possible to have several linked binding=20 > cache entries. >=20 > >=20 > > I think the general assumption is that there will be just=20 > one RH type=20 > > 2 per packet. That's at least what we assume in MIPL, but=20 > of course I=20 > > can't speak on the behalf other implementations. >=20 > but we seem to have disallowed by the above by mistake in RFC 3775. >=20 > RFC 3775 restricts RH Type 2 to only one address (segments=20 > left is always 1). RFC 2460 says a routing header can occur=20 > only once in a packet. (except for destinations options=20 > header, all other extension headers can appear only once in a packet). >=20 > RFC 3775 should have allowed more than one address in RH type=20 > 2 and required that the desination address on the packet and=20 > the next addressed to be processed in the routing header=20 > belong to the same node. this would have allowed us to=20 > include more than one address in the routing header, but=20 > still satisfy the security requiements of Mobile IPv6. >=20 Agreed. That's actually part of the RRH spec.=20 There's also a rule that enforces that the RH2 can only be forwarded down the nested tree. If you look at=20 9.4 Processing of the extended Routing Header Type 2 in http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-05.txt You'll find that the constraint of teh next hop being in a same node is replaced by=20 =20 /* new security check */ if Address [i] doesn't belong to one of the Mobile Network prefixes { discard the packet return } Pascal From nemo-bounces@ietf.org Thu Oct 28 09:31:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11564 for ; Thu, 28 Oct 2004 09:31:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAHB-0003EA-Kz; Thu, 28 Oct 2004 09:25:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNADn-0002sL-MV for nemo@megatron.ietf.org; Thu, 28 Oct 2004 09:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10990 for ; Thu, 28 Oct 2004 09:21:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNARr-0000sU-PD for nemo@ietf.org; Thu, 28 Oct 2004 09:36:17 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2004 15:38:55 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9SDKjT1025813; Thu, 28 Oct 2004 15:21:06 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 15:21:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO taxonomy Date: Thu, 28 Oct 2004 15:21:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC38994F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS8ZfLG9QzhgNyFTNmgk9N1IvpTCAAXb+1g From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 28 Oct 2004 13:21:05.0313 (UTC) FILETIME=[FA717910:01C4BCF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , marcelo bagnulo braun , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > Would do you mean by "ATTACK"? I mean causing the flow to fail.Maybe CN trying to make sense of a HoA = option in a CoT message and updating the wrong binding? Or having a chain of HoA options so that an existing implementation gets = confused? If we are really interested in digging here, I can try to figure out a = scenario where such a thing happens.=20 >=20 > The RR tests are independent so a proxying MR doesn't need to=20 > interfere with a VMN doing the same thing. But there is an=20 > issue with a CN seeing BUs that create "nested" bindings. > Let's take an example: > MN has HA(MN), HoA(MN); it configured CoA(MN) from the mobile > network prefix; let's called the CoA P1::IID >=20 > MR has HA(MR), HoA(MR), gets CoA(MR) from the AR and advertises > P1 on the mobile network. >=20 > Thus the MN would try to setup a binding in the CN from HoA(MN) > to P1:IID. I doing so it would receive a HoT tunneled from > its HA (which the MR can't even see if ESP is used on the > tunnel) and a CoT addressed to P1::IID. >=20 > Should the MR try to do a proxy RO on behalf of the MN > then the only thing the MR knows is that it has a MNN with > the IP address CoA(MN); it might not be able to tell that this > is a VMN. For example, if the VMN does not perform RO and has a > ESP tunnel with its HA, to the MR it looks like a MNN which has > an ESP tunnel which could be a VPN or whatever. > Thus the MR would try to route optimize by creating a binding > in the CN for CoA(MN) (P1:IID) to the CoA(MR). > In doing so, it would need process the CoT sent to CoA(MR), > but this doesn't interfere with any CoT that the MN would > trigger itself since the destination address is different. > The MR would also need to intercept the HoT packet addressed > to P1:IID, but this doesn't interfere with the above HoT > tunneled to HoA(MN). >=20 > Hence both the MR and MN can complete the BUs to the CN. > If they do, it would result in two separate binding on the CN: > from HoA(MN) -> P1::IID > from P1:IID -> CoA(MR) I think I understand what you mean; yes, that much should work... with the restrictions already in the list from Ville and Vijay.=20 Let's look at the flows a bit more: case one) VMN does not attempt RO yet. So the only CN is HA(VMN). So we end up with MR doing RR test with HA(VMN). Say HA(VMN) accepts = trying. The security you had by signing the careof in MIP6 is now back to that = of the RR test.=20 We have to see what threats this opens. In short, I think that the result is the same security as that of RRH = (please have a glance at: http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-he= ader-05.txt ) AFAIK, the only 'successful' attack identified to date is a time = shifting attack,=20 discussed recently on this list with Marcelo. It happens if the interval = between full=20 RRHs is very long. Actually, the default in the draft is on every = packet,=20 and the usage of RH3 is optional and implementation dependent.=20 =20 Case two) VMN attempts RO to CN, sends traffic directly to CN; MR sees = that and starts its own RO to CN. Then we end up with what teh RRH draft calls "1.1 Recursive = complexity" and in particular "3. CN operation" The text in that RRH section has been reused and then modified as the RO = taxonomy draft evolved. I'm not copying the RRH text here, but if you wish to continue on this = topic (please do :) then maybe we can comment on that text directly. Case three: MR is attached to MR' in a nested configuration. Think about the egress direction. Would we end up with a list of Home = Addresses? There's no definition in the order in which they are stacked, = for instance, and what the CN would do with that.=20 This discussion is very, very close to the one we had in my group when = we designed and implemented RRH.=20 Pascal From nemo-bounces@ietf.org Thu Oct 28 14:12:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06407 for ; Thu, 28 Oct 2004 14:12:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCla-0004M8-Ov; Thu, 28 Oct 2004 12:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBoG-0006mG-Vr; Thu, 28 Oct 2004 11:03:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21971; Thu, 28 Oct 2004 11:03:27 -0400 (EDT) Message-Id: <200410281503.LAA21971@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:03:27 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : T. Ernst, et al. Filename : draft-ietf-nemo-multihoming-issues-01.txt Pages : 35 Date : 2004-10-27 This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110152.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 28 15:49:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27499 for ; Thu, 28 Oct 2004 15:49:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCq0-0007Or-WA; Thu, 28 Oct 2004 12:09:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNC7x-0007Df-VL; Thu, 28 Oct 2004 11:23:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26139; Thu, 28 Oct 2004 11:23:48 -0400 (EDT) Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCM3-0004qn-5L; Thu, 28 Oct 2004 11:38:23 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 12A3FF2; Thu, 28 Oct 2004 11:23:12 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 106C430C; Thu, 28 Oct 2004 10:23:10 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0000789337; Thu, 28 Oct 2004 11:23:08 -0400 (EDT) Message-ID: <41810EDB.3070106@hp.com> Date: Thu, 28 Oct 2004 11:23:07 -0400 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> <41803123.3060901@iprg.nokia.com> In-Reply-To: <41803123.3060901@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >>> When the CN sends packets to HoA(MN) it would match the first binding. >>> I don't think RFC 3775 prescribes what a CN should do when, after >>> applying the binding and adding RH2 to the packet, there is another >>> binding which matches what is then in the destination field of the >>> packet. (But it would make sense to check this in the spec). >>> So different CN implementations might do different things such as: >>> - ignore the second binding >>> - apply the second binding in a recursive way i.e. add another RH2 >>> header >>> - fail (drop the packet or crash) I know I purposefully did 1) to not have nesting problems, it's just been a while since I played with that code to remember more. >> RFC 3775 Section 6.1.7 says: >> >> Binding Updates for a care-of address which is not a unicast routable >> address MUST be silently discarded. Similarly, the Binding Update >> MUST be silently discarded if the care-of address appears as a home >> address in an existing Binding Cache entry, with its current location >> creating a circular reference back to the home address specified in >> the Binding Update (possibly through additional entries). >> >> What this exactly means is open to interpretation. Strictly speaking it >> might mean it is ok to have several linked entries as long as they don't >> create a circular reference, but it is unlikely. But how can this happen? If I'm a MN at COA1, would I ever send a BU to anyone to say COA1 is now at COA2? I would think you'd just update the existing binding to point at COA2. In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA would construct a multi-hop routing header, then send it to the first hop. What am I missing? > RFC 3775 should have allowed more than one address in RH type 2 > and required that the desination address on the packet and the next > addressed to be processed in the routing header belong to the same > node. this would have allowed us to include more than one address > in the routing header, but still satisfy the security requiements > of Mobile IPv6. I guess I don't agree 100% with this since RH2 was supposed to be a special case to hold the HoA. Extending it to have more than that seems to turn it into a glorified RH0 with MRs in it, but that's my opinion... -Brian From nemo-bounces@ietf.org Thu Oct 28 19:19:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08345 for ; Thu, 28 Oct 2004 19:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGYF-0006iH-R6; Thu, 28 Oct 2004 16:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNEnF-0002vQ-3S; Thu, 28 Oct 2004 14:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06761; Thu, 28 Oct 2004 14:14:36 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNF1L-0001HO-CR; Thu, 28 Oct 2004 14:29:12 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9SIEWNH006039; Thu, 28 Oct 2004 12:14:33 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9SIEUJQ000727; Thu, 28 Oct 2004 20:14:31 +0200 (MEST) Message-ID: <41813733.5030805@sun.com> Date: Thu, 28 Oct 2004 11:15:15 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Subject: Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> <41803123.3060901@iprg.nokia.com> <41810EDB.3070106@hp.com> In-Reply-To: <41810EDB.3070106@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Brian Haley wrote: > But how can this happen? If I'm a MN at COA1, would I ever send a BU to > anyone to say COA1 is now at COA2? I would think you'd just update the > existing binding to point at COA2. > > In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA > would construct a multi-hop routing header, then send it to the first hop. > > What am I missing? The Nemo context where this was discussed. There might be a MR which will help a MNN by sending BUs on its behalf and the MNN might be a MIPv6 MN doing its own BUs. The MR only "sees" what the MNN has as its CoA so we end up with the MR creating a binding in the CN from CoA(MN) -> CoA(MR) and the MN creating a binding in the same CN from HoA(MN) -> CoA(MN). My question was whether RFC 3775 defined what would happen if this was done; for instance if it specified to ignore the second binding. Seems like it does not. Erik From nemo-bounces@ietf.org Thu Oct 28 19:20:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08599 for ; Thu, 28 Oct 2004 19:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGZw-0002i3-1U; Thu, 28 Oct 2004 16:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNF69-00024k-0D for nemo@megatron.ietf.org; Thu, 28 Oct 2004 14:34:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10974 for ; Thu, 28 Oct 2004 14:34:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFKG-0002jR-5d for nemo@ietf.org; Thu, 28 Oct 2004 14:48:44 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9SIY47q014481; Thu, 28 Oct 2004 11:34:05 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9SIY1JQ002425; Thu, 28 Oct 2004 20:34:02 +0200 (MEST) Message-ID: <41813BC6.6090405@sun.com> Date: Thu, 28 Oct 2004 11:34:46 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC38994F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC38994F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , marcelo bagnulo braun , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> Would do you mean by "ATTACK"? > > I mean causing the flow to fail.Maybe CN trying to make sense of a > HoA option in a CoT message and updating the wrong binding? Or having > a chain of HoA options so that an existing implementation gets > confused? 1) The CN doesn't receive CoT messages - did you mean CoTI? 2) The {C,H}oT{,I} messages do not modify any state on the CN; only the BU does. > If we are really interested in digging here, I can try to figure out > a scenario where such a thing happens. Please do. I don't see any issue than creating multiple separate binding on the CN. > Let's look at the flows a bit more: > > case one) VMN does not attempt RO yet. So the only CN is HA(VMN). So > we end up with MR doing RR test with HA(VMN). Say HA(VMN) accepts > trying. The security you had by signing the careof in MIP6 is now > back to that of the RR test. We have to see what threats this opens. In this case the HA ends up with two bindings - the home binding from HoA(MN) to P1::IID and the binding created by the MR from P1:IID to CoA(MR). What does RFC 3775 say about that? > The text in that RRH section has been reused and then modified as the > RO taxonomy draft evolved. I'm not copying the RRH text here, but if > you wish to continue on this topic (please do :) then maybe we can > comment on that text directly. Sorry, but I'm trying to have a discussion about the problem space, and not comment on any particular proposed solution; we need to understand the problem space first IMHO. > Case three: MR is attached to MR' in a nested configuration. Think > about the egress direction. Would we end up with a list of Home > Addresses? There's no definition in the order in which they are > stacked, for instance, and what the CN would do with that. You need to specify where the addresses come from in this case. Is there prefix delegation so that each MR gets a piece of address space from the AR, or not? If you have delegated prefixes (which are marked as special so that LFNs don't use them) then each nemo-aware VMN can use a CoA from the AR delegated prefix and just MIPv6 BUs. That is simple, but assumes delegated address space. Erik From nemo-bounces@ietf.org Thu Oct 28 23:26:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02752 for ; Thu, 28 Oct 2004 23:26:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMyp-0006oY-In; Thu, 28 Oct 2004 22:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMGk-00086i-UV for nemo@megatron.ietf.org; Thu, 28 Oct 2004 22:13:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22142 for ; Thu, 28 Oct 2004 22:13:33 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMUv-00084Y-UV for nemo@ietf.org; Thu, 28 Oct 2004 22:28:15 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9T2ADmF010338 for ; Fri, 29 Oct 2004 10:10:13 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id AF854B240C6 for ; Fri, 29 Oct 2004 10:16:05 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-Gfze/5eqpQ1WI3wgHPsI" Organization: Panasonic Singapore Laboratories Message-Id: <1099016164.10275.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 29 Oct 2004 10:16:05 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-03.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Gfze/5eqpQ1WI3wgHPsI Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, A new version (-03) of the RO Taxonomy Draft is ready for your reading pleasure. This time round, it is a major update. The draft is re-structured to better pose itself to fulfill the WG Charter requirement. However, there is still room for improvement. For that, we would greatly appreciate comments. A brief overview of changes: -> Added problem statement for route optimization. -> Discusses benefits of route optimizations -> lists a taxonomy for RO Solution Space (this is a bit different from previous version) -> explores into issues route optimization solution might face, including security considerations -> all solution-specific descriptions are moved to Appendix /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-thubert-nemo-ro-taxonomy-03.txt Date: Thu, 28 Oct 2004 10:54:58 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Taxonomy of Route Optimization models in the Nemo Context Author(s) : P. Thubert, et al. Filename : draft-thubert-nemo-ro-taxonomy-03.txt Pages : 34 Date : 2004-10-27 With current Network Mobility (NEMO) Basic Support, all communications to and from mobile network nodes must go through the MR-HA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay. To overcome these limitations, one might have to turn to route optimization (RO) for NEMO. This memo documents various types of route optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO route optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thubert-nemo-ro-taxonomy-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-10-28105941.I-D@ietf.org> ________________________________________________________________________ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-Gfze/5eqpQ1WI3wgHPsI Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-28105941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt --=-Gfze/5eqpQ1WI3wgHPsI Content-Type: Message/External-body; name="draft-thubert-nemo-ro-taxonomy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-28105941.I-D@ietf.org> --=-Gfze/5eqpQ1WI3wgHPsI-- From nemo-bounces@ietf.org Thu Oct 28 23:41:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03959 for ; Thu, 28 Oct 2004 23:41:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNFU-0001Bs-ER; Thu, 28 Oct 2004 23:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMmQi-0000g4-GS for nemo@megatron.ietf.org; Wed, 27 Oct 2004 07:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27824 for ; Wed, 27 Oct 2004 07:57:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMmeY-0003dz-Na for nemo@ietf.org; Wed, 27 Oct 2004 08:11:48 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2004 04:58:36 -0700 X-BrightmailFiltered: true Received: from dshell-w2k01.cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9RBuoGn000399; Wed, 27 Oct 2004 04:56:51 -0700 (PDT) Message-Id: <6.0.3.0.2.20041027075028.03d40108@lint> X-Sender: dshell@lint X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 27 Oct 2004 07:56:50 -0400 To: Vijay Devarapalli From: Daniel J Shell Subject: Re: NEMO throught IPv4 networks (was Re: [nemo] NAT/PAT transfersal overIPv4 networks) In-Reply-To: <417F5182.1040505@iprg.nokia.com> References: <7892795E1A87F04CADFCCF41FADD00FC345025@xmb-ams-337.emea.cisco.com> <417F5182.1040505@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Thu, 28 Oct 2004 23:16:16 -0400 Cc: nemo , "Pascal Thubert \(pthubert\)" , Thierry Ernst , ryuji@sfc.wide.ad.jp, "T.J.Kniveton" , pthubert@cisco.ccom.cnri.reston.va.us, William.D.Ivancic@nasa.gov X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org At 03:42 AM 10/27/2004, Vijay Devarapalli wrote: >Pascal Thubert (pthubert) wrote: > >>Hi Vijay: >>At least we start the discussion ... and we can discuss pro/cons, >>applicability, things like that, and improve the solutions. >>Note that for the specifics of the tunnel overhead, it is possible to >>apply some header compression technique, this is nothing new. > >yes it is. what do you have on mind? ROHC? why would I opt for a >solution with a tunnel overhead, when I can use something >without a tunnel overhead. Vijay If I use header compression then my firewall will have to know something about this. Since I may have some of my HAs behind a firewall. Some of my customers already do this will Mobile Networking IPv4. I do not seem them changing for IPv6 implementations. So I see the need for header compression but from my customers perspective it is not that big of an issue for now. As long as I can turn header compression on or off then it make sense. >>Actually we have discussed header compression internally long ago. But >>improving the draft requires the group attention. Otherwise it's moot. >>This is why we stopped the writing up for so long. > >okay. > >>Now in terms of requirement, NEMO might consider: >>- we have to support NAT or plain public, and if so, which types of >>NATs. I'm afraid that this is REALLY important. >>- whether it's acceptable to force that the IPv4 be terminated >>physically at the HA. Surely it is in some cases as of today. Still it's >>a limitation, which might have its own deployment and security >>consequences. I believe it's better if it is just an option for the >>deployement. >>- If we want the solution to be deployable incrementally to MIP6/NEMO, >>and if there's value that the solution might be deployed with no change >>to the HA. >>The IPv4 NAT/PAT traversal question has been there for quite some time. >>I believe that at this point, we can take the time to understand what we >>have on the table, and if it's possible, take the best of it all and >>make that a standard. > >I agree that NEMO should consider these requirements. Yes support of NAT/PAT is very important and I have been running into this will almost all of my deployments. On the IPv4 side support for DHCP address on interfaces with NAT sort of like we have for cable-devices. I have some folks hotelling with Mobile networks and this is becoming an issue. Regards an Shell CISCO GSU Ip mobility/wireless/satellite 440 331 5663 From nemo-bounces@ietf.org Thu Oct 28 23:44:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04409 for ; Thu, 28 Oct 2004 23:44:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNMT-0007Ip-RN; Thu, 28 Oct 2004 23:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDtp-0005An-PD; Thu, 28 Oct 2004 13:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23413; Thu, 28 Oct 2004 13:17:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNE7v-0005CE-RC; Thu, 28 Oct 2004 13:31:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9SHGbt20090; Thu, 28 Oct 2004 20:16:37 +0300 Date: Thu, 28 Oct 2004 20:16:37 +0300 (EEST) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Thu, 28 Oct 2004 23:23:30 -0400 Cc: nemo@ietf.org, mip6@ietf.org, mip4@ietf.org, miptrans@ops.ietf.org, v6ops@ops.ietf.org, Tsirtsis George Subject: [nemo] Re: MIP and transition issues X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I've created a new mailing list to discuss Mobile IP transition issues. There is no single good mailing list to do that, and crossposting to upto 4 WGs is not a good idea. Address: miptrans@ops.ietf.org To subscribe: 'subscribe miptrans' in the body to majordomo@psg.com Web archives: http://ops.ietf.org/lists/miptrans/ **** DO NOT POST ANY FURTHER MESSAGES ON V6OPS LIST! **** (if you respond, please remove the other lists from Cc:) FWIW, I also noticed there is another related draft: Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks draft-larsson-v6ops-mip-scenarios-00.txt (Larsson, Gustafsson, Levkowetz) As there have been various presentations on v6ops two times already, with no clear resolution, it would seem to be useful to have various people working on different documents bang their heads together on miptrans or offlist on which document(s) describing the problems and scenarios is the most appropriate as a basis for discussion. On Mon, 25 Oct 2004, Soliman, Hesham wrote: > Sorry for the cross posting, but this issue is being > discussed in all WG listed. > > I submitted the following two drafts last night: > draft-tsirtsis-dsmip-problem > draft-soliman-v4v6-mipv6- > > The first deals with the problem statement and the > second is one of the solution for using MIPv6 only. > There is another draft that proposes using MIPv4 > only: draft-tsirtsis-v4v6-mipv4 > > I hope we can discuss the problem statement and scenarios > in the next meeting. While the problem statement is on the mip6 > charter, it would be useful if we can have a slot allocated for > this in v6ops. > > thx > Hesham > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Fri Oct 29 00:27:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07197 for ; Fri, 29 Oct 2004 00:27:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNO1p-00028N-0o; Fri, 29 Oct 2004 00:06:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBHP-0004iy-AQ for nemo@megatron.ietf.org; Thu, 28 Oct 2004 10:29:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17342 for ; Thu, 28 Oct 2004 10:29:27 -0400 (EDT) Message-Id: <200410281429.KAA17342@ietf.org> Received: from picard.comnets.rwth-aachen.de ([137.226.4.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBVR-0002TF-Je for nemo@ietf.org; Thu, 28 Oct 2004 10:44:02 -0400 Received: (qmail 8452 invoked from network); 28 Oct 2004 14:28:35 -0000 Received: from unknown (HELO Mars) (ber@137.226.4.234) by picard.comnets.rwth-aachen.de with SMTP; 28 Oct 2004 14:28:35 -0000 From: "Lars Berlemann" To: "'Lars Berlemann'" Date: Thu, 28 Oct 2004 16:28:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS8+mfRljMl9BiZTHyRcu7ti4odNA== X-Spam-Score: 1.2 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Oct 2004 00:06:14 -0400 Subject: [nemo] European Wireless 2005 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit --------------------------------------------------------------- * Our apologies if you receive multiple copies of this e-mail * --------------------------------------------------------------- Dear Madam, Dear Sir, We are pleased to inform you that the next European Wireless Conference will be held in Nicosia, Cyprus, on April 10-13, 2005. The European Wireless 2005 Conference (EW'05) focuses on technologies, protocols, services and applications that will enable a full seamless and nomadic user access to new classes of multimedia services with a user-centric focus. Service provision will occur at the home, at the workplace, at leisure and during travel. The vision is to integrate the wireless local area and next generation cellular networks and develop the next generation of future wireless communication. Such networks will enable the provision of ubiquitous wireless services, which will become more and more innovative as they are driven by the consumer demands of the user and as a result of competition between the service providers. This is the main theme chosen for the European Wireless 2005 Conference. You can find the different topic areas of this conference on the attached Call for Papers or visit the European Wireless Web Page http://www.european-wireless2005.de in order to get the updated information about this conference. We hope that you will take this opportunity into consideration and that you will submit a paper not later than November 12, 2004 to the on-line Submission Interface of EDAS http://www.edas.info . We would appreciate if you could also inform your colleagues or partners about this conference and forward them this e-mail. We thank you in advance for your support in making this conference to be a success and are looking forward to welcoming you in Nicosia. With kind regards on behalf of the EW'05 TPC-Chairs, Lars Berlemann Important dates EW'05: Full Paper Submissions Due: November 12, 2004 Notification of Acceptance : January 24, 2005 Camera-Ready Due: February 19, 2005 -- ------------------------------------------ Lars Berlemann Chair of Communication Networks RWTH Aachen University Phone: +49 (0)241 80 27248 E-Mail: ber@comnets.rwth-aachen.de From nemo-bounces@ietf.org Fri Oct 29 04:55:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09185 for ; Fri, 29 Oct 2004 04:55:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSM2-0000QE-4G; Fri, 29 Oct 2004 04:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRzP-000581-67 for nemo@megatron.ietf.org; Fri, 29 Oct 2004 04:20:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06715 for ; Fri, 29 Oct 2004 04:20:01 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27] helo=jazz.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSDd-0000Ub-Td for nemo@ietf.org; Fri, 29 Oct 2004 04:34:46 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id i9T8JToa026907 for ; Fri, 29 Oct 2004 17:19:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id i9T8JUr24937 for ; Fri, 29 Oct 2004 17:19:30 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id i9T8JQE01826 for ; Fri, 29 Oct 2004 17:19:26 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id i9T7fsZ00620 for nemo@ietf.org; Fri, 29 Oct 2004 16:41:54 +0900 (JST) Received: from nancy (localhost [127.0.0.1]) by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i9T7frI00597 for ; Fri, 29 Oct 2004 16:41:53 +0900 (JST) Message-Id: <200410290741.i9T7frI00597@soml23.jp.panasonic.com> Date: Fri, 29 Oct 2004 16:41:53 +0900 From: Masayuki Kumazawa Subject: Issue 17(Re: [nemo] Issues on draft-terminology and draft-requirements) To: In-Reply-To: <20041028153228.4cc33a8a.ernst@sfc.wide.ad.jp> References: <20041028153228.4cc33a8a.ernst@sfc.wide.ad.jp> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Thierry and all, I considered the issue 17(Split Network). I think the following definition is appropriate. ----------------------------------------------------------------- Split Network is that MRs in different mobile networks share the same MNPs. ----------------------------------------------------------------- Best Regards, Masayuki <20041028153228.4cc33a8a.ernst@sfc.wide.ad.jp> From Thierry Ernst-san > >Dear all, > >You have noticed the release of new version of both the terminology and >the requirements drafts. Please watch the change list in the drafts. > >I would like to remind everyone about the issues list available at >http://www.sfc.wide.ad.jp/~ernst/nemo/ > >Comments which have been solved in the new version are marked "Accepted" >or "Rejected"; those still open are marked "Open" or "New". > >Feel free to raise new issues. I will close the Open issues based on >comments received/not received by next meeting. > >Thierry. > > >> Title : Network Mobility Support Terminology >> Author(s) : T. Ernst, H. Lach >> Filename : draft-ietf-nemo-terminology-02.txt >> Pages : 22 >> Date : 2004-10-26 > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt > > >> Title : Network Mobility Support Goals and Requirements >> Author(s) : T. Ernst >> Filename : draft-ietf-nemo-requirements-03.txt >> Pages : 13 >> Date : 2004-10-26 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt ----------- M.Kumazawa From nemo-bounces@ietf.org Fri Oct 29 05:21:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10670 for ; Fri, 29 Oct 2004 05:21:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSQo-0004L3-Mw; Fri, 29 Oct 2004 04:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSDn-0004FY-J0 for nemo@megatron.ietf.org; Fri, 29 Oct 2004 04:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07652 for ; Fri, 29 Oct 2004 04:34:53 -0400 (EDT) Received: from salzburg.ucdavis.edu ([169.237.104.162]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSS2-0000nQ-4P for nemo@ietf.org; Fri, 29 Oct 2004 04:49:38 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by salzburg.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9T8YnlZ022651; Fri, 29 Oct 2004 01:34:50 -0700 (PDT) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9T8Ynqc013965; Fri, 29 Oct 2004 01:34:49 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id i9T8YmBQ013964; Fri, 29 Oct 2004 01:34:48 -0700 (PDT) Date: Fri, 29 Oct 2004 01:34:48 -0700 (PDT) Message-Id: <200410290834.i9T8YmBQ013964@tremex.ucdavis.edu> To: Thierry Ernst , nemo Subject: RE: [nemo] NEMO Agenda CFP From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Thierry and T.J. We have submitted a draft draft-zhao-nemo-ro-ps-00.txt. Can we have a time slot for it? Thanks for your considerations. Sicnerely, fan - topic: NEMO RO problem statement and analysis - draft name: draft-zhao-nemo-ro-ps-00.txt - title: NEMO Route Optimization Problem Statement, Requirements and Evaluation Considerations - time length: 10 minutes - what issue do you intend to discuss I will focus on: 1. The terms of Correspondent Agent and Anchor Point 2. Limitation of NEMO Basic Support protocol (problem statement) 3. The related tradeoffs 4. Future works 5. Appendix: How various RO solutions are categorized based on the Anchor Point rather than a perspective of problem types (also in an abstract fashion) I will also mention: 1. optimal route and non-optimal route in the difference scenarios (problem statement) 2. The formalization of the nested NEMO network In short we want to show the essentiality of NEMO RO support and NEMO Basic Support, the new challenges faced by NEMO RO support compared with MIP6 RO support, and how a complete RO solution space is categorized from a different angle. However, I will not cover the requirement and evaluation considerations. > > Dear all, > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > 13.00-15.00. > > At least the following items will be included in the agenda: > - WG status > - draft-ietf-nemo-basic-support > - draft-ietf-nemo-mib > - draft-ietf-nemo-home-network-models > - draft-ietf-nemo-multihoming-issues > - TAHI announcement > - possible re-chartering > - prefix delegation > > > If you would like a timeslot for a topic not listed above, please send > a request to both chairs by the end of this week showing: > - topic > - draft name and title if appropriate > - time length > - what issue do you intend to discuss > - how does it fall into the above listed priorities of the WG or one of > the NEMO charter item > > Requests will be honored based on available time, priorities of the NEMO > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > case several people want to discuss similar issues, we would rather > advocate a discussion on the ML and one single person summarizing the > issues during the meeting. > > Only drafts previously announced on the NEMO ML will be considered for > slots. > > > The NEMO WG Chairs. > > From nemo-bounces@ietf.org Fri Oct 29 05:27:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11118 for ; Fri, 29 Oct 2004 05:27:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSnr-0007CO-Ou; Fri, 29 Oct 2004 05:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSMw-0000sF-2o for nemo@megatron.ietf.org; Fri, 29 Oct 2004 04:44:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08346 for ; Fri, 29 Oct 2004 04:44:19 -0400 (EDT) Received: from newyork.ucdavis.edu ([169.237.104.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSbA-0000yJ-PK for nemo@ietf.org; Fri, 29 Oct 2004 04:59:05 -0400 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by newyork.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9T8iHtI018677; Fri, 29 Oct 2004 01:44:17 -0700 (PDT) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9T8iHIt003018; Fri, 29 Oct 2004 01:44:17 -0700 (PDT) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id i9T8iHoP003017; Fri, 29 Oct 2004 01:44:17 -0700 (PDT) Date: Fri, 29 Oct 2004 01:44:17 -0700 (PDT) Message-Id: <200410290844.i9T8iHoP003017@lymeon.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [nemo] Fwd: I-D ACTION:draft-zhao-nemo-ro-ps-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, Sorry for this late announcement. We have submitted a NEMO RO problem draft. Your comments are very appreciated. Sincerely, fan A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NEMO Route Optimization Problem Statement, Requirements and Evaluation Considerations Author(s) : F. Zhao, et al. Filename : draft-zhao-nemo-ro-ps-00.txt Pages : 21 Date : 2004-10-21 This document describes and analyzes the routing optimization problem in NEMO, defines the requirements that must be met by NEMO route optimization solutions and then describes the metrics to evaluate the performance of NEMO route optimization solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zhao-nemo-ro-ps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-zhao-nemo-ro-ps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From nemo-bounces@ietf.org Fri Oct 29 05:49:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12727 for ; Fri, 29 Oct 2004 05:49:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT1e-0007em-LT; Fri, 29 Oct 2004 05:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSco-0008Fu-Fu for nemo@megatron.ietf.org; Fri, 29 Oct 2004 05:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09544 for ; Fri, 29 Oct 2004 05:00:44 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSr2-0001I1-M9 for nemo@ietf.org; Fri, 29 Oct 2004 05:15:30 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2004 11:18:12 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T8xsrQ023096; Fri, 29 Oct 2004 11:00:09 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 10:59:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO taxonomy Date: Fri, 29 Oct 2004 10:59:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC389BB1@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS9RMLFrHACJicVSUuub4ebfvuxaQAUBCUw From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 29 Oct 2004 08:59:51.0961 (UTC) FILETIME=[A6CF8090:01C4BD95] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , marcelo bagnulo braun , Chan-Wah NG , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > > The text in that RRH section has been reused and then modified as = the > > RO taxonomy draft evolved. I'm not copying the RRH text here, but if > > you wish to continue on this topic (please do :) then maybe we can > > comment on that text directly. >=20 > Sorry, but I'm trying to have a discussion about the problem space, = and > not comment on any particular proposed solution; we need to understand > the problem space first IMHO. Yes, I was doing just that. The text I mentioned was not solution space = but suggested that the approach that you detailed was not optimum. = Here's the text in question: 1.1 Recursive complexity A number of drafts and publications suggest -or can be extended to- a model where the Home Agent and any arbitrary Correspondent would actually get individual binding from the chain of nested Mobile Routers, and form a routing header appropriately. An intermediate MR would keep track of all the pending communications between hosts in its subtree of Mobile Networks and their CNs, and a binding message to each CN each time it changes its point of attachment. If this was done, then each CN, by receiving all the binding messages and processing them recursively, could infer a partial topology of the nested Mobile Network, sufficient to build a multi-hop routing header for packets sent to nodes inside the nested Mobile Network. However, this extension has a cost: 1. Binding Update storm when one MR changes its point of attachment, it needs to send a BU to all the CNs of each node behind him. When the Mobile Network is nested, the number of nodes and relative CNs can be huge, leading to congestions and drops. 2. Protocol Hacks Also, in order to send the BUs, the MR has to keep track of all the traffic it forwards to maintain his list of CNs. In case of IPSec tunneled traffic, that CN information may not be available. 3. CN operation The computation burden of the CN becomes heavy, because it has to analyze each BU in a recursive fashion in order to infer nested Mobile Network topology required to build a multi hop routing header. 4. Missing BU If a CN doesn't receive the full set of PSBU sent by the MR, it will not be able to infer the full path to a node inside the nested Mobile Network. The RH will be incomplete and the packet may or may not be delivered. 5. Obsolete BU If the Binding messages are sent asynchronously by each MR, then, when the relative position of MRs and/or the TLMR point of attachment change rapidly, the image of Mobile Network that the CN maintains is highly unstable. If only one BU in the chain is obsolete due to the movement of an intermediate MR, the connectivity may be lost. A conclusion is that the path information must be somehow aggregated to provide the CN with consistent snapshots of the full path across the Mobile Network. This can be achieved by an IPv6 form of loose source / record route header, that we introduce here as a Reverse Routing Header Pascal From nemo-bounces@ietf.org Fri Oct 29 05:50:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12795 for ; Fri, 29 Oct 2004 05:50:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT1g-0007fs-AJ; Fri, 29 Oct 2004 05:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSiN-00043h-Ol; Fri, 29 Oct 2004 05:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09759; Fri, 29 Oct 2004 05:06:29 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSwc-0001NA-TI; Fri, 29 Oct 2004 05:21:15 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2004 11:23:57 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T95brS024830; Fri, 29 Oct 2004 11:05:54 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 11:05:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Date: Fri, 29 Oct 2004 11:05:45 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcS9J1JAiXa8GtGyRU2PSR/FVxEFBAAbrpDA From: "Pascal Thubert \(pthubert\)" To: "Brian Haley" , "Vijay Devarapalli" X-OriginalArrivalTime: 29 Oct 2004 09:05:50.0173 (UTC) FILETIME=[7C5250D0:01C4BD96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Erik Nordmark X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > > RFC 3775 should have allowed more than one address in RH type 2 > > and required that the desination address on the packet and the next > > addressed to be processed in the routing header belong to the same > > node. this would have allowed us to include more than one address > > in the routing header, but still satisfy the security requiements > > of Mobile IPv6. >=20 > I guess I don't agree 100% with this since RH2 was supposed to be a special case > to hold the HoA. Extending it to have more than that seems to turn it into a > glorified RH0 with MRs in it, but that's my opinion... >=20 Well, there is a difference: we can (and must) put a restriction in the usage of the extended RH2. And that restriction is to go down the nested tree only. In particular if the source routed path in the RH2 is strict (not loose), we can force that the next entry in the RH is actually part of an MNP of the MR that processes the RH2. This is explicitly what the RRH draft says. Pascal From nemo-bounces@ietf.org Fri Oct 29 05:55:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13271 for ; Fri, 29 Oct 2004 05:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT21-00081g-Cd; Fri, 29 Oct 2004 05:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSo5-0007MM-H5 for nemo@megatron.ietf.org; Fri, 29 Oct 2004 05:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10098 for ; Fri, 29 Oct 2004 05:12:22 -0400 (EDT) Received: from frankfurt.ucdavis.edu ([169.237.104.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNT2J-0001Tu-CE for nemo@ietf.org; Fri, 29 Oct 2004 05:27:08 -0400 Received: from cucujus.ucdavis.edu (cucujus.ucdavis.edu [169.237.104.179]) by frankfurt.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i9T9CJTR009071; Fri, 29 Oct 2004 02:12:20 -0700 (PDT) Received: from cucujus.ucdavis.edu (localhost [127.0.0.1]) by cucujus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i9T9CJqJ003167; Fri, 29 Oct 2004 02:12:19 -0700 (PDT) Received: (from www@localhost) by cucujus.ucdavis.edu (8.12.10/8.12.9/Submit) id i9T9CJJ6003166; Fri, 29 Oct 2004 02:12:19 -0700 (PDT) Date: Fri, 29 Oct 2004 02:12:19 -0700 (PDT) Message-Id: <200410290912.i9T9CJJ6003166@cucujus.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [nemo] questions on draft-kniveton-nemo-prefix-delegation-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear T.J. and Pascal, Sorry for the late response to this PD draft as I was ill last week. In the scenarios where MR is desired to be assigned the MNP dynamically, if I am not wrong, there may exist the inconsistency problem between MR's MNP and MNN's Home Address. Note that the problem does not depend on the specification of prefix delegation mechanism. In MIP6, MN knows when is the proper time to change its home address as it knows the state of communication between itself and CN. However in NEMO, MR's MNP can not be changed when one of its MNNs still communicates with CN because in NEMO Basic Support protocol, HA has no route once an old MNP is withdrawn. Thus a mechanism to detect the state of MNN might be needed in order not to break the continuity of session. Please correct me if I am wrong. Thanks. Sincerely, fan From nemo-bounces@ietf.org Fri Oct 29 06:38:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15655 for ; Fri, 29 Oct 2004 06:38:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTjO-0007Wq-Mb; Fri, 29 Oct 2004 06:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTT6-0006Dm-D0 for nemo@megatron.ietf.org; Fri, 29 Oct 2004 05:54:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13251 for ; Fri, 29 Oct 2004 05:54:46 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNThM-0002O9-1I for nemo@ietf.org; Fri, 29 Oct 2004 06:09:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2004 12:12:16 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T9sDrE005914; Fri, 29 Oct 2004 11:54:13 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 11:54:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO taxonomy Date: Fri, 29 Oct 2004 11:54:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC389C03@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS9RMLFrHACJicVSUuub4ebfvuxaQAUiRNA From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 29 Oct 2004 09:54:12.0555 (UTC) FILETIME=[3E46A9B0:01C4BD9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , marcelo bagnulo braun , Chan-Wah NG , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > > > > case one) VMN does not attempt RO yet. So the only CN is HA(VMN). = So > > we end up with MR doing RR test with HA(VMN). Say HA(VMN) accepts > > trying. The security you had by signing the careof in MIP6 is now > > back to that of the RR test. We have to see what threats this opens. >=20 > In this case the HA ends up with two bindings - the home binding from > HoA(MN) to P1::IID and the binding created by the MR from P1:IID to = CoA(MR). >=20 > What does RFC 3775 say about that? I believe that you are clear, in your response to Brian, that the = problem is introduced by NEMO; and that the situation where the 2 = bindings are related should not occur in MIPv6.=20 So now, I'm confused... why should RFC 3775 say anything here?=20 =20 >=20 > > Case three: MR is attached to MR' in a nested configuration. Think > > about the egress direction. Would we end up with a list of Home > > Addresses? There's no definition in the order in which they are > > stacked, for instance, and what the CN would do with that. >=20 > You need to specify where the addresses come from in this case. > Is there prefix delegation so that each MR gets a piece of address = space > from the AR, or not? >=20 > If you have delegated prefixes (which are marked as special so that = LFNs > don't use them) then each nemo-aware VMN can use a CoA from the AR > delegated prefix and just MIPv6 BUs. >=20 > That is simple, but assumes delegated address space. > OK. Seems you're changing the rules. All this talking is about the = algorithm that you detailed in this thread, and that is basically MIRON = as I understand it. If we go to the delegation space, it's another = chapter in the taxonomy, it's a very different discussion, and all my = arguments here do not apply. Actually, as you know, I like the = delegation space very much, and share a draft with Ralph on doing some = LMM/RO that way. Now, as I understand your algorithm, each MR would bind the careof of = its visitor (as a home address) with its own careof. If the visitor is a = MR doing the same thing, we end up creating a chain of bindings at the = CN, again, exactly as you detailed in the next mail.=20 The specific problem I was discussing here is that each MR would = actually add a HoA option to the packets on the way to the CN. And I do = not see an existing CN implementation understanding the semantics of = this chain of home address options in a same packet. The RRH and RO taxonomy drafts both have some text that list generic = problems with that approach (I copied the RRH text inline in a separate = mail).=20 I think that discussing over your algorithm is an excellent education = for us all on that very new problem, and that our conclusion should = reside in the taxonomy draft. One thing I had in mind, starting the RO = taxonomy draft, was to save some of this WG time by sharing our findings = on various families of approaches, including the MIRON one, in a single = document.=20 I hope that soon we can let that specific exercise behind and move = forward. Pascal From nemo-bounces@ietf.org Fri Oct 29 06:38:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15696 for ; Fri, 29 Oct 2004 06:38:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTjP-0007X9-6T; Fri, 29 Oct 2004 06:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTT7-0006Fi-48 for nemo@megatron.ietf.org; Fri, 29 Oct 2004 05:54:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13254 for ; Fri, 29 Oct 2004 05:54:46 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNThN-0002O9-1f for nemo@ietf.org; Fri, 29 Oct 2004 06:09:33 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2004 12:12:20 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T9rdrk005802; Fri, 29 Oct 2004 11:54:16 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 11:54:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO Agenda CFP Date: Fri, 29 Oct 2004 11:54:07 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC389C04@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NEMO Agenda CFP Thread-Index: AcS8se5VE0DiZ16XS16lJ3PVxK3FEwA6hECg From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 29 Oct 2004 09:54:12.0883 (UTC) FILETIME=[3E78B630:01C4BD9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: Vijay Devarapalli , tj , ryuji@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Thierry: HAHA has already been presented to the WG. It has been split and several drafts will result from that split. I think it could be useful that we present the split and the new drafts that were published since.=20 To be honest, though, the ML has not reacted too much (yet?). So I guess it's not a priority, but depending on the available time, I can present the global HAHA fro instance. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst > Sent: jeudi 28 octobre 2004 07:49 > To: nemo > Cc: tj > Subject: [nemo] NEMO Agenda CFP >=20 >=20 > Dear all, >=20 > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > 13.00-15.00. >=20 > At least the following items will be included in the agenda: > - WG status > - draft-ietf-nemo-basic-support > - draft-ietf-nemo-mib > - draft-ietf-nemo-home-network-models > - draft-ietf-nemo-multihoming-issues > - TAHI announcement > - possible re-chartering > - prefix delegation >=20 >=20 > If you would like a timeslot for a topic not listed above, please send > a request to both chairs by the end of this week showing: > - topic > - draft name and title if appropriate > - time length > - what issue do you intend to discuss > - how does it fall into the above listed priorities of the WG or one of > the NEMO charter item >=20 > Requests will be honored based on available time, priorities of the NEMO > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > case several people want to discuss similar issues, we would rather > advocate a discussion on the ML and one single person summarizing the > issues during the meeting. >=20 > Only drafts previously announced on the NEMO ML will be considered for > slots. >=20 >=20 > The NEMO WG Chairs. >=20 From nemo-bounces@ietf.org Fri Oct 29 12:48:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14640 for ; Fri, 29 Oct 2004 12:48:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZhW-0003SF-45; Fri, 29 Oct 2004 12:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZXO-0005WD-9P for nemo@megatron.ietf.org; Fri, 29 Oct 2004 12:23:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12677 for ; Fri, 29 Oct 2004 12:23:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZld-0002a9-Cv for nemo@ietf.org; Fri, 29 Oct 2004 12:38:25 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9TFtje13363; Fri, 29 Oct 2004 08:55:45 -0700 X-mProtect: <200410291555> Nokia Silicon Valley Messaging Protection Received: from danira-pool04952.americas.nokia.com (10.241.49.52, claiming to be "[10.241.49.52]") by darkstar.iprg.nokia.com smtpdDt2aSj; Fri, 29 Oct 2004 08:55:42 PDT Message-ID: <41826E58.708@iprg.nokia.com> Date: Fri, 29 Oct 2004 09:22:48 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org, Erik Nordmark Subject: Re: [nemo] issue 44 References: <417EE9A8.1080209@iprg.nokia.com> In-Reply-To: <417EE9A8.1080209@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I havent heard from anyone. so I assume we are not doing this change now. Erik? Vijay Vijay Devarapalli wrote: > hi all, > > I am trying to resolve issue 44. > http://people.nokia.net/vijayd/nemo/issue44.txt > > this error is most probably due to a mis-configuration > on the MR. we have 2 options > > 1. do nothing. if the MR sends a BU with multiple prefix > options and receives a Binding Ack with status 142, it > can try sending a BU again with one prefix at a time. > > 2. make the change that Erik suggested. the HA includes > the offending prefix(es) in the Binding Ack. the MR can > send a BU again with the offending prefix(es) removed. > > option 2 is definitely the better one, but I think it is > too big a change to do this late. I would prefer to leave > it as it is and do the update later when the basic support > spec is updated. > > comments are welcome. > > Vijay > > > > From nemo-bounces@ietf.org Fri Oct 29 13:04:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15944 for ; Fri, 29 Oct 2004 13:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZzh-0006Ed-VB; Fri, 29 Oct 2004 12:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZlm-0005QN-Db; Fri, 29 Oct 2004 12:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13804; Fri, 29 Oct 2004 12:38:27 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNa04-0002vD-IC; Fri, 29 Oct 2004 12:53:18 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9TGbP7q009942; Fri, 29 Oct 2004 09:37:25 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TGbMJQ029489; Fri, 29 Oct 2004 18:37:22 +0200 (MEST) Message-ID: <418271ED.5060102@sun.com> Date: Fri, 29 Oct 2004 09:38:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) References: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Ville Nuorvala X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Well, there is a difference: we can (and must) put a restriction in the > usage of the extended RH2. And that restriction is to go down the nested > tree only. In particular if the source routed path in the RH2 is strict > (not loose), we can force that the next entry in the RH is actually part > of an MNP of the MR that processes the RH2. This is explicitly what the > RRH draft says. How would the strict restriction work when the mobile network (imagine a large cruise ship) has one or more layers of regular routers, and then the passangers arrive with their PANs that have their MRs? A strict routing check assumes that all the routers are listed. Erik From nemo-bounces@ietf.org Fri Oct 29 13:28:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17570 for ; Fri, 29 Oct 2004 13:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaIL-0000BE-Il; Fri, 29 Oct 2004 13:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaDe-0004oQ-Sb for nemo@megatron.ietf.org; Fri, 29 Oct 2004 13:07:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16146 for ; Fri, 29 Oct 2004 13:07:15 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaRy-0003bv-DK for nemo@ietf.org; Fri, 29 Oct 2004 13:22:06 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9TH7E7q023827; Fri, 29 Oct 2004 10:07:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TH7BJQ001639; Fri, 29 Oct 2004 19:07:12 +0200 (MEST) Message-ID: <418278ED.4040905@sun.com> Date: Fri, 29 Oct 2004 10:07:57 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC389BB1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC389BB1@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , marcelo bagnulo braun , Chan-Wah NG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 5. Obsolete BU > > If the Binding messages are sent asynchronously by each MR, then, > when the relative position of MRs and/or the TLMR point of > attachment change rapidly, the image of Mobile Network that the > CN maintains is highly unstable. If only one BU in the chain is > obsolete due to the movement of an intermediate MR, the > connectivity may be lost. It also isn't clear to me how such an approach would work when multiple MRs move at the same time. With a tree of AR->MR1->MR2->MNN, if MR1 changes AR at the same time as MR2 changes from MR1, wouldn't the fact that each "layer" tries to independently signal the CN make things very flaky; some part of one layers 6 packet BU exchange with the CN might be lost due to the layers above also moving. > A conclusion is that the path information must be somehow aggregated > to provide the CN with consistent snapshots of the full path across > the Mobile Network. This can be achieved by an IPv6 form of loose > source / record route header, that we introduce here as a Reverse > Routing Header Another possible way, in the case when the CN is modified, would be to have the MNN learn the list of CoA from announcements (e.g. in RAs) from the chain of MRs above it. That way the MNN can reliably learn the list, and then the MNN can pass the list to the CN in a BU. But I think the case when the CN isn't modified is about as easy; the MNN would instead of sending a BU to the CN with the list, it will send a BU to the CN which points at the top MR's COLA, and a BU to that MR which points it at the CoA of the next MR in the tree, etc. Thus the MNN learns the path of MRs the packets need to traverse and creates bindings in each MR indicating the next hop. (MNN->CN path and HAO left as an exercise for the reader :-) Erik From nemo-bounces@ietf.org Fri Oct 29 13:31:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17727 for ; Fri, 29 Oct 2004 13:31:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaVu-0007Xu-Fl; Fri, 29 Oct 2004 13:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaEj-0005lB-1a for nemo@megatron.ietf.org; Fri, 29 Oct 2004 13:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16231 for ; Fri, 29 Oct 2004 13:08:21 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaT1-0003cq-HU for nemo@ietf.org; Fri, 29 Oct 2004 13:23:13 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9TH8Is3019784; Fri, 29 Oct 2004 10:08:20 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TH8FJQ001662; Fri, 29 Oct 2004 19:08:15 +0200 (MEST) Message-ID: <4182792D.6060203@sun.com> Date: Fri, 29 Oct 2004 10:09:01 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC389C03@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC389C03@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , marcelo bagnulo braun , Chan-Wah NG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I believe that you are clear, in your response to Brian, that the > problem is introduced by NEMO; and that the situation where the 2 > bindings are related should not occur in MIPv6. > > So now, I'm confused... why should RFC 3775 say anything here? Because a broken or malicious node might cause the same thing. So at least the CN/HA shouldn't crash or die because of the multiple related bindings. >>> Case three: MR is attached to MR' in a nested configuration. >>> Think about the egress direction. Would we end up with a list of >>> Home Addresses? There's no definition in the order in which they >>> are stacked, for instance, and what the CN would do with that. >> >> You need to specify where the addresses come from in this case. Is >> there prefix delegation so that each MR gets a piece of address >> space from the AR, or not? >> >> If you have delegated prefixes (which are marked as special so that >> LFNs don't use them) then each nemo-aware VMN can use a CoA from >> the AR delegated prefix and just MIPv6 BUs. >> >> That is simple, but assumes delegated address space. >> > > > OK. Seems you're changing the rules. No, I was merely confused by your unstated assumption that there was no address delegation in your case above. All this talking is about the > algorithm that you detailed in this thread, and that is basically > MIRON as I understand it. If we go to the delegation space, it's > another chapter in the taxonomy, it's a very different discussion, > and all my arguments here do not apply. Actually, as you know, I like > the delegation space very much, and share a draft with Ralph on doing > some LMM/RO that way. > > Now, as I understand your algorithm, each MR would bind the careof of > its visitor (as a home address) with its own careof. If the visitor > is a MR doing the same thing, we end up creating a chain of bindings > at the CN, again, exactly as you detailed in the next mail. Nope. Each Nemo aware MNN would have lots of addresses to choose from, one from each layer of MRs. In particular, it would have a address delegated in a nested way from the AR. It can use this address as the CoA and do a regular MIPv6 BU to a CN. This assumes that in the nested case the AR hands out sufficient address space to pass down a piece to all the links in the nested network. But the MRs don't have to do anything special except delegating the address space (and announcing it to their downstreams in a way that doesn't confuse any LFNs). > The specific problem I was discussing here is that each MR would > actually add a HoA option to the packets on the way to the CN. And I > do not see an existing CN implementation understanding the semantics > of this chain of home address options in a same packet. Agreed. It makes sense to focus on the cases when the CN isn't modified and look at what the MRs and MNNs need to do in that case. Erik > The RRH and RO taxonomy drafts both have some text that list generic > problems with that approach (I copied the RRH text inline in a > separate mail). > > I think that discussing over your algorithm is an excellent education > for us all on that very new problem, and that our conclusion should > reside in the taxonomy draft. One thing I had in mind, starting the > RO taxonomy draft, was to save some of this WG time by sharing our > findings on various families of approaches, including the MIRON one, > in a single document. > > I hope that soon we can let that specific exercise behind and move > forward. > > Pascal > From nemo-bounces@ietf.org Fri Oct 29 13:32:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17884 for ; Fri, 29 Oct 2004 13:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaWB-0007cd-BJ; Fri, 29 Oct 2004 13:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaGQ-0007BW-TL for nemo@megatron.ietf.org; Fri, 29 Oct 2004 13:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16350 for ; Fri, 29 Oct 2004 13:10:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaUj-0003fd-Fd for nemo@ietf.org; Fri, 29 Oct 2004 13:24:58 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9THA67q025075; Fri, 29 Oct 2004 10:10:07 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9THA4JQ001742; Fri, 29 Oct 2004 19:10:05 +0200 (MEST) Message-ID: <4182799A.7070507@sun.com> Date: Fri, 29 Oct 2004 10:10:50 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] issue 44 References: <417EE9A8.1080209@iprg.nokia.com> <41826E58.708@iprg.nokia.com> In-Reply-To: <41826E58.708@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I havent heard from anyone. so I assume we are not doing this > change now. > > Erik? My main issue was that the draft wasn't clear what happens when some prefixes are ok and others not. So if folks don't see a benefit (for debugging or operations) with telling the MR which prefixes failed, I don't have a problem with doing nothing on that front. Erik From nemo-bounces@ietf.org Fri Oct 29 17:45:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16964 for ; Fri, 29 Oct 2004 17:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe4I-0002PJ-Uu; Fri, 29 Oct 2004 17:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdT8-0006UJ-Gf for nemo@megatron.ietf.org; Fri, 29 Oct 2004 16:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07184 for ; Fri, 29 Oct 2004 16:35:28 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdhT-0000iN-BA for nemo@ietf.org; Fri, 29 Oct 2004 16:50:20 -0400 Received: from [203.178.139.172] (wifi-139-172.sfc.wide.ad.jp [203.178.139.172]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i9TKYdnG010495; Sat, 30 Oct 2004 05:34:40 +0900 In-Reply-To: <4182799A.7070507@sun.com> References: <417EE9A8.1080209@iprg.nokia.com> <41826E58.708@iprg.nokia.com> <4182799A.7070507@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] issue 44 Date: Sat, 30 Oct 2004 05:34:39 +0900 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I prefer option 1 (do nothing). I agree that option 2 is useful for debugging and operation. But, we need more consideration before going with option 2. For example, MR sends BU with 2001:a::/48, but only 2001:a:b::/64 is valid. How can HA include offending prefixes in BA? regards, ryuji On 2004/10/30, at 2:10, Erik Nordmark wrote: > Vijay Devarapalli wrote: >> I havent heard from anyone. so I assume we are not doing this >> change now. >> Erik? > > My main issue was that the draft wasn't clear what happens when some > prefixes are ok and others not. > > So if folks don't see a benefit (for debugging or operations) with > telling the MR which prefixes failed, I don't have a problem with > doing nothing on that front. > > Erik From nemo-bounces@ietf.org Fri Oct 29 19:20:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25275 for ; Fri, 29 Oct 2004 19:20:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNfrK-0001Zz-PX; Fri, 29 Oct 2004 19:08:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNfj0-0004CF-2z for nemo@megatron.ietf.org; Fri, 29 Oct 2004 19:00:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23546 for ; Fri, 29 Oct 2004 18:59:59 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfxM-0004we-1p for nemo@ietf.org; Fri, 29 Oct 2004 19:14:53 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TMxtNH025915; Fri, 29 Oct 2004 16:59:55 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TMxqJQ026541; Sat, 30 Oct 2004 00:59:53 +0200 (MEST) Message-ID: <4182CB96.902@sun.com> Date: Fri, 29 Oct 2004 16:00:38 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] issue 44 References: <417EE9A8.1080209@iprg.nokia.com> <41826E58.708@iprg.nokia.com> <4182799A.7070507@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > I prefer option 1 (do nothing). > > I agree that option 2 is useful for debugging and operation. > But, we need more consideration before going with option 2. > > For example, MR sends BU with 2001:a::/48, > but only 2001:a:b::/64 is valid. > How can HA include offending prefixes in BA? It would tell you that 2001:a::/48 was invalid. Thus it would only be useful when there are multiple prefixes in the BU. Erik From nemo-bounces@ietf.org Sat Oct 30 22:56:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07910 for ; Sat, 30 Oct 2004 22:56:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO5iu-0007nT-2A; Sat, 30 Oct 2004 22:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO5eE-0007B0-Pr for nemo@megatron.ietf.org; Sat, 30 Oct 2004 22:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07267 for ; Sat, 30 Oct 2004 22:40:48 -0400 (EDT) Received: from bb219-74-18-57.singnet.com.sg ([219.74.18.57] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO5sp-00075L-Sb for nemo@ietf.org; Sat, 30 Oct 2004 22:55:56 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 79DF52D76F4; Sun, 31 Oct 2004 10:40:24 +0800 (SGT) Subject: Re: [nemo] NEMO Agenda CFP From: Chan-Wah NG To: Thierry Ernst In-Reply-To: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> References: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1099190424.10501.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 31 Oct 2004 10:40:24 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, Thierry, TJ, I would like to present the new version of RO-Taxonomy and RRNP drafts, if time allows. draft-thubert-nemo-ro-taxonomy-03.txt: I understand that we have presenetd this draft previously, however, as this version is a major update, I'll like to do a brief description of it. draft-ng-nemo-rrnp-00.txt: This is not a RO solution, but a mechanism for potential RO solution to make use of. It also raises some security concerns on the use of network prefixes in RO. I wouldn't need anything more than 5 mins for each of them. /rgds /cwng On Thu, 2004-10-28 at 13:49, Thierry Ernst wrote: > Dear all, > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > 13.00-15.00. > > At least the following items will be included in the agenda: > - WG status > - draft-ietf-nemo-basic-support > - draft-ietf-nemo-mib > - draft-ietf-nemo-home-network-models > - draft-ietf-nemo-multihoming-issues > - TAHI announcement > - possible re-chartering > - prefix delegation > > > If you would like a timeslot for a topic not listed above, please send > a request to both chairs by the end of this week showing: > - topic > - draft name and title if appropriate > - time length > - what issue do you intend to discuss > - how does it fall into the above listed priorities of the WG or one of > the NEMO charter item > > Requests will be honored based on available time, priorities of the NEMO > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > case several people want to discuss similar issues, we would rather > advocate a discussion on the ML and one single person summarizing the > issues during the meeting. > > Only drafts previously announced on the NEMO ML will be considered for > slots. > > > The NEMO WG Chairs. > > >