From ronyoung@nortelnetworks.com Thu Mar 1 00:44:57 2001 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12240 for ; Thu, 1 Mar 2001 00:44:56 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f215hVl19419 for ; Thu, 1 Mar 2001 00:43:31 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Wed, 28 Feb 2001 23:34:58 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Wed, 28 Feb 2001 23:37:45 -0600 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id AAA28287 for ; Thu, 1 Mar 2001 00:32:15 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s001.baynetworks.com; Wed, 28 Feb 2001 21:25:40 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Wed, 28 Feb 2001 21:31:35 -0800 Received: from web1006.mail.yahoo.com (web1006.mail.yahoo.com [128.11.23.96]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id XAA04542 for ; Wed, 28 Feb 2001 23:30:40 -0600 (CST) Received: (qmail 18782 invoked by uid 60001); 28 Feb 2001 13:30:33 -0000 Message-ID: <20010228133033.18781.qmail@web1006.mail.yahoo.com> Received: from [208.61.161.156] by web1006.mail.yahoo.com; Wed, 28 Feb 2001 05:30:33 PST Date: Wed, 28 Feb 2001 05:30:33 -0800 (PST) From: Vasos Vassiliou Subject: REMOVE To: cathy@fgrpublications.com, mobile-ip@smallworks.com In-Reply-To: <647.687866.290736@fgrpublications.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: vasosv@yahoo.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: --- jspilot899827 wrote:

FGR Publications - The Desktop Observer

We need Book, Software, Product, Restaurant, Resort & Movie Reviewers - see below

Increase your GPA in one semester or receive a 100% refund!

The CramCompanion Accelerated Learning systems will allow you to learn a greater amount of study material in a shorter period of time. It is great for the active student who never seems to have enough time to effectively study for tests. Parent's of middle and high school students love the CramCompanion software because they can check daily on how much material their child has entered into the CramCompanion for the chapters they are covering in class. By taking 10-20 minutes to enter the subject material covered in class it literally forces the student to learn.

CLOSEOUT PRICE ON NAME BRAND COMPUTERS

$289 Refurbished Dell, Compaq & Gateway systems are now available in limited amounts. 14 Dell systems, 8 Compaq and 23 Gateway. These were purchased in one complete lot from a busted dot com startup who ran out of money. Each system was cleaned up and inspected and all work as new. These will go fast. Call 770-449-8000 extension 158 and ask for Jim.

BOOK,SOFTWARE & PRODUCT REVIEWERS NEEDED

You can request any book, software program or consumer product and keep them after you post a brief review. Visit our web site below to learn how to sign up as a reviewer for Focus Group Reviews.

WE NEED Ebook authors - We pay 50% royalties.

We need authors to write e-books to be published to include our CramCompanion software. These non-fiction e-books can range from Building a Koi Pond to Plant Physiology

Your e-book and our CramCompanion accelerated Learning software will provide the reader with an accelerated learning system which will allow them to truly learn the subject matter of your e-book in shorter period of time. Each e-book will be bundled with our CramCompanion accelerated learning software and a 45 page accelerated learning techniques manual as well as the associated accelerated learning mp3 files.

Visit the web site below and scroll down to the "We need ebook authors" section.

Here is the web site.

*******************************************************************************

Today's Sponsor - Cut your water heating bills in half! Click here for more info


*******************************************************************************
FGR Publications has been operating on the Internet since 1997.
We never have and never will engaged in the practice of SPAM or unsolicited
email. From time to time we will acquire opt-in list only under the rules that we
are the only buyers of such a list. We will then send an introductory
message such as this one you received from us. This is vital for you and us
as it allows you to get off this list and it will allow us to retain only the
true opt-in subscribers. You can feel safe that it is in good hands. Again,
we strongly apologize for any inconvenience this message has caused you, but on
the other hand you can now feel assured that your removal request will be granted.

Removal: For those that do not wish to be on database simply reply to this email message with the single word REMOVE in the message subject line or send an email message to cathy@fgrpublications.com with the single word REMOVE in the subject line. You email address will be promptly removed.
*******************************************************************************

__________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 07:06:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29972 for ; Thu, 1 Mar 2001 07:06:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19143; Thu, 1 Mar 2001 04:05:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08709; Thu, 1 Mar 2001 03:31:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21BTOR14581 for mobile-ip-dist; Thu, 1 Mar 2001 03:29:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21BTEV14574; Thu, 1 Mar 2001 03:29:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06609; Thu, 1 Mar 2001 03:29:14 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03706; Thu, 1 Mar 2001 03:29:13 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 06:29:11 -0500 Message-ID: From: George Tsirtsis To: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Cc: "'mipv6-handoff@sunroof.eng.sun.com'" , "'mobile-ip@marvin.corpeast.baynetworks.com'" Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt Date: Thu, 1 Mar 2001 06:29:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I got your e-mail only once...which means that the mailing list did not work...anyway..we keep going. -----Original Message----- From: James Kempf [mailto:james.kempf@sun.com] Sent: Wednesday, February 28, 2001 11:58 PM To: George Tsirtsis; mobile-ip@sunroof.eng.sun.com Cc: 'mipv6-handoff@sunroof.eng.sun.com' Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt ... > >GT> Well, that is the trick... The MN will send the BU assuming the nCOA is >OK...but it MUST NOT use the nCOA until it receives a BACK! The BACK will >only be sent by the oldAR if the HACK has been received from the newAR >saying that the nCOA is actually valid... So let me get this straight. Suppose the HI/HACK exchange happens and the newCoA is fine with newAR, and tells MN to use the newCoA, but for some reason the L2 move is delayed and the BU/BACK occurs over the old L2 connection. Since newAR is fine with the newCoA, oldAR reports a successful BACK. Now suppose, for some reason, that the L2 move is aborted. This could happen in cellular, for example, if the mobile suddenly moved back toward the middle of the cell and its power readings started increasing. Now the mobile is left on the old L2 with a topologically incorrect address to which oldAR is tunnelling. GT> The MN will only have to send a Neighbor Advertisement (which can also be signed) to the oldAR to retrieve its connection, some packets may be lost but even that should be rare...I think we can make this work but we have not talked about it in detail in the draft because we have some open issues...We plan to discuss this and in general ping pong during the IETF because the subject is complex and we have not managed to agree between us yet...I suggest we leave this point for now so we can be more productive... I assure you, we are going to come back to it during and after the IETF. >GT> If the MN connects to the newAR faster than the HACK returns to the >oldAR and assuming the MN has already send the BU, the MN will timeout and >resend the BU but it will not use the nCOA...see the Description paragraph >in section 4.7. I guess we have made the assumption that the HI/HACK >sequence is not going to be the limiting factor otherwise we do not make the >handoff faster but slower => not good :-) > I think this assumption is probably valid, since the HI/HACK is going through the wired network. It should, however, be stated. GT> OK. ... According to the description of PrRtAdv on pg. 14: In sateful (sp. stateful) configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for (presumably newAR?). In stateless address auto- configuration, this option may or may not be sent. If sent, indicates the requesting node SHOULD use this address as newCoA for the duration of the handover. If not sent, the requesting node SHOULD compute the newCoA using the Interface ID from the Destination Address of this message. Now, according to this, use of this address is completely optional. If the MN chooses not to use it or oldAR chooses not to send it, the MN MUST do new CoA generation at the newAR, otherwise it can't send a BU. So, in effect, the MN could be left in the position where it generates a CoA which newAR already knows is invalid, then sends that CoA to oldAR, and has it vetoed in the BACK. Then it has to go through another round of CoA address generation. I don't think this will reduce any signalling. GT> Whether this option is sent or not, the newCOA is calculated the same way by both the oldAR and the MN (at least in the stateless case). The reason we made this optional is that sending this option avoids guesswork at the oldAR...i.e.: the oldAR knows for a fact the address that the MN will use as a newCOA. On the other hand this costs a 24bytes long option...which we did not want to make mandatory since we try to minimize bits over the air where possible. Note that the chances of the oldAR calculating a different address from the MN given the same Interface ID and Prefix is really very very small. We only added this option to cover for the privacy draft where the MN might want to change Interface ID very often... There is a further problem with the description of this message on pg. 13/14 (which I just now saw, trying to make sense of the last sentence). What is meant by "the Interface Id of the Destination address?" First off, if the MN is to form a CoA, doesn't it use its own interface ID and the network ID of the subnet advertised by the router? GT> I guess that you are referring to: "the Interface Id of the Destination address" of the *PrRtAdv* message that is going to the MN. The oldAR can use the Interface ID of this address (which we know it belongs to the MN) to construct the newCOA...what is the problem? Secondly, the description of the Destination Address on pg. 13 states: The Source Address of an invoking Router Solicitation for Proxy or the addrss of the node the Access Router is instructing to handover. What does this mean? It sounds to me, and from the protocol diagrams on pg. 8) that the PrRtAdv is coming from oldAR. Is that its address? If so, then how can the MN form a CoA on the new link when it doesn't have the subnet? If not, then I think the description should reflect that. GT> I think I might be missing your point...The PrRtAdv is sent from the oldAR to the MN. The Destination Sddress of this message is the address of the MN (which can be derived by the Source Address of the RtSolPr message that was sent from the MN to the oldAR earlier). This same address includes an Interface ID that can be used to calculate the newCOA...Did I miss your point? >In the network assisted, "stateless" config case, how does the MN get >notified of >nCoA when it gets to newAR? For example, newAR might determine that the >address is invalid, but only oldAR gets told. MN needs to go through >some >procedure, presumably standard MIPv6 CoA configuration, only to be told >at >some point that it can't use the address, while newAR knows this all >along. >Is this so, or am I missing something? > >GT> Here is what is going on: The first think the MN does when it connects >to the newAR is to send Neighbor Advertisement (NA). Assuming the BU has >already been send, 3 things can happen. >- nCOA is valid => A buffed BACK is delivered to the MN which can now use >the nCOA >- nCOA is invalid => A buffered BNACK is delivered to the MN which must now >get a newCOA all over again (revert back to normal MIPv6) >- delays/errors (Any of BU, HI , HACK and BACK was lost/delayed) => No BACK >is delivered to the MN, the MN must resend the BU to the oldAR... OK, but I still don't understand why the MN has to go through all this signalling when newAR may have already sent the HACK and possibly has already been defending the newCoA. Why can't MN simply ask newAR, and if it gets no response, then go through the standard MIP newCoA generation? GT> What is "all that signaling"? The MN will have to send a BU and the oldAR will have to send a BACK for routing change purposes...no way around that, agree? So what is the added signaling? In any case, another reason (which Mohamed reminded me off) is security...the MN does not have a security association with the newAR yet...all other messages in this mechanism are secured... ... > >GT> Jak, what you are saying is OK only if the network can determine the >fact that the MN must be handed-off well in advance...and thus have time to >do HI/HACK before you send the PrRtAdv and this is certainly allowed (and >you can use it for stateless config as you suggest...). We felt, however, >that you might not have all this time...In this case you do stateless as we >suggest and you send the PrRtAdv virtually at the same time you send the HI >message...that is definitely faster... Well, according to previous comment, the group seemed to feel that the HI/HACK was fast. Also, if the PrRtAdv is sent at the same time, it can't have a newCoA in it, because the oldAR hasn't yet received an acknowledgement that the generated newCoA is OK, correct? Given that, the MN ends up having to generate a newCoA on the other end anyway, going through all the signalling involved in MIP CoA generation. GT> Jak, you are missing a fine little point since the start of this discussion. The oldAR CAN SEND the newCOA even if it HAS NOT received the HACK! The trick is that we allow the oldAR to guess! In the unlikely case that the oldAR gets it wrong or the newAR for whatever reason replies with a HNACK, the oldAR will reply with a BNACK to the MN's BU...and the MN will have to do normal MIPv6. But this is very unlikely to happen anyway and we think it will speed things up in 99.9...% of the cases. I think we have to make sure that you and the WG understand this idea....which I see that it is counterintuitive and may need better explenation in the draft...I will make sure we cover this in the presentation. ... >to get routing right...and thus everything is based at the oldAR (which >controls routing for the MN)...so we also delegate, the confirmation to the >MN that its nCOA is OK, to the oldAR and we deliver this information in the >BACK which also confirms that the routing change has taken place...A design >decision, someone else might have based everything on the newAR...but that >would be a different design. Right, and I think it would result in less signalling in some cases. That's what I'm trying to say. Also, this is a design assumption that is left unstated in the draft. It should be clearly articulated. GT> OK, I see that we can make this more clear...The discussion with you has brought up a number of points that should be clarified...we will try to do this in the next version. ... > >GT> The requirement is that the MN gets the PrRtAdv before the link to the >oldAR is severed...how you do this is implementation specific...not sure >what you want us to say about it...If for some reason it does not happen >(PrRtAdv) gets lost then, in the normal graceful IP manner the MN will have >to do normal MIPv6.... Then this should be stated in the draft, and it is obvious, to me anyway, that it requires L2 information because the MN can't possibly know it otherwise. GT> OK, will do, thanks. >In the case of the BU, I would assume that it *does* matter, that the >mobile node will not send the BU until it knows it has a solid new L2. >Otherwise, it might be telling oldAR >to route to the nCoA before it even has L2 established. So how does it >find >this out? > >GT> I think you may have now understood from the discussion so far what is >happening. The BU is sent with the *assumption* that the nCOA is >valid...this is not confirmed, however, and routing does not change until >and HACK is returned by the oldAR and BACK returned to the MN... As mentioned, I think it is possible to do much better if the MN simply asks newAR. It would simplify the design. Why was the design decision made to base confirmation of newCoA validity on oldAR? Perhaps the group had a good reason for this, if so,I think it ought to be listed in a "Design Goals" section. GT> I brought up two reasons up to now. 1. Routing change has to be based at oldAR so we thought we base the whole design on a single point rather than distribute different aspects of it in different points. 2. Security Association only exists between MN and oldAR + oldAR and newAR which already puts the oldAR in a strategically good position to handle the whole handoff. I think we can make these explicit in the draft. I would also be interested to see, if you have the time to work on this and still think is feasible, a bit more detail on how the newCOA confirmation can be done at the newAR...then we could judge better wether this is a good idea or not. ... > >So MN gets a trigger prior to sending RtSolPr in the mobile assisted >case, >and oldAR prior to HI in the network assisted case? > > >GT> In the Mobile Assisted or Mobile Determined the Mobile decides that is >must handoff, how is this done is outside the scope of this doc...It might >get a trigger or it might have the intelligence to figure that out by >itself...either way the same think happens... I think this is one of the key, meta-level objections I have to this draft. I do not think you can simply assume that L3 gets an L2 trigger up front that a handoff is about to happen , then continue signalling on L3 regardless of the state of L2. The problem is that handoff is a mixture of L2 actions and L3 actions, by its very nature. That said, I think it should be possible to work with some general abstractions about L2 actions rather than specific L2s, since most L2 designs will give you some information. Clearly articulating what information is required where and what to do if a particular L2 does not supply it is critical for having an interoperable design. If a designer would rather not use such L2 triggers at all, vanilla MIPv6 handoff will do just fine. They can even use an L2 trigger after handoff on the mobile via the driver and avoid having to wait for a multicast router advert. GT> OK, I think this can be further discussed and clarified. The problem is that we did spend a very long time discussing L2 triggers and L2 assumptions and although we think we more or less understand them, we found impossible (given the timeframe) to find *useful* general abstractions...and at the end we found that we did not have too...but let us think about this a bit more and see if now that we have completed this phase of work can go back and reconsider this. >I think this should be clearly stated somewhere in the draft, preferably >near >the front under "Assumptions". > >GT> Not really, there is no reason to state this...The implementer will have >to decide how things get triggered based on the link layer he/she is working >with...you think there will be a trigger coming from the network to trigger >the mobile determined case, I think the mobile will figure this out on its >own....and we are probably both correct for different link layers... No reason to state assumptions???? Stating assumptions is one of the hallmarks of a good specification. If you don't state assumptions, how is an implementer to know whether their situation has the right support for the specification? GT> Let me duck and take this back :-) Of course we have to state assumptions and I think you have correctly identified a number of things that might need to be explicitly stated. We may, however, disagree on how much we need to assume about Link Layers... >Why should this have to come from the oldAR? The newAR knows whether the >nCoA is valid, why can't the mobile simply ask it? > >GT> Now you are designing a new protocol and I am tempted to ask you to >write a draft :-) Seriously, we thought that the most important thing is I'm sorry for being so touchy, George, but I think there are some problems with this draft in terms of explanation, design complexity and some assumptions that I think were made that are not explained much less justified. If you are not willing to consider modifying the protocol based on working group input, let me know right now and I won't bother even working on it any further. GT> Modifications are always welcome but lets not rush and make changes before we all understand how this works. I can easily see why the draft might not be 100% clear since the design team has been working intensively on this for almost 4 months and some things that we came to realize and consider given, might not be in the draft in a way easy to digest...I am sure we will work on that..this is v00! I am just asking you to take the time (and I appreciate the effort you put on this already) and let the current design sink in before we rip it apart. I don't want this conversation to descend into the kind of knife fight that's been happening on Seamoby but, on the other hand, if want you are looking for is to have the working group simply rubber stamp your work, I'll simply say "sayonara" and you can get the rest of the working group to do it. GT> No, no...this is one of the, unfortunately rare these days, set of comments that are constructive and non religious! Lets keep going...let us help you understand what we have done and then we change what needs to be changed. George From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 07:27:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01331 for ; Thu, 1 Mar 2001 07:27:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17465; Thu, 1 Mar 2001 04:25:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13020; Thu, 1 Mar 2001 04:25:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21CNUo14970 for mobile-ip-dist; Thu, 1 Mar 2001 04:23:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21CNDV14943; Thu, 1 Mar 2001 04:23:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12860; Thu, 1 Mar 2001 04:23:12 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA26672; Thu, 1 Mar 2001 04:23:12 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 06:29:11 -0500 Message-ID: From: George Tsirtsis To: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Cc: "'mipv6-handoff@sunroof.eng.sun.com'" , "'mobile-ip@marvin.corpeast.baynetworks.com'" Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt Date: Thu, 1 Mar 2001 06:29:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I got your e-mail only once...which means that the mailing list did not work...anyway..we keep going. -----Original Message----- From: James Kempf [mailto:james.kempf@sun.com] Sent: Wednesday, February 28, 2001 11:58 PM To: George Tsirtsis; mobile-ip@sunroof.eng.sun.com Cc: 'mipv6-handoff@sunroof.eng.sun.com' Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt ... > >GT> Well, that is the trick... The MN will send the BU assuming the nCOA is >OK...but it MUST NOT use the nCOA until it receives a BACK! The BACK will >only be sent by the oldAR if the HACK has been received from the newAR >saying that the nCOA is actually valid... So let me get this straight. Suppose the HI/HACK exchange happens and the newCoA is fine with newAR, and tells MN to use the newCoA, but for some reason the L2 move is delayed and the BU/BACK occurs over the old L2 connection. Since newAR is fine with the newCoA, oldAR reports a successful BACK. Now suppose, for some reason, that the L2 move is aborted. This could happen in cellular, for example, if the mobile suddenly moved back toward the middle of the cell and its power readings started increasing. Now the mobile is left on the old L2 with a topologically incorrect address to which oldAR is tunnelling. GT> The MN will only have to send a Neighbor Advertisement (which can also be signed) to the oldAR to retrieve its connection, some packets may be lost but even that should be rare...I think we can make this work but we have not talked about it in detail in the draft because we have some open issues...We plan to discuss this and in general ping pong during the IETF because the subject is complex and we have not managed to agree between us yet...I suggest we leave this point for now so we can be more productive... I assure you, we are going to come back to it during and after the IETF. >GT> If the MN connects to the newAR faster than the HACK returns to the >oldAR and assuming the MN has already send the BU, the MN will timeout and >resend the BU but it will not use the nCOA...see the Description paragraph >in section 4.7. I guess we have made the assumption that the HI/HACK >sequence is not going to be the limiting factor otherwise we do not make the >handoff faster but slower => not good :-) > I think this assumption is probably valid, since the HI/HACK is going through the wired network. It should, however, be stated. GT> OK. ... According to the description of PrRtAdv on pg. 14: In sateful (sp. stateful) configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for (presumably newAR?). In stateless address auto- configuration, this option may or may not be sent. If sent, indicates the requesting node SHOULD use this address as newCoA for the duration of the handover. If not sent, the requesting node SHOULD compute the newCoA using the Interface ID from the Destination Address of this message. Now, according to this, use of this address is completely optional. If the MN chooses not to use it or oldAR chooses not to send it, the MN MUST do new CoA generation at the newAR, otherwise it can't send a BU. So, in effect, the MN could be left in the position where it generates a CoA which newAR already knows is invalid, then sends that CoA to oldAR, and has it vetoed in the BACK. Then it has to go through another round of CoA address generation. I don't think this will reduce any signalling. GT> Whether this option is sent or not, the newCOA is calculated the same way by both the oldAR and the MN (at least in the stateless case). The reason we made this optional is that sending this option avoids guesswork at the oldAR...i.e.: the oldAR knows for a fact the address that the MN will use as a newCOA. On the other hand this costs a 24bytes long option...which we did not want to make mandatory since we try to minimize bits over the air where possible. Note that the chances of the oldAR calculating a different address from the MN given the same Interface ID and Prefix is really very very small. We only added this option to cover for the privacy draft where the MN might want to change Interface ID very often... There is a further problem with the description of this message on pg. 13/14 (which I just now saw, trying to make sense of the last sentence). What is meant by "the Interface Id of the Destination address?" First off, if the MN is to form a CoA, doesn't it use its own interface ID and the network ID of the subnet advertised by the router? GT> I guess that you are referring to: "the Interface Id of the Destination address" of the *PrRtAdv* message that is going to the MN. The oldAR can use the Interface ID of this address (which we know it belongs to the MN) to construct the newCOA...what is the problem? Secondly, the description of the Destination Address on pg. 13 states: The Source Address of an invoking Router Solicitation for Proxy or the addrss of the node the Access Router is instructing to handover. What does this mean? It sounds to me, and from the protocol diagrams on pg. 8) that the PrRtAdv is coming from oldAR. Is that its address? If so, then how can the MN form a CoA on the new link when it doesn't have the subnet? If not, then I think the description should reflect that. GT> I think I might be missing your point...The PrRtAdv is sent from the oldAR to the MN. The Destination Sddress of this message is the address of the MN (which can be derived by the Source Address of the RtSolPr message that was sent from the MN to the oldAR earlier). This same address includes an Interface ID that can be used to calculate the newCOA...Did I miss your point? >In the network assisted, "stateless" config case, how does the MN get >notified of >nCoA when it gets to newAR? For example, newAR might determine that the >address is invalid, but only oldAR gets told. MN needs to go through >some >procedure, presumably standard MIPv6 CoA configuration, only to be told >at >some point that it can't use the address, while newAR knows this all >along. >Is this so, or am I missing something? > >GT> Here is what is going on: The first think the MN does when it connects >to the newAR is to send Neighbor Advertisement (NA). Assuming the BU has >already been send, 3 things can happen. >- nCOA is valid => A buffed BACK is delivered to the MN which can now use >the nCOA >- nCOA is invalid => A buffered BNACK is delivered to the MN which must now >get a newCOA all over again (revert back to normal MIPv6) >- delays/errors (Any of BU, HI , HACK and BACK was lost/delayed) => No BACK >is delivered to the MN, the MN must resend the BU to the oldAR... OK, but I still don't understand why the MN has to go through all this signalling when newAR may have already sent the HACK and possibly has already been defending the newCoA. Why can't MN simply ask newAR, and if it gets no response, then go through the standard MIP newCoA generation? GT> What is "all that signaling"? The MN will have to send a BU and the oldAR will have to send a BACK for routing change purposes...no way around that, agree? So what is the added signaling? In any case, another reason (which Mohamed reminded me off) is security...the MN does not have a security association with the newAR yet...all other messages in this mechanism are secured... ... > >GT> Jak, what you are saying is OK only if the network can determine the >fact that the MN must be handed-off well in advance...and thus have time to >do HI/HACK before you send the PrRtAdv and this is certainly allowed (and >you can use it for stateless config as you suggest...). We felt, however, >that you might not have all this time...In this case you do stateless as we >suggest and you send the PrRtAdv virtually at the same time you send the HI >message...that is definitely faster... Well, according to previous comment, the group seemed to feel that the HI/HACK was fast. Also, if the PrRtAdv is sent at the same time, it can't have a newCoA in it, because the oldAR hasn't yet received an acknowledgement that the generated newCoA is OK, correct? Given that, the MN ends up having to generate a newCoA on the other end anyway, going through all the signalling involved in MIP CoA generation. GT> Jak, you are missing a fine little point since the start of this discussion. The oldAR CAN SEND the newCOA even if it HAS NOT received the HACK! The trick is that we allow the oldAR to guess! In the unlikely case that the oldAR gets it wrong or the newAR for whatever reason replies with a HNACK, the oldAR will reply with a BNACK to the MN's BU...and the MN will have to do normal MIPv6. But this is very unlikely to happen anyway and we think it will speed things up in 99.9...% of the cases. I think we have to make sure that you and the WG understand this idea....which I see that it is counterintuitive and may need better explenation in the draft...I will make sure we cover this in the presentation. ... >to get routing right...and thus everything is based at the oldAR (which >controls routing for the MN)...so we also delegate, the confirmation to the >MN that its nCOA is OK, to the oldAR and we deliver this information in the >BACK which also confirms that the routing change has taken place...A design >decision, someone else might have based everything on the newAR...but that >would be a different design. Right, and I think it would result in less signalling in some cases. That's what I'm trying to say. Also, this is a design assumption that is left unstated in the draft. It should be clearly articulated. GT> OK, I see that we can make this more clear...The discussion with you has brought up a number of points that should be clarified...we will try to do this in the next version. ... > >GT> The requirement is that the MN gets the PrRtAdv before the link to the >oldAR is severed...how you do this is implementation specific...not sure >what you want us to say about it...If for some reason it does not happen >(PrRtAdv) gets lost then, in the normal graceful IP manner the MN will have >to do normal MIPv6.... Then this should be stated in the draft, and it is obvious, to me anyway, that it requires L2 information because the MN can't possibly know it otherwise. GT> OK, will do, thanks. >In the case of the BU, I would assume that it *does* matter, that the >mobile node will not send the BU until it knows it has a solid new L2. >Otherwise, it might be telling oldAR >to route to the nCoA before it even has L2 established. So how does it >find >this out? > >GT> I think you may have now understood from the discussion so far what is >happening. The BU is sent with the *assumption* that the nCOA is >valid...this is not confirmed, however, and routing does not change until >and HACK is returned by the oldAR and BACK returned to the MN... As mentioned, I think it is possible to do much better if the MN simply asks newAR. It would simplify the design. Why was the design decision made to base confirmation of newCoA validity on oldAR? Perhaps the group had a good reason for this, if so,I think it ought to be listed in a "Design Goals" section. GT> I brought up two reasons up to now. 1. Routing change has to be based at oldAR so we thought we base the whole design on a single point rather than distribute different aspects of it in different points. 2. Security Association only exists between MN and oldAR + oldAR and newAR which already puts the oldAR in a strategically good position to handle the whole handoff. I think we can make these explicit in the draft. I would also be interested to see, if you have the time to work on this and still think is feasible, a bit more detail on how the newCOA confirmation can be done at the newAR...then we could judge better wether this is a good idea or not. ... > >So MN gets a trigger prior to sending RtSolPr in the mobile assisted >case, >and oldAR prior to HI in the network assisted case? > > >GT> In the Mobile Assisted or Mobile Determined the Mobile decides that is >must handoff, how is this done is outside the scope of this doc...It might >get a trigger or it might have the intelligence to figure that out by >itself...either way the same think happens... I think this is one of the key, meta-level objections I have to this draft. I do not think you can simply assume that L3 gets an L2 trigger up front that a handoff is about to happen , then continue signalling on L3 regardless of the state of L2. The problem is that handoff is a mixture of L2 actions and L3 actions, by its very nature. That said, I think it should be possible to work with some general abstractions about L2 actions rather than specific L2s, since most L2 designs will give you some information. Clearly articulating what information is required where and what to do if a particular L2 does not supply it is critical for having an interoperable design. If a designer would rather not use such L2 triggers at all, vanilla MIPv6 handoff will do just fine. They can even use an L2 trigger after handoff on the mobile via the driver and avoid having to wait for a multicast router advert. GT> OK, I think this can be further discussed and clarified. The problem is that we did spend a very long time discussing L2 triggers and L2 assumptions and although we think we more or less understand them, we found impossible (given the timeframe) to find *useful* general abstractions...and at the end we found that we did not have too...but let us think about this a bit more and see if now that we have completed this phase of work can go back and reconsider this. >I think this should be clearly stated somewhere in the draft, preferably >near >the front under "Assumptions". > >GT> Not really, there is no reason to state this...The implementer will have >to decide how things get triggered based on the link layer he/she is working >with...you think there will be a trigger coming from the network to trigger >the mobile determined case, I think the mobile will figure this out on its >own....and we are probably both correct for different link layers... No reason to state assumptions???? Stating assumptions is one of the hallmarks of a good specification. If you don't state assumptions, how is an implementer to know whether their situation has the right support for the specification? GT> Let me duck and take this back :-) Of course we have to state assumptions and I think you have correctly identified a number of things that might need to be explicitly stated. We may, however, disagree on how much we need to assume about Link Layers... >Why should this have to come from the oldAR? The newAR knows whether the >nCoA is valid, why can't the mobile simply ask it? > >GT> Now you are designing a new protocol and I am tempted to ask you to >write a draft :-) Seriously, we thought that the most important thing is I'm sorry for being so touchy, George, but I think there are some problems with this draft in terms of explanation, design complexity and some assumptions that I think were made that are not explained much less justified. If you are not willing to consider modifying the protocol based on working group input, let me know right now and I won't bother even working on it any further. GT> Modifications are always welcome but lets not rush and make changes before we all understand how this works. I can easily see why the draft might not be 100% clear since the design team has been working intensively on this for almost 4 months and some things that we came to realize and consider given, might not be in the draft in a way easy to digest...I am sure we will work on that..this is v00! I am just asking you to take the time (and I appreciate the effort you put on this already) and let the current design sink in before we rip it apart. I don't want this conversation to descend into the kind of knife fight that's been happening on Seamoby but, on the other hand, if want you are looking for is to have the working group simply rubber stamp your work, I'll simply say "sayonara" and you can get the rest of the working group to do it. GT> No, no...this is one of the, unfortunately rare these days, set of comments that are constructive and non religious! Lets keep going...let us help you understand what we have done and then we change what needs to be changed. George From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 12:40:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12526 for ; Thu, 1 Mar 2001 12:40:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19088; Thu, 1 Mar 2001 09:39:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00081; Thu, 1 Mar 2001 09:38:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21Hag316488 for mobile-ip-dist; Thu, 1 Mar 2001 09:36:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21HaXV16481 for ; Thu, 1 Mar 2001 09:36:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29691 for ; Thu, 1 Mar 2001 09:36:32 -0800 (PST) Received: from eagle.aud.alcatel.com (host60d9.alcatel.com [128.251.96.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00342 for ; Thu, 1 Mar 2001 09:36:32 -0800 (PST) Received: from mswitch.aud.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA18139; Thu, 1 Mar 2001 11:36:24 -0600 (CST) Received: from usa.alcatel.com by mswitch.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA14127; Thu, 1 Mar 2001 11:36:22 -0600 (CST) Message-ID: <3A9E8895.DD789091@usa.alcatel.com> Date: Thu, 01 Mar 2001 11:36:21 -0600 From: Behcet Sarikaya X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Raj and Phil, I think the critical question for micromobility (mm) branch of the Seamoby WG is to be or not to be, i.e. whether another routing protocol for mobility is required. Presently we have the MIP and the Manet routing approaches. The alternative seems to be per-host routes or host-based routing. I do not think there has been another breakthrough proposal significantly different. We all know Cellular IP and Hawaii proposals. Recently there is probably another one based on extending OSPF with host-based routes. Of course there are a lot of details but I think this is the crux of Seamoby mm problem. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 12:49:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12937 for ; Thu, 1 Mar 2001 12:49:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22960; Thu, 1 Mar 2001 09:47:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27138; Thu, 1 Mar 2001 09:46:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21HioO16619 for mobile-ip-dist; Thu, 1 Mar 2001 09:44:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21HifV16612 for ; Thu, 1 Mar 2001 09:44:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01726 for ; Thu, 1 Mar 2001 09:44:41 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26436 for ; Thu, 1 Mar 2001 09:44:40 -0800 (PST) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08599 for ; Thu, 1 Mar 2001 09:44:57 -0800 (PST) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03820 for mobile-ip@sunroof.eng.sun.com; Thu, 1 Mar 2001 12:44:39 -0500 (EST) Date: Thu, 1 Mar 2001 12:44:39 -0500 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: Re: gistration revocation Message-ID: <20010301124438.A3810@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from phil.roberts@motorola.com on Wed, Feb 21, 2001 at 01:21:05PM -0600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hope this finally gets through... Hi, We have submitted a draft dealing with Releasing Resources in MIP. Although intended for a different use, the draft has overlapping ideas with Steve's Registration Revocation draft. We'd like to possibly consolidate ideas with the Registration Revocation draft and thus, move forward with one merged WG item draft. A pointer to the draft: draft-subbarao-mobileip-resource-00.txt Thanks, Madhavi On Wed, Feb 21, 2001 at 01:21:05PM -0600, Roberts Philip-qa3445 wrote: > > Steve has requested we make Registration Revocation for Mobile IP a working > group document. The chairs are in agreement that this is a useful addition > to the suite of Mobile IP protocols. We'd like to hear from the working > group whether there are any complaints to making this a working group item. > Please respond on the working group mailing list by COB March 1." > > The draft is: > http://search.ietf.org/internet-drafts/draft-glass-mobileip-reg-revok-00.txt From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 13:08:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13735 for ; Thu, 1 Mar 2001 13:08:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03310; Thu, 1 Mar 2001 10:07:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07381; Thu, 1 Mar 2001 10:05:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21I3K816801 for mobile-ip-dist; Thu, 1 Mar 2001 10:03:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21I3AV16794 for ; Thu, 1 Mar 2001 10:03:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07495 for ; Thu, 1 Mar 2001 10:03:10 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07392 for ; Thu, 1 Mar 2001 11:03:09 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14049; Thu, 1 Mar 2001 10:03:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV01622; Thu, 1 Mar 2001 10:02:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28818; Thu, 1 Mar 2001 10:02:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15006.36559.662301.41126@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 10:02:55 -0800 (PST) To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF In-Reply-To: <3A9E8895.DD789091@usa.alcatel.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> <3A9E8895.DD789091@usa.alcatel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think this quite captures the finesse on the issue. I don't believe that the proper framing of the question is whether a new routing protocol needs to be invented or not: it may very well be that there is nothing to be done on the _routing protocol_ front to support injecting host routes if that's the ultimate solution. There may be work needed to support _signaling_ a router that it needs to change how a subnet is reachable. I know this is hair splitting, but I think it's important to separate out that it's quite possible that the heavy lifting can already be done by current protocols, and that all we need is the ability to trigger them to happen. You might call that a "routing protocol" too, but it ought not evoke the fear and loathing that postulating a Routing Protocol should. MIke Behcet Sarikaya writes: > Hi Raj and Phil, > > I think the critical question for micromobility (mm) branch of the > Seamoby WG is > to be or not to be, i.e. > whether another routing protocol for mobility is required. Presently we > have the MIP and > the Manet routing approaches. > The alternative seems to be per-host routes or host-based routing. I do > not think there > has been another breakthrough proposal significantly different. We all know > Cellular IP and > Hawaii proposals. Recently there is probably another one based on extending > OSPF with > host-based routes. > Of course there are a lot of details but I think this is the crux of > Seamoby mm problem. > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 13:11:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13978 for ; Thu, 1 Mar 2001 13:11:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11240; Thu, 1 Mar 2001 10:10:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09819; Thu, 1 Mar 2001 10:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21I8f716960 for mobile-ip-dist; Thu, 1 Mar 2001 10:08:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21I8UV16953 for ; Thu, 1 Mar 2001 10:08:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23948 for ; Thu, 1 Mar 2001 10:08:30 -0800 (PST) Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10766 for ; Thu, 1 Mar 2001 11:08:28 -0700 (MST) Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id CAA72324; Fri, 2 Mar 2001 02:59:44 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03112; Thu, 1 Mar 2001 10:06:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07381; Thu, 1 Mar 2001 10:05:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21I3K816801 for mobile-ip-dist; Thu, 1 Mar 2001 10:03:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21I3AV16794 for ; Thu, 1 Mar 2001 10:03:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07495 for ; Thu, 1 Mar 2001 10:03:10 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07392 for ; Thu, 1 Mar 2001 11:03:09 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14049; Thu, 1 Mar 2001 10:03:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV01622; Thu, 1 Mar 2001 10:02:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28818; Thu, 1 Mar 2001 10:02:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <15006.36559.662301.41126@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 10:02:55 -0800 (PST) To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF In-Reply-To: <3A9E8895.DD789091@usa.alcatel.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> <3A9E8895.DD789091@usa.alcatel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I don't think this quite captures the finesse on the issue. I don't believe that the proper framing of the question is whether a new routing protocol needs to be invented or not: it may very well be that there is nothing to be done on the _routing protocol_ front to support injecting host routes if that's the ultimate solution. There may be work needed to support _signaling_ a router that it needs to change how a subnet is reachable. I know this is hair splitting, but I think it's important to separate out that it's quite possible that the heavy lifting can already be done by current protocols, and that all we need is the ability to trigger them to happen. You might call that a "routing protocol" too, but it ought not evoke the fear and loathing that postulating a Routing Protocol should. MIke Behcet Sarikaya writes: > Hi Raj and Phil, > > I think the critical question for micromobility (mm) branch of the > Seamoby WG is > to be or not to be, i.e. > whether another routing protocol for mobility is required. Presently we > have the MIP and > the Manet routing approaches. > The alternative seems to be per-host routes or host-based routing. I do > not think there > has been another breakthrough proposal significantly different. We all know > Cellular IP and > Hawaii proposals. Recently there is probably another one based on extending > OSPF with > host-based routes. > Of course there are a lot of details but I think this is the crux of > Seamoby mm problem. > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 13:16:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14229 for ; Thu, 1 Mar 2001 13:16:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07230; Thu, 1 Mar 2001 10:15:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11126; Thu, 1 Mar 2001 10:14:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21ICKv17354 for mobile-ip-dist; Thu, 1 Mar 2001 10:12:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21IBfV17249 for ; Thu, 1 Mar 2001 10:11:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10279 for ; Thu, 1 Mar 2001 10:11:39 -0800 (PST) Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23155 for ; Thu, 1 Mar 2001 10:11:38 -0800 (PST) Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id DAA155140; Fri, 2 Mar 2001 03:02:56 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10965; Thu, 1 Mar 2001 10:10:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09819; Thu, 1 Mar 2001 10:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21I8f716960 for mobile-ip-dist; Thu, 1 Mar 2001 10:08:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21I8UV16953 for ; Thu, 1 Mar 2001 10:08:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23948 for ; Thu, 1 Mar 2001 10:08:30 -0800 (PST) Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10766 for ; Thu, 1 Mar 2001 11:08:28 -0700 (MST) Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id CAA72324; Fri, 2 Mar 2001 02:59:44 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03112; Thu, 1 Mar 2001 10:06:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07381; Thu, 1 Mar 2001 10:05:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21I3K816801 for mobile-ip-dist; Thu, 1 Mar 2001 10:03:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21I3AV16794 for ; Thu, 1 Mar 2001 10:03:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07495 for ; Thu, 1 Mar 2001 10:03:10 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07392 for ; Thu, 1 Mar 2001 11:03:09 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14049; Thu, 1 Mar 2001 10:03:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV01622; Thu, 1 Mar 2001 10:02:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28818; Thu, 1 Mar 2001 10:02:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <15006.36559.662301.41126@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 10:02:55 -0800 (PST) To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF In-Reply-To: <3A9E8895.DD789091@usa.alcatel.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> <3A9E8895.DD789091@usa.alcatel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I don't think this quite captures the finesse on the issue. I don't believe that the proper framing of the question is whether a new routing protocol needs to be invented or not: it may very well be that there is nothing to be done on the _routing protocol_ front to support injecting host routes if that's the ultimate solution. There may be work needed to support _signaling_ a router that it needs to change how a subnet is reachable. I know this is hair splitting, but I think it's important to separate out that it's quite possible that the heavy lifting can already be done by current protocols, and that all we need is the ability to trigger them to happen. You might call that a "routing protocol" too, but it ought not evoke the fear and loathing that postulating a Routing Protocol should. MIke Behcet Sarikaya writes: > Hi Raj and Phil, > > I think the critical question for micromobility (mm) branch of the > Seamoby WG is > to be or not to be, i.e. > whether another routing protocol for mobility is required. Presently we > have the MIP and > the Manet routing approaches. > The alternative seems to be per-host routes or host-based routing. I do > not think there > has been another breakthrough proposal significantly different. We all know > Cellular IP and > Hawaii proposals. Recently there is probably another one based on extending > OSPF with > host-based routes. > Of course there are a lot of details but I think this is the crux of > Seamoby mm problem. > > -- > Behcet > From ronyoung@nortelnetworks.com Thu Mar 1 16:19:06 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23677 for ; Thu, 1 Mar 2001 16:19:05 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:24 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:18:15 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04601 for ; Thu, 1 Mar 2001 15:08:03 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 15:07:53 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 15:07:51 -0500 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09394 for ; Thu, 1 Mar 2001 14:07:49 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Nl01075 for ; Thu, 1 Mar 2001 15:06:23 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16270; Thu, 1 Mar 2001 20:07:17 GMT Date: Thu, 1 Mar 2001 20:07:17 GMT Message-Id: <200103012007.UAA16270@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:07 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23684 for ; Thu, 1 Mar 2001 16:19:06 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:26 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:18:22 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04607 for ; Thu, 1 Mar 2001 15:08:08 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 15:07:57 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 15:07:54 -0500 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09402 for ; Thu, 1 Mar 2001 14:07:52 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Pl01105 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16311; Thu, 1 Mar 2001 20:07:19 GMT Date: Thu, 1 Mar 2001 20:07:19 GMT Message-Id: <200103012007.UAA16311@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:08 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23695 for ; Thu, 1 Mar 2001 16:19:07 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:27 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:18:39 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04603 for ; Thu, 1 Mar 2001 15:08:05 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 15:07:56 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 15:07:53 -0500 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09400 for ; Thu, 1 Mar 2001 14:07:52 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Pl01099 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16306; Thu, 1 Mar 2001 20:07:19 GMT Date: Thu, 1 Mar 2001 20:07:19 GMT Message-Id: <200103012007.UAA16306@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:10 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23708 for ; Thu, 1 Mar 2001 16:19:09 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:25 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:18:15 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04605 for ; Thu, 1 Mar 2001 15:08:07 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 15:07:57 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 15:07:54 -0500 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09399 for ; Thu, 1 Mar 2001 14:07:52 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Ol01090 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16296; Thu, 1 Mar 2001 20:07:18 GMT Date: Thu, 1 Mar 2001 20:07:18 GMT Message-Id: <200103012007.UAA16296@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:10 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23711 for ; Thu, 1 Mar 2001 16:19:10 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:28 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:19:49 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04667 for ; Thu, 1 Mar 2001 15:11:31 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Thu, 1 Mar 2001 12:10:06 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 12:13:23 -0800 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09396 for ; Thu, 1 Mar 2001 14:07:51 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Ol01084 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16285; Thu, 1 Mar 2001 20:07:18 GMT Date: Thu, 1 Mar 2001 20:07:18 GMT Message-Id: <200103012007.UAA16285@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:25 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23729 for ; Thu, 1 Mar 2001 16:19:24 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:26 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:18:22 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04609 for ; Thu, 1 Mar 2001 15:08:10 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 15:07:57 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 15:07:54 -0500 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09401 for ; Thu, 1 Mar 2001 14:07:52 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Ol01093 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16301; Thu, 1 Mar 2001 20:07:18 GMT Date: Thu, 1 Mar 2001 20:07:18 GMT Message-Id: <200103012007.UAA16301@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From ronyoung@nortelnetworks.com Thu Mar 1 16:19:40 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23757 for ; Thu, 1 Mar 2001 16:19:39 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 14:36:27 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 14:19:47 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04669 for ; Thu, 1 Mar 2001 15:11:33 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Thu, 1 Mar 2001 12:10:08 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 12:13:24 -0800 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA09397 for ; Thu, 1 Mar 2001 14:07:51 -0600 (CST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f21K6Ol01087 for ; Thu, 1 Mar 2001 15:06:25 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA16290; Thu, 1 Mar 2001 20:07:18 GMT Date: Thu, 1 Mar 2001 20:07:18 GMT Message-Id: <200103012007.UAA16290@qnsgs000.nortelnetworks.com> To: mobile-ip@smallworks.com From: tom wang Subject: subscribe mobile-ip Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: tom.wang@mail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit subscribe mobile-ip ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 17:18:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26163 for ; Thu, 1 Mar 2001 17:18:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04825; Thu, 1 Mar 2001 14:17:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15848; Thu, 1 Mar 2001 14:16:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21MDvt20373 for mobile-ip-dist; Thu, 1 Mar 2001 14:13:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21MDlV20366 for ; Thu, 1 Mar 2001 14:13:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26360 for ; Thu, 1 Mar 2001 14:13:48 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA14691 for ; Thu, 1 Mar 2001 14:13:46 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Thu Mar 1 17:11:45 EST 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA26399 for ; Thu, 1 Mar 2001 17:13:33 -0500 (EST) From: "Sandy Thuel" To: Subject: Dynamic Home Addressing I-D Date: Thu, 1 Mar 2001 17:11:15 -0500 Message-ID: <001d01c0a29c$888b43c0$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, We recently submitted an I-D to the mobileip WG on dynamic home addressing, entitled: "Dynamic Home Addressing in Mobile IP using Transient Tunnels" Since it is taking some time for the announcement to appear, you can get access to the draft at the following web site http://www.bell-labs.com/user/thuel/draft-thuel-mobileip-tt-01.txt Please send comments, concerns or suggestions. The more, the better. Sandy From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 17:22:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26312 for ; Thu, 1 Mar 2001 17:22:45 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25073; Thu, 1 Mar 2001 14:21:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17056; Thu, 1 Mar 2001 14:21:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21MJW720479 for mobile-ip-dist; Thu, 1 Mar 2001 14:19:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21MJLV20472 for ; Thu, 1 Mar 2001 14:19:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16650 for ; Thu, 1 Mar 2001 14:19:22 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08287; Thu, 1 Mar 2001 14:19:22 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA02681; Thu, 1 Mar 2001 14:19:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV08482; Thu, 1 Mar 2001 14:19:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28891; Thu, 1 Mar 2001 14:19:13 -0800 (PST) From: Michael Thomas Message-ID: <15006.51937.60735.267223@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 14:19:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Hemant.Chaskar@nokia.com Cc: mat@cisco.com, hchaskar@hotmail.com, Hesham.Soliman@era.ericsson.se, james.kempf@sun.com, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I really don't even know where to begin. It seems that your claim is that RSVP's receiver oriented PATH/RESV is either flawed, or should have a mode which allows a single pass. I believe this leads to overbooking for multicast since you don't get to do flow merging properly and a host of other reasons that I don't purport to understand well. What I really don't understand is why MIP would be the right place to solve this problem. If it has merit, the RSVP folks seems like a much more appropriate set of people to entertain such a proposal. I suspect that they'd be able to supply a lot more reasons why they designed RSVP the way they did. Suggesting that mobileip is a breed apart that requires its own QoS mechanisms sounds just as wrong headed as RSVP folks designing their own mobility protocol. Mike Hemant.Chaskar@nokia.com writes: > Yes, it goes end to end. But there is a basic difference illustrated > by following example. If we look at the latency between time end nodes > are ready to use new CoA and the time QoS forwarding treatment is programmed > > over the new path, it can be seen that RSVP takes one end-to-end round trip > time > between these two events. On the other hand, including QoS object with > binding > messages performs QoS programming before the nodes release packets using > new CoA. This is shown by following illustration. > > Suppose MN is currently at CoA1. Consider data traffic from the > CN towards the MN (downlink direction). > > o MN moves to CoA2. > > o MN sends BU from CoA2. > > ----[One way end-to-end delay]---- > > o BU reaches CN. CN sends BA to MN at CoA2. > > In RSVP, CN sends PATH message to MN at CoA2. > > In our approach, QoS OBJECT OPTION for downlink packet stream(s) > is included in HOP-by-HOP OPTIONS EXTENSION HEADER with the BA. > > o CN may start sending MN's packets to CoA2. These packets > contain CoA2 as destination address. > > **In RSVP approach, they are not identified by existing > reservations for MN's sessions. This is because, RSVP session is > primarily identified by destination address which now has changed > from CoA1 to CoA2. Hence, these packets will get default > forwarding treatment.** > > **In our approach, the packet carrying QoS information about these > packets precedes these packets, and hence, they can get proper > forwarding treatment.** > > ----[One way end-to-end delay]---- > > o BA reaches MN at CoA2. In RSVP approach, PATH message reaches > MN at CoA2. > > o In RSVP approach, MN sends RESV to CN. > > ----[One way end-to-end delay]---- > > o In RSVP approach, RESV reaches CN. > > **In RSVP approach, it is at this time that the proper QoS > forwarding treatment is programmed at the intermediate network > domains for packets destined to CoA2.** > > > Hemant > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 01. March 2001 13:33 > To: Hemant Chaskar > Cc: Hesham.Soliman@era.ericsson.se; james.kempf@sun.com; > mobile-ip@marvin.corpeast.baynetworks.com; seamoby@diameter.org > Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff > > > > I don't see how this fundamentally changes > anything that James brought up. It still has to go > end to end, and it's still touching every router > in between MN and CN. > > What I do see is a lot of reinvention of RSVP > Rspec and Tspec's for no known reason. The only > thing I can see of possible value is the ability > to piggyback the QoS update with the BU, but even > if this is the sole goal -- and that it's a worthy > goal which is not at all apparent to me -- I > imagine that there are better ways of doing this > with out reinventing RSVP: like, maybe, > piggybacking the BU on the PATH, or some such. > > Mike > > > Hemant Chaskar writes: > > Regarding the issue of round-trip latency in programming QoS forwarding > > treatment along new path after change in CoA: > > > > This is intrinsic drawback of OPWA model of resource reservation of RSVP. > In > > the worst case, one round-trip time will include traversals of four > wireless > > links. This happens when both CN and MN are mobile. > > > > Note that this drawback is eliminated in the approach to QoS signaling > based > > on including QoS Object in hop-by-hop options extension header along with > > > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was > > presented in SD and revised version (01) will be submitted soon. > > > > Hemant > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 17:49:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27169 for ; Thu, 1 Mar 2001 17:49:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28407; Thu, 1 Mar 2001 14:48:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22296; Thu, 1 Mar 2001 14:47:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21Mk3X20848 for mobile-ip-dist; Thu, 1 Mar 2001 14:46:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21MjrV20836 for ; Thu, 1 Mar 2001 14:45:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13551 for ; Thu, 1 Mar 2001 14:45:54 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20177 for ; Thu, 1 Mar 2001 14:45:54 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA15141 for ; Thu, 1 Mar 2001 14:45:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV09233; Thu, 1 Mar 2001 14:45:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28899; Thu, 1 Mar 2001 14:45:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15006.53536.527304.135424@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 14:45:52 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [resend to make it onto the real mip list..] I don't see how this fundamentally changes anything that James brought up. It still has to go end to end, and it's still touching every router in between MN and CN. What I do see is a lot of reinvention of RSVP Rspec and Tspec's for no known reason. The only thing I can see of possible value is the ability to piggyback the QoS update with the BU, but even if this is the sole goal -- and that it's a worthy goal which is not at all apparent to me -- I imagine that there are better ways of doing this with out reinventing RSVP: like, maybe, piggybacking the BU on the PATH, or some such. Mike Hemant Chaskar writes: > Regarding the issue of round-trip latency in programming QoS forwarding > treatment along new path after change in CoA: > > This is intrinsic drawback of OPWA model of resource reservation of RSVP. In > the worst case, one round-trip time will include traversals of four wireless > links. This happens when both CN and MN are mobile. > > Note that this drawback is eliminated in the approach to QoS signaling based > on including QoS Object in hop-by-hop options extension header along with > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was > presented in SD and revised version (01) will be submitted soon. > > Hemant > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > --OAA02477.983486356/sj-msg-core-4.cisco.com-- From ronyoung@nortelnetworks.com Thu Mar 1 18:03:40 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27552 for ; Thu, 1 Mar 2001 18:03:39 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 15:36:54 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 15:39:57 -0600 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.100.129.29]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id QAA06248 for ; Thu, 1 Mar 2001 16:30:22 -0500 (EST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 15:30:00 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4351C70F@crchy271.us.nortel.com> From: "Glenn Morrow" To: "'Michael Thomas'" , Hemant Chaskar Cc: Hesham.Soliman@era.ericsson.se, james.kempf@sun.com, mobile-ip@marvin.corpeast.baynetworks.com, seamoby@diameter.org Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff Date: Thu, 1 Mar 2001 15:29:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A296.C11978C0" X-Orig: X-Orig: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A296.C11978C0 Content-Type: text/plain Sounds like a no-brainer to me. The handoff signaling was the question and it looks like an ICMP solution has emerged? Where do you propose to put the objects there or have you not resigned yourselves to accept the ICMP solution (i.e. do you still want to try to push RSVP)? I really care more about the function than the WG or the protocol choosen - pick one. One advantage (tenous as it may be) of putting the QoS objects in IP itself is that it pretty much stops the argument about which protocol or WG to use for what, when more than one function is needed. Extremely counter to this is the investment each party has made in existing signaling solutions. With a start from scratch mentality I would put in an IP header as I feel that it is a network layer function. Regards, Glenn > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Thursday, March 01, 2001 12:33 PM > To: Hemant Chaskar > Cc: Hesham.Soliman@era.ericsson.se; james.kempf@sun.com; > mobile-ip@marvin.corpeast.baynetworks.com; seamoby@diameter.org > Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff > > > I don't see how this fundamentally changes > anything that James brought up. It still has to go > end to end, and it's still touching every router > in between MN and CN. > > What I do see is a lot of reinvention of RSVP > Rspec and Tspec's for no known reason. The only > thing I can see of possible value is the ability > to piggyback the QoS update with the BU, but even > if this is the sole goal -- and that it's a worthy > goal which is not at all apparent to me -- I > imagine that there are better ways of doing this > with out reinventing RSVP: like, maybe, > piggybacking the BU on the PATH, or some such. > > Mike > > > Hemant Chaskar writes: > > Regarding the issue of round-trip latency in programming QoS forwarding > > > treatment along new path after change in CoA: > > > > This is intrinsic drawback of OPWA model of resource reservation of > RSVP. In > > the worst case, one round-trip time will include traversals of four > wireless > > links. This happens when both CN and MN are mobile. > > > > Note that this drawback is eliminated in the approach to QoS signaling > based > > on including QoS Object in hop-by-hop options extension header along > with > > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was > > presented in SD and revised version (01) will be submitted soon. > > > > Hemant > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > ------_=_NextPart_001_01C0A296.C11978C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] Hierarchical MIP, QoS, and Handoff

Sounds like a = no-brainer to me. The handoff signaling was the question and it looks = like an ICMP solution has emerged?

Where do you propose = to put the objects there or have you not resigned yourselves to accept = the ICMP solution (i.e. do you still want to try to push = RSVP)?

I really care more = about the function than the WG or the protocol choosen - pick = one.

One advantage = (tenous as it may be) of putting the QoS objects in IP itself is that = it pretty much stops the argument about which protocol or WG to use for = what, when more than one function is needed.

Extremely counter to = this is the investment each party has made in existing signaling = solutions.

With a start from = scratch mentality I would put in an IP header as I feel that it is a = network layer function.


Regards,

Glenn

-----Original Message-----
From:   Michael Thomas [SMTP:mat@cisco.com]
Sent:   Thursday, March 01, 2001 12:33 PM
To:     Hemant Chaskar
Cc:     Hesham.Soliman@era.ericsson.se; james.kempf@sun.com; = mobile-ip@marvin.corpeast.baynetworks.com; = seamoby@diameter.org

Subject:       = RE: [seamoby] Hierarchical MIP, QoS, = and Handoff


I don't see how this fundamentally = changes
anything that James brought up. It = still has to go
end to end, and it's still touching = every router
in between MN and CN.

What I do see is a lot of reinvention = of RSVP
Rspec and Tspec's for no known = reason.  The only
thing I can see of possible value is = the ability
to piggyback the QoS update with the = BU, but even
if this is the sole goal -- and that = it's a worthy
goal which is not at all apparent to = me -- I
imagine that there are better ways of = doing this
with out reinventing RSVP: like, = maybe,
piggybacking the BU on the PATH, or = some such.

             Mike


Hemant Chaskar writes:
 > Regarding the issue of = round-trip latency in programming QoS forwarding
 > treatment along new path = after change in CoA:
 >
 > This is intrinsic drawback = of OPWA model of resource reservation of RSVP. In
 > the worst case, one = round-trip time will include traversals of four wireless
 > links. This happens when = both CN and MN are mobile.
 >
 > Note that this drawback is = eliminated in the approach to QoS signaling based
 > on including QoS Object in = hop-by-hop options extension header along with
 > binding messages = (draft-chaskar-mobileip-qos-00.txt). This draft was
 > presented in SD and = revised version (01) will be submitted soon.
 >
 > Hemant
 > = _________________________________________________________________=
 > Get your FREE download of = MSN Explorer at http://explorer.msn.com
 >

------_=_NextPart_001_01C0A296.C11978C0-- From ronyoung@nortelnetworks.com Thu Mar 1 18:45:07 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28475 for ; Thu, 1 Mar 2001 18:45:06 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 16:12:40 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 16:13:43 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id RAA06897 for ; Thu, 1 Mar 2001 17:08:09 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Thu, 1 Mar 2001 14:03:35 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 14:06:49 -0800 Received: from pluto.acs.unt.edu (pluto.acs.unt.edu [129.120.220.2]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id QAA09975 for ; Thu, 1 Mar 2001 16:04:39 -0600 (CST) Received: from cs.unt.edu (cs.unt.edu [129.120.36.230]) by pluto.acs.unt.edu (8.9.3/8.9.3) with ESMTP id QAA28041 for ; Thu, 1 Mar 2001 16:04:20 -0600 (CST) Received: from csp01.csci.unt.edu (csp01.csci.unt.edu [129.120.36.65]) by cs.unt.edu (8.9.3/8.9.3) with ESMTP id QAA18231 for ; Thu, 1 Mar 2001 16:04:18 -0600 (CST) (envelope-from swim99@cs.unt.edu) Received: from swim99 by csp01.csci.unt.edu with local (Exim 3.12 #1 (Debian)) id 14YbBL-0007xc-00 for ; Thu, 01 Mar 2001 16:04:19 -0600 To: mobile-ip@smallworks.com X-Mailing-List: swim99@ix.csci.unt.edu X-Mailing-List-Server: SWiMified minordomo 0.6.1 X-Loop: swim99@ix.csci.unt.edu Precedence: bulk Subject: Distr. Simulation Message-Id: From: Dist-Simulation2001 Date: Thu, 01 Mar 2001 16:04:19 -0600 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: swim99@cs.unt.edu X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: 100447.2316@compuserve.com 72507.3332@compuserve.com 95412030@plink.cityu.edu.hk A.karbowski@ia.pw.edu.pl ASENGUPT@us.oracle.com ASSJTurner@ntu.edu.sg ASWTCAI@ntu.edu.sg AWhitney@TASC.com Abdel-Ghani.Daraiseh.abdeld@nt.com Ahgreenberg21@aol.com Alexander.Vankov@d3group.com Amitava_Mukherjee@india.notes.pwa.co.in Andrzej_Pelc@uqah.uquebec.ca Ani_Sanyal@fleet.com Aniruddha.Banerjee@mckesson.com Aniruddha_Kundu@ccm.intel.com Annie.Picart@enst-bretagne.fr Antoine.Clerget@sophia.inria.fr Artur.Ziviani@lip6.fr BFOSS@ist.ucf.edu BOUKERCHE@netcourrier.com BWaite@aegisrc.com Bengt.Ahlgren@sics.se Brian_Sante@stricom.army.mil Bruno.Preiss@UWaterloo.Ca ByrumCA@NSWC.NAVY.MIL C.A.F.Nielsen@ifad.dk CDzermajko@p21.com CHu@uh.edu CSallas@aegistg.com Christian.Frei@epfl.ch Claude.Castelluccia@inrialpes.fr Cong-Duc.Pham@lip6.fr Cong-Duc.Pham@lip6.fr Corentin.Durbach@prism.uvsq.fr Cost264@lip6.fr D.Ferguson@mot.com D.G.Clark@datasci.co.uk David.Gitlin@SMGInc.com David.Kelton@uc.edu Dr.Graef@t-online.de DunnEP@NPT.NUWC.NAVY.MIL EWARTRB@wl.wpafb.af.mil Edward.Korsberg@cle.ab.com FRANCO@DIST.UNIGE.IT Faruk.Hadziomerovic.fsh@nt.com Fethi.Filali@sophia.inria.fr Fitz.7@osu.edu Fodor@era-t.ericsson.se Frits.vanMerode@beoz.unimaas.nl Gene_Wiehagen@stricom.army.mil Hua.Jiang.huajiang@nt.com IEEETCPC@listserv.utoronto.ca Ilie.Stiharu_Alexe@eng.canadair.ca Iraqi@ieee.org J.Banaszak@shu.ac.uk J.Cleary@cs.waikato.ac.nz J.P.Cosmas@qmw.ac.uk JLAI@winlab.RUTGERS.EDU JOHNSTRR@wl.wpafb.af.mil Jallel.benothman@prism.uvsq.fr James.Coolahan@jhuapl.edu Jastinder.Jawanda.jawanda@nt.com Jean-Pierre.J.F.FAYE@SDC.thomson.fr Jerome.Galtier@sophia.inria.fr Jerome.mbai@enit.rnu.tn Josef.Weidendorfer@in.tum.de Jouni.Ikonen@lut.fi K.Begain@scm.brad.ac.uk KATHERINE.L.MORSE@saic.com KKang@nps.navy.mil Kalyan.BASU.kbasu@nt.com Karayannis@uh.edu Kennedy_Jim@bls.gov Kiran.S.Panesar@intel.com Kleijnen@KUB.NL LBM_MRA@ix.netcom.com LSnyder@aegistg.com Linda.Wilson@Dartmouth.edu Ljubica.Blazevic@epfl.ch Lui.Carroll@insa-tls.fr Luis.Costa@lip6.fr M.Conti@cnuce.cnr.it MDAINESI@ar.oracle.com Marco.Conti@cnuce.cnr.it Marilyn_Emmans@amecom.com Martin.Zauner@risc.uni-linz.ac.at Mats.Brorsson@it.lth.se Mattern@Informatik.TU-Darmstadt.de NARAYAN@WINLAB.RUTGERS.EDU NMalone@aegistg.com OChevassut@lbl.gov Olivier.Perrin@loria.fr P.Gevros@cs.ucl.ac.uk Paddy.Nixon@cs.tcd.ie Pat.Talbot-contractor@jntf.osd.mil Pentti.Huttunen@lut.fi Peter.Luksch@in.tum.de PetriNets@daimi.aau.dk Pierre.Bieber@cert.fr Pierre.Siron@cert.fr Pierrette.Villardy@supaero.fr Piyasena@shu.ac.uk R.J.Campion@staffs.ac.uk RAlo@uh.edu RHC@MIS.MHIT.EDU.TW ROBKIN@perceptronics.com RON.JOHNSTON@FLIGHT.WPAFB.AF.MIL Rajeev.Jayaram@exu.ericsson.se ReillySM@npt.nuwc.navy.mil Rick_McKenzie@cpqm.saic.com Robert.Macredie@brunel.ac.uk Roger_werner@ntsc.navy.mil S.Ghaheri-Niri@ee.surrey.ac.uk SKukolich@Camb-LADS.loral.com SMPA8725@jpo-miti.go.jp SPEEDES@aol.com SSwimmer@getty.edu Sami.Tabbane@email.ati.tn Schaffer@Camb-LADS.loral.com Scott.Charles@nmnh.si.edu Serge.Fdida@lip6.fr Serge.Fdida@lip6.fr Shyam.Chakraborty@hut.fi Silvia.Giordano@epfl.ch Somprakash_Bandyopadhyay@india.notes.pwa.co.in Soraya.Zertal@prism.uvsq.fr Srikanth.kambhatla@intel.com Stefan.Kaiser@dlr.de Stefano.Russo@unina.it SteveF@cs.waikato.ac.nz Tajudeen.Atolagbe@brunel.ac.uk Ted.Clowes@Cubic.Com Thomas.Brandes@gmd.de Tom.Lake@glossa.co.uk VINCENT.E.DIEHL@cpmx.saic.com WUERFERD@b045mail.wpafb.af.mil Wayne.Loucks@UWaterloo.Ca Werner.Almesberger@epfl.ch Yann.Boniface@loria.fr Zied.Choukair@enst-bretagne.fr ZimmermanPM@navair.navy.mil a.s.mcgough@ncl.ac.uk a.seneviratne@unsw.edu.au aalo@fau.edu aapon@comp.uark.edu aaz@rice.edu abani@eng.buffalo.edu abc@arl.mil abe@cc.tohoku.ac.jp abello@research.att.com abhijit@serc.iisc.ernet.in aboelaze@cs.yorku.ca abraham@vismath.org abrams@daphne.cs.vt.edu achandrarajan@yahoo.com acharya@bell-labs.com achilles@lucent.com achou@clarku.edu aconti@deis.unibo.it acox@ist.ucf.edu acpc-l@risc.uni-linz.ac.at adb@signal.dra.hmg.gb addison@cs.ucla.edu adg@dibe.unige.it adg@research.panasonic.com adi@cpsc.ucalgary.ca adj@rover.CS.Berkeley.EDU adnan@ee.tamu.edu afonso.ferreira@sophia.inria.fr agchiu@comino.lcs.mit.edu agrawal@cs.ucsb.edu agrawal@cstp.umkc.edu agrawala@cs.umd.edu agriffin@ist.ucf.edu agv@elo.utfsm.cl ai@ubd.edu.bn ajib@infres.enst.fr ajmone@polito.it ajr@cs.unt.edu akahol@cisco.com aktouf@amon.imag.fr alagoz@gwu.edu alain.quilliot@sp.isima.fr alain.tanguy@sp.isima.fr alex@loas.fr alexkoh@hotmail.com alext@pine.ece.utexas.edu alexz@cs.uclas.edu alfredo@lamport.rhon.itam.mx alg@comm.toronto.edu ali@megahertz.njit.edu allen@star.ee.ntu.edu.tw alm@cs.wustl.edu almsick@sican.de almulla@mcs.sci.kuniv.edu.kw alouini@ece.umn.edu alp@ifit.uni-klu.ac.at alsaialy@ipa.edu.sa aluru@cs.nmsu.edu aly@mag.keio.ac.jp amadeus@risc.uni-linz.ac.at amamiya@is.kkyusyu-u.ac.jp amawy@gate.ee.lsu.edu ambler@mail.utexas.edu ambuj@cs.ucsb.edu amina@seas.gwu.edu amitava.mukherjee@ieee.org amitava.mukherjee@in.pwcglobal.com aml@cs.wustl.edu ammar.attoui@sp.isima.fr ammar@cc.gatech.edu amotz@eng.tau.ac.il an4m@cs.virginia.edu anand@cs.virginia.edu anavarro@icesi.edu.co andonovo@univ-valenciennes.fr andras@comet.columbia.edu andre-luc.beylot@prism.uvsq.fr andreas.pitsillides@ucy.ac.cy andreas@percptronics.com andrew@cs.princeton.edu andry@dstc.edu.au andy.goldfinger@jhuapl.edu anestis@comm.toronto.edu anita@mitre.org annap@cs.dartmouth.edu annaru@cs.technion.ac.il antonio@telecom.deis.unical.it anurag@ece.iisc.ernet.in anurag@hd1.vsnl.net.in anwar@bell-labs.com aoyama@kama.melco.co.jp aperles@disca.upv.es apizarro@lidi.info.unlp.edu.ar arached@dt.uh.edu araghav@ces.clemson.edu arakit@ccgw.open.rd.nttdata.jp arcg@opal-rt.com archie.morris@kottmann.com arisha@cs.umd.edu aronsonj@saic.com arudrapatna@ieee.org arun_arunachalam@nortel.com arup@ccrl.nj.nec.com asaad@ie-eg.com asalomaa@utu.fi asatani@sin.cc.kogakuin.ac.jp aselma01@starbase.spd.louisville.edu aslp@cs.princeton.edu aso@ecei.tohoku.ac.jp assaf@cs.technion.ac.il assar@sics.se assjturner@ntu.edu.sg assyhuang@ntu.edu.sg assyhuang@ntu.edu.sg astoyen@unomaha.edu asunil@novell.com aswtcai@ntu.edu.sg aswtcai@ntuix.ntu.ac.sg asyosh@sandia.gov athina@artemis.ece.drexel.edu ato@winlab.rutgers.edu aujpl@hotmail.com aussem@sp.isima.fr avibt@ecitele.com avresky@bu.edu awillig@ft.ee.tu-berlin.de awilson@virtc.com ayoussef@us.ibm.com ayu@eee.hku.hk b-george@wiu.edu baccelli@sophia.inria.fr badri@cs.rutgers.edu baer@cs.nps.navy.mil bahl@microsoft.com bai@mars.ee.fju.edu.tw baiocchi@infocom.uniroma1.it bakadir@ucam.ac.ma bakkali_h@yahoo.fr balaji@crhc.uiuc.edu balaran@adsrc.org balterse@ert.rwth-aachen.de banerjee@crhc.uiuc.edu banerjee@ece.northwestern.edu banerjee@ece.nwu.edu bao@jaist.ac.jp barbeau@scs.carleton.ca baresi@elet.polimi.it barham@rbd.com barrett@lanl.gov barry.n.glass@boeing.com barry_mitchell@jhuapl.edu bart@cs.tamu.edu barta@ttt-atm.ttt.bme.hu bartosz.mielczarek@s2.chalmers.se baruch@cs.jhu.edu barun@jaist.ac.jp basagni@utdallas.edu basol@vhdl.poly.edu bassi@cs.ucf.edu battiti@science.unitn.it bauerd@cs.rpi.edu bauerd@cs.rpi.edu bdasgupta@att.com bdavis@getty.edu bdl@bell-labs.com bdl@research.bell-labs.com beatriz@sanjuan.com.ar beaumont@univ-brest.fr beaune@emse.fr beej@cs.dartmouth.edu beheshti@dt3.dt.uh.edu bellenot@math.fsu.edu bellman@aero.org ben_abd@hotmail.com benaboud@crid.u-bourgogne.fr benchd@dtc.army.mil benny@sp.isima.fr bennybing@ieee.org berger@watson.ibm.com berkling@is.tsukuba.ac.jp bermond@sophia.inria.fr bernhard.dangl@utanet.at bernhold@npac.syr.edu berqia@crid.u-bourgogne.fr berrached@adsrc.org beto@jaist.ac.jp bettaz@ist.cerist.dz bf@src.lip6.fr bfoss@ist.ucf.edu bfwang@cs.nthu.edu.tw bhabani@www.isical.ac.in bhargava@ece.uvic.ca bhaskar@ccrl.nj.nec.com bhatt@bellcore.com bhatt@info.kochi-tech.ac.jp bianca@mpi-sb.mpg.de bianchi@elet.polimi.it bilderba@erc.msstate.edu bili@weihl.com bill@ucla.edu binh@ee.unsw.edu.au binli99@163.net bisdik@us.ibm.com bisdik@watson.ibm.com bjo@science.uva.nl bjorn.hjelm@alltel.com bki@top.cis.syr.edu blazevic@lrc.di.epfl.ch blee@seas.gwu.edu bley@zib.de blhughes@eos.ncsu.edu bli@cs.ust.hk blondia@uia.ua.ac.be bm@uni-paderborn.de bmcqueary@sps.com bmm@cs.cmu.edu bnoble@siue.edu bob.hunter@trw.com bob.murray@boeing.com bob_meyer@imdgw.chinalake.navy.mil bodin@irisa.fr boeger@ibr.es.tu-bs.de boeres@urbi.com.br bohuli@moon.bjnet.edu.cn bononi@cs.unibo.it bonucce@di.unipi.it booker@mitre.org boppana@cs.utsa.edu boris@concord.org boronat@vents.uji.es bosco@inf.ufsc.br boukerche@cs.unt.edu boukercherachid@hotmail.com boulis@janet.ucla.edu bouras@cerfacs.fr bourzouf@univ-valenciennes.fr bovet@uniroma2.it bpooi@gintic.gov.sg brad@ccrc.wustl.edu brasse@fel.tno.nl braunl@ee.uwa.edu.au brd@cs.uni-sb.de brenner@via.ecp.fr brett.e.butler@cpmx.saic.com brett_butler@jsims.com brian_mcenany@cpqm.saic.com brocha@ctr.columbia.edu brpreiss@uwaterloo.ca bruce@cs.jcu.edu.au brun@laas.fr bruno@cs.ucsb.edu brunst@zhr.tu-dresden.de brusil@nist.gov brutocao@ca.metsci.com brutzman@nps.navy.mil bschow@ee.nsysu.edu.tw bschrick@ist.ucf.edu bshep@research.bell-labs.com bsikdar@networks.ecse.rpi.edu bswift@hfl.tc.faa.gov btillman@aegisrc.com buchholz@ls4.informatik.uni-dortmund.de bunt@cs.usask.ca ian@cs.unt.edu nicol@cs.dartmouth.edu burkard@opt.math.tu-graz.ac.at bushsf@crd.ge.com busovaca@csus.edu bwinner@mitre.org bxu@eecs.uic.edu byrav@cse.unl.edu byrumca@nswc.navy.mil cabernet-events@ncl.ac.uk cai@cs.buffalo.edu cal@aero.org calder@cs.ucsd.edu calinescu@dimacs.rutgers.edu camargo@immd8.informatik.uni-erlangen.de campagne@emse.fr campbell@comet.columbia.edu campello@isl.stanford.edu cao@cs.umn.edu carey@cs.usask.ca carl@cs.mcgill.ca carl@ifad.dk carla@cs.duke.edu carlos@lamce.ufrj.br carmen@ca.sandia.gov carter@liquid.bellcore.com castiglione@amherst.com cawm@hodcs.att.com cbrand@salzburgresearch.at cburke@mitre.org cbyers@originalsim.com ccchiang@cs.ucla.edu cchen9@gmu.edu cchen@csie.nctu.edu.tw cchen@ece.missouri.edu cchiasse@cwc.ucsd.edu cchsu@csie.ntu.edu.tw cclim@gintic.gov.sg cdede@gmu.edu cdoulig@unipi.gr cdx@nju.edu.cn ceesd@fee.uva.nl ceh@cs.ucf.edu celanoj@spawar.navy.mil cellular@dfv.rwth-aachen.de cene@esil.univ-mrs.fr cg@comnets.rwth-aachen.de chLin@cs.ccu.edu.tw chaiKeong.Toh@cl.cam.ac.uk champeau@univ-brest.fr chang@charlie.cns.iit.edu changjie_wang@263.net chatelin@cerfacs.fr chekuri@research.bell-labs.com chen@cs.tamu.edu chen@vsl.ist.ucf.edu cheng@csce.kyushu-u.ac.jp chengl@caip.rutgers.edu cheriton@cs.stanford.edu cherkasova@hpl.hp.com cheung@cs.uh.edu chin@csis.hku.hk chinkw@flash.cs.curtin.edu.au chiola@disi.unige.it chiu@cs.ucf.edu chiueh@cs.sunysb.edu chjin@cise.ufl.edu chlamtac@utdallas.edu chlin@cs.ccu.edu.tw choa@umbc.edu chou@dsm.fordham.edu choudhar@ece.nwu.edu choy@cs.ust.hk chris.c.wallace@lmco.edu chris@cse.ucsc.edu chris_Bouwens@cpqm.saic.com christia@rice.edu christine.force@sp.isima.fr chs@regent.e-technik.tu-muenchen.de chun@itri.org.tw ci@att.com ciancu@cs.ucsb.edu cichler@tzd.telekom.de cieslik@rz.uni-greifswald.de cioffi@stanford.edu cipark@vision.postech.ac.kr cipherdist@itd.nrl.navy.mil cjcarlisle@csi.com cjdeschenes@tasc.com cjm@ix.netcom.com cjmb@signal.dra.hmg.gb cjrouget@dera.gov.uk ckim@popeye.snu.ac.kr ckim@popeye.snu.ac.kr cktoh@ece.gatech.edu clam@cis.ohio-state.edu claude.mazel@sp.isima.fr claudia_slaton@ntsc.navy.mil clc@spawar.navy.mil clchen@csie.ntu.edu.tw closed.Recipients@leonis.nus.edu.sg clwang@csis.hku.hk clyde@bellcore.com cmc@di.ufpe.br cmlin@crab.iecs.fcu.edu.tw cmr5@lehigh.edu cms@irb.uni-hannover.de cnom@maestro.bellcore.com cohen@percptronics.com comm-theory@ieee.org commsoft@cc.bellcore.com comswtc@gmu.edu conery@cs.uoregon.edu cortelle@info.uniroma2.it cost237-transport@comp.lancs.ac.uk costis@dcs.shef.ac.uk cotroneo@unina.it cpalau@dcom.upv.es cpalmieri@sanluis.inta.gov.ar cperkins@wishbone.corp.sun.com cpham@lhpca.univ-lyon1.fr craig@ndgsoftware.com craig@rushe.aero.org crdow@iecs.fcu.edu.tw cremones@elet.polimi.it crouzeix@ucfma.univ-bpclermont.fr cruz@lrg.ufsc.br csashi@cs.wisc.edu csdir@giasmd01.vsnl.net.in csiller@lucent.com csj@cc.ee.ntu.edu.tw cslui@cse.cuhk.edu.hk cspgxxy@brunel.ac.uk csu95126@cse.iitd.ernet.in csyang@cie.nsysu.edu.tw ctc-members@redbank.tinac.com cturrell@dmso.mil curt@visicom.com cwctancl@leonis.nus.edu.sg cyoung@ececs.uc.edu cyu@icu.ac.kr d-wei@u-aizu.ac.jp d.kingston@comsoc.org d.saha@computer.org d3506013@csie.ntu.edu.tw d8309004@cs.ntust.edu.tw dachung@dis.tku.edu.tw dale.pace@jhuapl.edu damani@cs.utexas.edu damian.dalton@ucd.ie dana.scoot@cs.cmu.edu daniel.claude@espace.aerospatiale.fr dano@bellcore.com darcan@bound.edu.tr darken@cs.nps.navy.mil darlin@rs2.ocit.edu.tw darrell@cse.ucsc.edu daru@ludens.elte.hu das@cse.uta.edu datta@cs.unlv.edu dave@cyber.reading.ac.uk david@melbourneit.com.au davidn@ee.ucd.ie dbanerje@telecom.sna.samsung.com dbass@utdallas.edu dbenhaddou@hotmail.com dbenhaddou@princetonoptical.com dbrinker@lucent.com dcg@dcs.gla.ac.uk dcslsl@tsinghua.edu.cn dcsteoym@nus.edu.sg ddaly@crhc.uiuc.edu ddmiller@bvu-lads.loral.com ddweiner@ecs.syr.edu dead_head_99@msn.com dean_daugherty@pobox.tbe.com deanc@nefarious.orl.saic.com decker@uni-paderborn.de deedee@cse.iitkgp.ernet.in deelman@cs.ucla.edu deelmane@cs.rpi.edu dehan@iam.de delic@boun.edu.tr deo@cs.ucf.edu desaki@eei.metro-u.ac.jp despins@inrs-telecom.uquebec.ca dfinkel@cs.WPI.EDU dfk@cs.dartmouth.edu dg@dcs.kcl.ac.uk dhkim@ece.arizona.edu dhx@ornl.gov diane.baucher@cnet.francetelecom.fr dib@dera.gov.uk dib@dra.hmg.gb dieter@lfi.uni-hannover.de dikim@uoscc.uos.ac.kr dilip@crhc.uiuc.edu dilip@uiuc.edu dimako@ece.uvic.ca dimosthe@di.uoa.gr dinesh@rice.edu disz@mcs.anl.gov divyesh@almaden.ibm.com dkhotimsky@lucent.com dkidston@styx.uwaterloo.ca dkrishna@ichips.intel.com dlarocca@mitre.org dlb@ai.mit.edu dlee@cs.ust.hk dlm@ece.uc.edu dls102@psu.edu dmadhava@ececs.uc.edu, dmaltz@cs.cmu.edu dmiller@ll.mit.edu dmm@cs.cmu.edu doan@cs.usyd.edu.au docentes@cin.ufpe.br dogana@ee.eng.ohio-state.edu donat@CS.UniBO.IT dondo@adsrc.famu.edu dongarra@cs.utk.edu donpaul@bell-labs.com dorgival@dcc.ufmg.br doug.blough@ece.gatech.edu doug.wahrenberger@lmco.com dowd@computer.org dowd@eng.umd.edu dpa@ececs.uc.edu dpoole@nvl.army.mil drabe@sican.de dragon@cs.utexas.edu dranjan@cs.nmsu.edu dreimann@zeta.albion.edu dsagan@drc.com dsatish@eecs.wsu.edu dschwarzkoph@att.com dseidel@mitre.org dsj@research.att.com dsu@nist.gov dtang@gunpowder.Stanford.EDU dtheune@virtc.com dtoth@sophia.inria.fr dugonet@trac.nps.navy.mil dva1@gte.com dvanhook@ll.mit.edu dvh@iist.unu.edu dw.roberts@gtri.gatech.edu dwf@icst.ucla.edu.puc-rio.br dwisliam@adsrc.org dxs@aa.cs.keio.ac.jp dxwang@mail.tsinghua.edu.cn dza@avesta.com dzd@cs.umn.edu e.e.e.frietman@tn.tudelft.nl ebslee@ntu.edu.sg echong@ecn.purdue.edu eci@cs.brown.edu eci@dc.uba.ar ed.jackson@dynetics.com ed@cp.tn.tudelft.nl edm@cs.purdue.edu eedjhn@eed.ericsson.se eeeugshl@cityu.edu.hk eekhaled@ee.ust.hk eenejib@ust.hk eesana@ee.ust.hk egc@reserch.bell-labs.com ege@cs.fiu.edu eglash.1@osu.edu ehab@cs.ualberta.ca eisenblaetter@zib.de ejk@lut.fi ekpark@cstp.umkc.edu ekram@ece.uvic.ca elarson@email.unc.edu elecsim_mgr@mystech.com elekocc@nus.edu.sg elelyekm@leonis.nus.edu.sg eletlj@nus.edu.sg elgindyh@cse.unsw.edu.au elias@cs.titech.ac.jp elin.wedlund@netinsight.se elin@cs.columbia.edu elkhatib@csi.uottawa.ca elleithy@bridgeport.edu ellenbgn@mitre.org elliotw@mit.edu elloyd@udel.edu elvis@npd.ufsc.br emilia@rav.sscc.ru emmett@symbi.com en04miro@overnet.com.ar enbody@cse.msu.edu end2end-interest@isi.edu endredi@ludens.elte.hu engp7450@nus.edu.sg engp7450@nus.edu.sg engp7999@leonis.nus.edu.sg enrique@bell-labs.com eoschmidt@tasc.com epage@mitre.org epatuwo@bsa3.kent.edu eraslan@mcrlab.uottawa.edu ercal@umr.edu eric@cae.ca ermel@ifn.et.tu-dresden.de erodgers@argo.cs.uwf.edu eroo@cs.ucf.edu eroyer@zeta.ece.ucsb.edu esanluis@inta.gov.ar eschmutz@mcs.drexel.edu esteban75@hotmail.com etxprjo@etxb.ericsson.se eva@cs.cornell.edu ewegman@gmu.edu eweststr@eecs.tufts.edu f4523146@ms.cc.ntu.edu.tw fabbri@cs.unt.edu faisst@cg.tuwien.ac.at fang@njit.edu fang@pads1.cs.nthu.edu.tw farago@utdallas.edu farcet@thmson_lcr.fr farooq@Glue.umd.edu farvar@eng.umd.edu fatih1@seas.gwu.edu fatih@alagoz.com fatiha.zaidi@int-evry.fr fatima.belkouch@utc.fr fayjf@eglin.af.mil fball@brookes.ac.uk fci@lri.fr fconagy@ludens.elte.hu feng@cse.psu.edu ferenci@cc.gatech.edu fernanda@lrg.ufsc.br ferrari@virginia.edu ferrie@cim.mcgill.ca ferscha@soft.uni-linz.ac.at fershad@comp.nus.edu.sg fgcarbal@inf.uc3m.es fgirs@cctmn.inatel.br fgzh@hotmail.com fhodum@dctd.saic.com filloque@univ-brest.fr firmino@decom.fee.unicamp.br fischer@acetef.nawcad.navy.mil fisher@compsci.com fisherrh@navair.navy.mil fishwick@cise.ufl.edu fj2236@se.usma.edu fkuhl@mitre.org flai@cc.ee.ntu.edu.tw fock@ert.rwth-aachen.de foglia@iet.unipi.it fontagne@laas.fr fox.ijcs@btinternet.com fox@cs.stanford.edu fp8049@se.usma.edu franchina@die.ing.uniroma1.it franci@infocom.uniroma1.it franco@dist.unige.it frank@cs.ucla.edu freebej@onr.navy.mil fsarkar@nortel.com fsdm@it.uq.edu.au fsh@nortel.com fsh@nortelnetworks.com fsilva@ics.uci.edu fujimoto@cc.gatech.edu fukami@radio.sony.co.jp fukuda@is.aist-nara.ac.jp fulvio.spagna@ti.com furm@npac.syr.edu furuichi@isl.melco.co.jp fwattenb@nsf.gov fwieland@mitre.org g-wu@crl.go.jp g.aggelou@ee.surrey.ac.uk g.fortino@unical.it g.mazzini@ieee.org gabi@ani.univie.ac.at gaetano@cs.washington.edu gagnonf@cae.ca galland@emse.fr gangdang@nudt.edu.cn garg@ece.utexas.edu gary.tan@brunel.ac.uk gaujal@sophia.inria.fr gautamd@microsoft.com gavishb@mail.cox.smu.edu gb@cis.ohio-state.edu gbundy@mitre.org gcao@cis.ohio-state.edu gcc@watson.ibm.com gcf@npac.syr.edu gchan@cs.ust.hk gcoe@ida.org geoffs@arl.mil georganas@mcrlab.uottawa.ca george.giaglis@brunel.ac.uk george@hcs.ufl.edu gerasoul@cs.rutgers.edu gerber@dfki.de gerco@cs.vu.nl gerd@cg.tuwien.ac.at gerhard.fohler.se gerla@cs.ucla.edu gfc@npac.syr.edu gfigart@logicon.com ghanem@cs.odu.edu ghchen@csie.ntu.edu.tw gholland@cs.tamu.edu gigalarc-l@di.ufpe.br gilad@airslide.com gilbert.babin@ift.ulaval.ca gimblett@nexus.srnr.arizona.edu giordano@lrc.di.epfl.ch giorgi@iet.unipi.it giovanni@us.ibm.com gkar@us.ibm.com glamm@ece.umn.edu glasmann@ei.tum.de glenv@rtimeinc.com globecom@signet.com.sig glossa@cix.compulink.co.uk glovan@fltsim.mdc.com gmani@iastate.edu gmorabi@iit.unict.it godlewski@infres.enst.fr golshani@asu.edu gomes@cpsc.ucalgary.ca gomez@mathcs.sjsu.edu gopalr@cs.uoknor.edu gopi@csa.iisc.ernet.in gordon@comp.lancs.ac.uk gourgand@ucfma.univ-bpclermont.fr goutham@utdallas.edu govind@serc.iisc.ernet.in govindan@laya.isi.edu gqiang@mcn.xidian.edu.cn gracanin@vt.edu grad@cin.ufpe.br graham.shanks@gecm.com grahul@in.ibm.com granville@inf.ufrgs.br greg_elmore@pobox.tbe.com gregorb@clear.net.nz grimaud@emse.fr gshackel@bbn.com gsharma@ececs.uc.edu gszabele@tasc.com gt@louisiana.edu gtan@comp.nus.edu.sg guckenbedj@eccic.com guha@cs.ucf.edu gunter@cs.ucla.edu gupta@cs.arizona.edu gupta@cs.colostate.edu guven@atri.curtin.edu.au guy@ist.ucf.edu gvalentino@systran.com gvasend@logicon.com gwainer@sce.carleton.ca gypsy93@netlab.korea.ac.kr gzhang@sbee.sunysb.edu h.shen@cit.gu.edu.au ha@vt.edu haahrm@wilde.cs.tcd.ie hab@ece.engr.ucf.edu habe@prism.uvsq.fr hadidi@frcu.eng.eg hafida@bill.ppc.engga.uwo.ca haifeng.wang@nokia.com haihongz@asu.edu hal@utdallas.edu halim@sce.carleton.ca hallb@cotf.navy.mil halvard@ii.uib.no hameur@irit.fr hamid@cs.odu.edu hamnes@mail.cs.umn.edu hara@ise.eng.osaka-u.ac.jp haring@ani.univie.ac.at harkrids@stricom.army.mil harmon@ati-sd.com hatzis@cti.gr havinga@cs.utwente.nl hayashi@exa.onlab.ntt.co.jp hayoon@cs.ucla.edu hbauer@newbridge.com hcarter@ececs.uc.edu hcc@cc.ndhu.edu.tw hchuang@lucent.com hclee@netlab.ce.knu.ac.kr healy@ati-sd.com hechicera_78@hotmail.com helal@cise.ufl.edu hellolix@hotmail.com hesha@krdl.org.sg hesselman@telin.nl hewitt@ai.mit.edu hgs@cs.columbia.edu hikmetsari@aol.com hipparch@sophia.inria.fr hiraki@is.s.u-tokyo.ac.jp hiromoto@jazz.cs.utsa.edu hitoshi.matsukawa@kama.melco.co.jp hkim@cs.wright.edu hlind@bvu-lads.loral.com hll@research.telcordia.com hmsyed@nortelnetworks.com hnkst5+@pitt.edu hnn@dislab.nju.edu.cn ho@almaden.ibm.com ho@almaden.ibm.com hob@scali.no hohlfeld@cs.ucsd.edu holbrook@dsg.stanford.edu holder@banzai.uta.edu hongdk@sunlight.yonsei.ac.kl hori@jaist.ac.jp horsz.besier@telekom.de hossam@cs.queensu.ca houda.labiod@prism.uvsq.fr hp@cast.uni-linz.ac.at hphu@nudt.edu.cn hpraveen@novell.com hra@cs.uga.edu hrao@fareastone.com.tw hsawaguchi@ucsd.edu hscohen@att.com hss@nmt.edu hstern@coe.eng.ua.edu hsu@murray.fordham.edu hsu@ntu.edu.sg hsu@tlaloc.sfsu.edu huajiang@nortel.com hummel@athens.dis.anl.gov hunga@aa.cs.keio.ac.jp hurwitzmm@nswccd.navy.mil hussein@eri.sci.eg hwang@disys.korea.ac.kr hxw@eecs.umich.edu hxy@cs.ucla.edu i21961@caravela.di.fc.ul.pt ian.akyildiz@ece.gatech.edu ibarra@cs.ucsb.edu ibkwan@neumann.ee.ucla.edu ibrahim@network.kuniv.edu.kw ichiro@is.ocha.ac.jp idra@intranet.gr iera@ns.ing.unirc.it ietf@isi.edu iida@cse.kyutech.ac.jp iis@hhs.se ijacobs@vt.edu ilari.welling@nokia.com illingwj@trac.nps.navy.mil imhyo@brutus.snu.ac.kr indu@andes.ee.iastate.edu informatik@ifs.univie.ac.at ingrid@cc.gatech.edu intanago@catarina.usc.edu iona@erc.msstate.edu ionut@CS.ColoState.EDU ipaprotny@pria.com iraqi@bbcr.uwaterloo.ca iraqi@iro.umontreal.ca irene@comm.toronto.edu ishields@us.ibm.com isi.mitrani@ncl.ac.uk isolis@igso.net istavrak@di.uoa.gr itc@ieee.org iuoras.a@ems-t.ca ivan@site.uottawa.ca j.baal.schem@ieee.org j.darling@surrey.ac.uk j.p.cosmas@elec.qmw.ac.uk j.p.cosmas@qmw.ac.uk j.siemer@ise.ac.uk jacm@theory.lcs.mit.edu jacob@cs.unt.edu jacquet@lirep.univ-bpclermont.fr jadm@cs.waikato.ac.nz jadran.lenarcic@ijs.si jam@cs.uga.edu jam@pollux.cs.uga.edu jamal@cse.ucsc.edu jamel@cin.ufpe.br james.hunt@bmdo.osd.mil janssen@mathstat.dal.ca jari.Porras@lut.fi jari.porras@lut.fi jarkko.sevanto@research.nokia.com jarmo.harju@cs.tut.fi jasminka@iritel.bg.ac.yu jasonliu@cs.dartmouth.edu jauvane@mcrlab.uottawa.edu javierg@comet.columbia.edu jbachman@dv.synetics.com jbarchan@sandcastle.cosc.brocku.ca jbo@prism.uvsq.fr jbo@prism.uvsq.fr jcalvin@ll.mit.edu jcguerri@dcom.upv.es jchang@alglab.sogang.ac.kr jchen@cs.gmu.edu jchen@leibniz.gmu.edu jchennik@telcordia.com jcleary@cs.waikato.ac.nz jclymer@Exchange.FULLERTON.EDU jdahmann@MSIS.dmso.mil jean.pastre@sp.isima.fr jean@odyssiasystems.com jeff.simmers@dynetics.com jeffay@cs.unc.edu jeffrey.w.wallace@att.net jens.Hartmann@comnets.rwth-aachen.de jens.hartmann@ericsson.com jenst@uni-paderborn.de jeong@nkgw.ics.keio.ac.jp jesmith@sagacitech.com jevans@ee.usyd.edu.au jfan@stanford.edu jfelez@etsii.upm.es jfladik@tasc.com jfm@cs.cmu.edu jgabbard@vpst.org jgarcia@eecis.udel.edu jgauthier@aegistg.com jgraffagnini@aegisrc.com jgthomas@arl.mil jha@cs.ucla.edu jha@inktomi.com jhiller@afit.af.mil jhorne1@cris.com jhu@eeyore.stcloudstate.edu jhummel@anl.gov jhusoy@ieee.org jhw@research.att.com jialin.ju@pnl.gov jiang@matilda.vu.edu.au jiang@research.att.com jiapei@leland.stanford.edu jibgisad@si.ehu.es jie@cse.fau.edu jikonen@lut.fi jimbob@cs.bris.ac.uk jimh@surreal.asd.sgi.com jiy@disys.korea.ac.kr jj@cse.ucsc.edu jjean@cs.wright.edu jjli@sp.isima.fr jjtsai@waikato.ac.nz jk@di.ufpe.br jkcramr@uol.com jkeller@cs.uni-sb.de jkkim@ece.arizona.edu jkuljis@roehampton.ac.uk jl24@eng.buffalo.edu jlai@winlab.edu jlauer@broadcom.com jlee@gte.com jleitao@red.lx.it.pt jlim@Eng.UA.EDU jll@ece.iit.edu jmartin@cs.ucla.edu jmccutch@colsa.com jmelas@telecom.ntua.gr jmf@prism.uvsq.fr jmisic@cs.ust.hk jmitola@mitre.org jmolero@disca.upv.es jmontagn@bic.mni.mcgill.ca jmoore@dcs.shef.ac.uk jnovak@mitre.org jocelync@nortelnetworks.com johan.zander@es.sigma.se john.Byrne@cs.tcd.ie john.fay@eglin.af.mil john.h.husoy@tn.his.no john_shockley@sri.com johns@atri.curtin.edu.au johnson@isi.edu jolee@infortel.kotel.co.kr jolee@wareplus.com jolszewski@std.saic.com jones@vmasc.odu joonsuk@isl.stanford.edu jopsi@mpi-sb.mpg.de jorg@duke.poly.edu jorge@ac.up.es jorjeta@cs.cmu.edu joscouri@Mobility.com joseph@umiacs.umd.edu joshi@cs.umbc.edu joshuap@us.ibm.com jouni.ikonen@lut.fi jozo@tlaloc.sfsu.edu jpanchal@winlab.rutgers.edu jperez@dmso.mil jredi@bbn.com jrmoorma@students.uiuc.edu jrmoorma@uiuc.edu jsancheze@lucent.com jsf@regent.e-technik.tu-muenchen.de jslee@ece.arizona.edu jss@pebbles.jpl.nasa.gov jssong@emerald.yonsei.ac.kr juan.lara@ii.uam.es juanbenigar@hotmail.com juin@cise.ufl.edu jukka.ala-mutka@siemens.fi julien.bourgeois@iut-bm.univ-fcomte.fr junyi@lucent.com jussi.lemilainen@nokia.com jwillcox@colsa.com jxavier@isr.ist.atl.pt jyiu@lucent.com k.bagchi@excite.com k_brahiti@hotmail.com kadous@cae.wisc.edu kaeli@ece.neu.edu kaj.linden@nokia.com kalyan@cc.gatech.edu kalyanas@ecn.purdue.edu kaml@cs.cmu.edu kampichw@ict.tuwien.ac.at karatza@csd.auth.gr karcenci@criba.edu.ar karen@eecs.tufts.edu karim@dcs.gla.ac.uk karthik11@email.com kats@isl.melco.co.jp kauffman@cust.univ-bpclermont.fr kaushik@sce.carleton.ca kavcic@yellowstone.hrl.harvard.edu kawahara@cse.kyutech.ac.jp kaylan@bound.edu.tr kazakos@louisiana.edu kbalakrishnan@cs.gsu.edu kbasu@nortel.ca kbisset@lanl.gov kd@cyber.reading.ac.uk ke+@cs.cmu.edu kebang@realtime.soongsil.ac.kr kelsayed@alpha1-eng.cairo.eun.eg kemple@nps.navy.mil kennedy@eurescom.de kenneth.stauffer@wpafb.af.mil kenneth.wood@foundationdt.com kenya-sato@sei.co.jp kerry@waikato.ac.nz ketan@iitd.ernet.in keyes@cs.odu.edu kfrosch@cne.gmu.edu kgshin@eecs.umich.edu kgugler@mathematik.uni-ulm.de khaled.arisha@honeywell.com khaled@ieee.org khalid@ccse.kfupm.edu.sa khcho@janet.ucla.edu khering@informatik.uni-leipzig.de khimeche@crs.etca.fr khordoc@macs.ece.mcgill.ca khuff@gte.com kia@usl.edu kienasa3@mailbox.univie.ac.at kike@iinfo.unsj.edu.ar kiko@unam.edu.ar kilgore@threadtec.com kimmo.raatikainen@cs.helsinki.fi kims@bh.kyungpook.ac.kr kinn@ece.ubc.ca kirton@signal.dra.hmg.gb klee@mail.ucf.edu klesueur@rttc.redstone.army.mil klhall@amtec-corp.com klin@ist.ucf.edu klopotek@ipipan.waw.pl kmjh@lut.fi kmorse@ics.uci.edu knop@cs.purdue.edu kochkar@yen.cse.kyutech.ac.jp kofranek@cesnet.cz kokseng@krdl.org.sg kolin@ppc.becs.ac.in konas@csrd.uiuc.edu konas@mti.sgi.com kotchano@lut.fi kris.aerts@cs.kuleuven.ac.be krish@wins.hrl.com krishna@eecs.wsu.edu krizanc@scs.carleton.ca kriznan@vt.edu krocjoe@acm.org krunz@ece.arizona.edu krw@prg.oxford.ac.uk ksalah@tellabs.com kschug@lamar.colostate.edu kscott@mitre.org ktwong@ee.cuhk.edu.hk kubbar@nortelnetworks.com kuepper@i4.informatik.rwth-aachen.de kumar@cs.curtin.edu.au kumaran@research.bell-labs.com kumova@cs.deu.edu.tr kun-mean.hou@isima.fr kurose@cs.umass.edu kuvs-elg@fokus.gmd.de kv@doe.cusat.edu kwiatk@rl.af.mil kyn@decom.fee.unicamp.br l-nardini@usa.com l.nigro@computer.org l.nigro@unical.it labra@pinon.ccu.uniovi.es lafuente@unlpin.edu.ar laik@cs.stanford.edu lalex@dmso.mil lalit@micro.iisc.ernet.in lang@cs.ucf.edu lapiotis@research.telcordia.com larcher@unse.edu.ar larguell@estec.esa.nl laszlo@itec.uni-klu.ac.at lata@cs.concordia.ca laus.Hugl@nt.tuwien.ac.at lawrn@bhaskara.ee.iisc.ernet.in lazowska@cs.washington.edu lbarroso@unsl.edu.ar lbelfore@odu.edu lbertog@uncoma.edu.ar lbirta@site.uottawa.ca lcampor@uncoma.edu.ar lcastro@criba.edu.ar lcecchi@uncoma.edu.ar lchavez@unrccc.edu.ar ldch@sunny.howon.ac.kr ldondeti@nortelnetworks.com le@it.kth.se lebeeker@grci.com leboudec@epfl.ch ledii@ciunsa.edu.ar lee@aero.org legaspi@spawar.navy.mil lelus@dist.unige.it lend@eng.buffalo.edu leonors@piemza.edu.ar lettieri@janet.ucla.edu lewis@dcs.gla.ac.uk lff@inf.ufsc.br lfoster@wod.srs.com lga@ac.up.es lia@polovale.softex.br liangah@hotmail.com lichun@research.att.com lifung@research.att.com liless@cs.nps.navy.mil limky@cs.curtin.edu.au lin@infomatik.uni-ulm.de linfd@cc.uab.es liny@csie.nctu.edu.tw liotop@cti.gr lipperts@i4.informatik.rwth-aachen.de liria@pcs.usp.br lirida.naviner@enst.fr liuay@student.dlut.edu.cn liz@smtplink.dis.anl.gov liz@uiuc.edu lj.awuah@usa.net ljubica.Blazevic@epfl.ch lk@cs.ucla.edu llacy@drc.com llee@hns.com llopez@uncoma.edu.ar llunsfor@colsa.com lmcadams@cisco.com lmcjsco@lmc.ericsson.se lmellon@std.saic.com lmorales@nortelnetworks.com ln@act.ict.ac.cn lobird@cs.nthu.edu.tw lockwood@ipoint.vlsi.uiuc.edu lombardo@iit.unict.it loper@gtri.gatech.edu lorenzo.vangelista@telital.it lorenzo@oops.nvl.army.mil lott@comnets.rwth-aachen.de lou@lucent.com loukas@di.uoa.gr lperez@unl.edu lquintas@unsl.edu.ar lrivero@tandil.edu.ar lrom@unina.it lrothroc@cs.wright.edu lrueda@iinfo.unsj.edu.ar ls6@telecom.ntua.gr lsanchez@uncoma.edu.ar lscoelho@lcmi.ufsc.br lsl@iis.sinica.edu.tw ltanco@email.ypf.com.ar lubinski@informatik.uni-rostock.de luciana@eps.ufsc.br luciod@info.unlp.edu.ar luethi@ani.univie.ac.at luethi@faust.informatik.unibw-muenchen.de luis@it.kth.se lusth@diamond.idbsu.edu lvidal@ufpaco.edu.ar lwilson@icase.edu lydia@theurgy.digex.net lyu@ca.metsci.com lzhuge@eee.hku.hk lzoroddu@groupe-progestic.com m.notare@computer.org m.pidd@lancaster.ac.uk m.scordilis@miami.edu m.underhill@surrey.ac.uk ma@cs.fsu.edu mabdalah@idsc.gov.eg mac@info.unlp.edu.ar macana@inf.utfsm.cl macconen@ees2.oulu.fi maciel@lrg-gw.lrg.ufsc.br macker@itd.nrl.navy.mil macsyste@satlink.com magister@unsl.edu.ar mahmoud@watson.ibm.com mainak@silo.csci.unt.edu maitreya@krdl.org.sg majo@info.unlp.edu.ar majumdar@sce.carleton.ca makki@fit.qut.edu.au malena@euzkadi.satlink.net malik@austin.ibm.com malony@cs.uoregon.edu mamaolo@uncoma.edu.ar manet@itd.nrl.navy.mil mani@cl.iitb.ernet.in mani@cs.caltech.edu manish@ece.iisc.ernet.in manoj@blessing.eng.umd.edu manto@nt.com.ar manuel.alfonsexa@ii.uam.es manuel.bettini@avions.aerospatiale.fr marcelo_g@usa.net marcin@orca.st.usm.edu marek@npac.syr.edu margaret.loper@gtri.gatech.edu margaret@cc.gatech.edu margos@inter1.unsl.edu.ar marian@piemza.edu.ar marias@mm.di.uoa.gr mario@scom.eaeht.eht.cu marite@iinfo.unsj.edu.ar mariza@dcc.ufmg.br mark.Baker@port.ac.uk mark.morano@wpafb.af.mil mark_Mcauliffe@stricom.army.mil marketing@opal-rt.com markhill@cs.wisc.edu markoh@cs.tut.fi markt@arl.mil marnie@mitre.org marroyo@exa.unrc.edu.ar marta@unpfce.edu.ar martig@arminco.com martina@armscor.co.za martini@cs.uni-bonn.de maruthi@cisco.com masayaki@kddlabs.co.jp matalonga@ort.ort.edu.uy mateo@ac.upc.es mateus@dcc.ufmg.br mathio@ece.ubc.ca matiasgel@hotmail.com matsbror@dit.lth.se matskp@cs.gsu.edu matskp@gsusgi1.gsu.edu matta@cs.bu.edu mattern@vs.informatik.tu-darmstadt.de mauricio.marin@comlab.ox.ac.uk mauricio@riu.edu.ar maziero@ppgia.pucpr.br mb0a@dc.uba.ar mbs@janet.ucla.edu mcaliusc@frfs.utn.edu.ar mcallaha@mitre.org mcampo@inf.ufrgs.br mcapobia@criba.edu.ar mcena@unsl.edu.ar mcfadden@mitre.org mchiani@deis.unibo.it mcrespo@inter2.unsl.edu.ar mcriff@infutfsm.cl mcyuang@csie.nctu.edu.tw mdaniele@exa.unrc.edu.ar mdans@cpsarg.com.ar mdelfres@exa.uncen.edu.ar mdelro@uncoma.edu.ar mdgrossi@mara.fi.uba.ar mdrinkwa@cas-inc.com meehan@cs.unc.edu mega@lut.fi mehdi@eng.umd.edu mehdi@mintaka.isr.umd.edu mehmet.unsoy@nortel.com meira@dcc.ufmg.br melhem@cs.pitt.edu mellon@jade.saic.com menhart@elf.stuba.sk menth@informatik.uni-wuerzburg.de merakos@di.uoa.gr merakos@di.uoa.gr merreca@unsl.edu.ar meyr@ert.rwth-aachen.de mfernand@raiz.uncu.edu.ar mflht@uxa.ecn.bgu.edu mfp@cs.cmu.edu mgbaker@cs.stanford.edu mgenero@uncoma.edu.ar mguizani@cs.uwf.edu mhd@seas.smu.edu mibuhari@ccse.kfupm.edu.sa michael.oconnr@ssc.de.ittind.com michael@teco.edu michela@pomodoro.polito.it micheld@ai.mit.edu michelg@crt.umontreal.ca michelle.chabrol@sp.isima.fr michlo@nortel.ca micke@sm.luth.se mickle@ee.pitt.edu micro@unromi.edu.ar midkiff@vt.edu mika.liljeberg@cs.helsinki.fi mika.liljeberg@research.nokia.com mike.devetsikiotis@sce.carleton.ca mike.hunsucker@afccc.af.mil mike.wesdell@cubic.com mike@sce.carelton.ca mili@it.kth.se miller_jon@bak.com milner@signal.dra.hmg.gb milner@signal.dra.hmg.gb milocco@uncoma.edu.ar mineo@CS.UCLA.EDU mingozzi@iet.unipi.it mir@regent.e-technik.tu-muenchen.de mirela@newsite.com.br miro.kraetzl@dsto.defence.gov.au misan@disca.upv.es misan@disca.upv.es misson@lirep.univ-bpclermont.fr mistral2@satlink.com mitrou@softlab.ece.ntua.gr miyajima@kama.melco.co.jp mjcorbin@dra.hmg.gb mjs@icmc.sc.usp.br mjt@serc.iisc.ernet.in mkim@mm.ewha.ac.kr mkincaid@bellatlantic.net mlago@isis.unlp.edu.ar mlb@cs.arizona.edu mlightner@aegisrc.com mlillo@exa.unrc.edu.ar mma@dmu.ac.uk mmaimour@lhpca.univ-lyon1.fr mmalek@lucent.com mmartin@inaut.unsj.edu.ar mmb@ira.uka.de mmetz@imcva.com mmjohns@ca.sandia.gov mmyjak@imtinc.com mmyjak@ist.ucf.edu mobile-ip@SMALLWORKS.COM mobile-ip@tadpole.com mogni@rionet.rionegro.com.ar moh@mathcs.sjsu.edu mohabd@alpha1-eng.cairo.eun.eg mohamed@dcs.gla.ac.uk mohamed_nezami@hotmail.com mohseni@tmcso.com monson@flightsim.mdc.com mori@mlab.t.u-tokyo.ac.jp moroni@criba.edu.ar morris@ee.uwa.edu.au mort@sol.ee.lsu.edu moshell@cs.ucf.edu mosse@cs.pitt.edu mouftah@ee.queensu.ca moustafa@ieee.org mpearson@cs.waikato.ac.nz mpetty@odu.edu mpiccoli@unsl.edu.ar mprinti@inter2.unsl.edu.ar mpullen@gmu.edu mpvs73@entelchile.net mrgalli@intec.edu.ar mroberts@colsa.com msanchez@exa.unicen.edu.ar msc@cs.mcgill.ca mshankar@scorpio.kent.edu msteenst@bbn.com mstutzman@logicon.com mtk@ece.nwu.edu mtosini@exa.unicen.edu.ar muellert@entlw7.et.tu-dresden.de multicomm@cc.bellcore.com muntean@lim.univ-mrs.fr muntz@cs.ucla.edu murthy@iitm.ernet.in mustafa@ece.concordia.ca mvc@research.att.com mwinburn@sps.com myth@diku.dk n2k-oc@comsoc.org nab@supcom.rnu.tn nacif@dcc.ufmg.br nader@ece.uci.edu nael@cs.binghamton.edu nakasima@tutics.tut.ac.jp nandy@serc.iisc.ernet.in naoumov@lut.fi narahari@seas.gwu.edu narayan@winlab.rutgers.edu nassimi@homer.njit.edu naud@virtualprototypes.ca naylor@research.att.com ncconsulting@home.com ned100@ohm.york.ac.uk nelson@research.att.com nfurment@sophia.inria.fr nfutamur@top.cis.syr.edu nguyvin@charlie.cns.iit.edu nicklas.hedman@lu.erisoft.se nicolas@usj.edu.lb nikaein@eurecom.fr nikmir@u-aizu.ac.jp nishio@ise.eng.osaka-u.ac.jp nisnarang@hss.hns.com njm@npac.syr.edu nmanjiki@ee.queensu.ca nmf-members@nmf.com nomay@seas.smu.edu nour@iro.umontreal.ca nproto@telecom.ntua.gr ntagoug@uaeu.ac.ae ntf@regent.e-technik.tu-muenchen.de nthomas@cs.unt.edu nuzman@arl.mil nweeden@dra.hmg.gb o-hollan@uwe.ac.uk obaidat@monmouth.edu ocg-info@ocg.or.at odaysc@navair.navy.mil oden-mh@redstone.army.mil oel@zzurich.ibm.com.puc-rio.br oferrall@itd.nrl.navy.mil ogielski@winlab.rutgers.edu oguztuzun@ceng.metu.edu.tr oh@cs.ucf.edu olariu@cs.odu.edu olsinal@ing.unlpam.edu.ar orcs-l@osuvm1.bitnet organizacion@info-net.com.ar orjana@acm.org oulusoy@CS.Bilkent.Edu.TR oyu@eecs.uic.edu ozaki@isl.melco.co.jp ozutam@ceng.metu.edu.tr p.buchholz@inf.tu-dresden.de p.sapaty@surrey.ac.uk padmanab@microsoft.com padua@uiuc.edu padua@uiuc.edu palazzo@iit.unict.it palis@crab.rutgers.edu pallab@cse.iitkgp.ernet.in panch@asu.edu panesar@cc.gatech.edu pang.ng@unn.ac.uk papanik@intelligencia.com papavassiliou@adm.njit.edu papka@mcs.anl.gov paredis@cmu.edu parhami@ece.ucsb.edu parsim@it.kth.se partha@asu.edu partha@dasgupta.com partho@research.att.com parva@uni-paderborn.de parvati@summit.stanford.edu parviz@us.ibm.com pas@ai.mit.edu paschoal@inf.ufrgs.br patel@crhc.uiuc.edu patersondj@navair.navy.mil paul.c.colonna@adstii.com paulan@hfl.tc.faa.gov paw@ececs.uc.edu pawelj@e-technik.uni-rostock.de payam@nortelnetworks.com pearcs@cs.rpi.edu pei@cs.ucla.edu peir@cise.ufl.edu pemi@comnets.rwth-aachen.de pengland@microsoft.com pentaris@cti.gr per.johansson@ericsson.com perev@silver.udg.es performance@haven.epm.ornl.gov performance@tay1.dec.com perkin27@cse.msu.edu perlin@cat.nyu.edu perrone@cs.wm.edu pessuresh@usa.net petbu@ida.liu.se pete.shea@dynetics.com peteh@dera.gov.uk peteh@signal.dra.hmg.gb peter.palven@es.sigma.se peter@tsinet.gr peterh@cae.ca peterson@cse.uta.edu petfr@ida.liu.se petter@ii.uib.no pflug@smc.univie.ac.at pfr@cs.virginia.edu pfr@virginia.edu pfrey@cadence.com pfrey@ece.uc.edu pg@dist.unige.it pg@iitk.ac.in pgilley@arl.mil pgrammer@triton.dmso.mil pgupta@cs.ucf.edu ph@techfak.uni-kiel.de pham@cs.ucla.edu pham@masi.ibp.fr phatak@cs.rutgers.edu phil.wilsey@uc.edu philip.wilsey@uc.edu philiph@us.ibm.com phj@triton.ucpel.tche.br pickholt@seas.gwu.edu pier@ing.unibs.it pierre.roux@alcatel.fr pierreva@ifma.ifma.fr pillai@krdl.org.sg piluc@dsi.unifi.it pinotti@iei.pi.cnr.it pissinou@cacs.usl.edu pjappine@lut.fi pkchande@mahindrabt.com pkj@netlab.korea.ac.kr plaxton@cs.utexas.edu pmanzoni@disca.upv.es pmd@work.csam.iit.edu podesta@ti.fhg.de posgrad@cin.ufpe.br pottier@univ-brest.fr power_systems@opal-rt.com prasad@cpk.auc.dk prasanna@ganges.usc.edu prashant@cs.sunysb.edu prasun@aloha.crhc.uiuc.edu pratt@cs.nps.navy.mil pratts@cs.nps.navy.mil pravin@watson.ibm.com pravinb@research.att.com prete@iet.unipi.it privman@craft.camp.clarkson.edu probst.wilfried@uqam.ca prochnow@mitre.org psameer@novell.com psj@emerald.yonsei.ac.kr psk@iitm.ernet.in psnagendra@ee.iisc.ernet.in pstath@telecom.ntua.gr psutton@spawar.navy.mil ptalbot@jntf.osd.mil pupolin@fiore.dei.unipd.it pwindyga@ist.ucf.edu pwonnacott@dra.hmg.gb qian@u-aizu.ac.jp qiao@eng.buffalo.edu qing@cs.nthu.edu.tw qinglong@cs.ust.hk quaglia@dis.uniroma1.it qzeng@ececs.uc.edu r.cherif@ttnet.tn r.pereira@livjm.ac.uk r.perrott@qub.ac.uk r.prasad@et.tudelft.nl r.tafazolli@ee.surrey.ac.uk rabbit@exa.onlab.ntt.co.jp bennybing@ieee.org mzauner@etm.at TJ@Kniveton.com Basavaraj.Patil@nokia.com charliep@iprg.nokia.com alpesh@sigma.cisco.com alpesh@cisco.com tsuntsun@isl.rdc.toshiba.co.jp bellman@aero.org neumann@wi-inf.uni-essen.de franco.zambonelli@unimo.it sjlee@hpl.hp.com rachel.mcray@cpbr.com radha@egr.msu.edu radu@eecs.umich.edu rahul@krdl.org.sg rahul@teledesic.com rainer.kroh@daimlerchrysler.com raj@cise.ufl.edu raja.neogi@tek.com rajan@physics.iisc.ernet.in rajesh@magnum.barc.ernet.in rajib@cs.curtin.edu.au rajive@cs.ucla.edu rajive@cs.ucla.edu rajkumar@csse.monash.edu.au rajkumar@dgs.monash.edu.au ralf.steinmetz@kom.tu-darmstadt.de ralph@tomtom.llnl.gov ramanan@ececs.uc.edu ramanan@rishi.serc.iisc.ernet.in ramesh@comm.utoronto.ca ramesh@cse.uta.edu ramon@research.att.com ramsey@mcrlab.uottawa.ca ranka@cise.ufl.edu rao@ece.ucsd.edu rareynolds@tasc.com rassul@comp.nus.edu.sg rassul@it.kt.se rauber@cs.uni-sb.de ravip@utdallas.edu ray.paul@brunel.ac.uk ray.smith@trw.com raziq.yaqub@nmp.nokia.com rberezdivin@fallschurch.esys.com rboutaba@bcr11.uwaterloo.ca rboutaba@nal.utoronto.ca rbriggs@virtc.com rbtan@cs.uu.nl rcarocha@ime.usp.br rcerq@inf.puc-rio.br rcohen@lucent.com rcs@icmc.sc.usp.br rdd@cc.bellcore.com rdonadio@estec.esa.nl reda@brc.uconn.edu reda@engr.uconn.edu reddy@ee.tamu.edu redlich@ccrl.nj.nec.com reeced@saic.com reedjh@vt.edu relf@signal.dra.hmg.gb rem-conf-request@es.net reres@laas.fr resd-l@sbc.org.br retvari@ttt-atm.ttt.bme.hu reynolds@cs.virginia.edu rfd@ece.engr.ucf.edu rfrances@ist.ucf.edu rgarrett@ida.org rgminder@ist.ucf.edu rhan@watson.ibm.com rhaupt@aix550.informatik.uni-leipzig.de rhc@mis.mhit.edu.tw rhr1@cornell.edu richard.keeble@brunel.ac.uk richard@b29net.bt.co.uk richards@hfl.tc.faa.gov rigo@cs.purdue.edu riley@cc.gatech.edu riley_rainey@websimulations.com rima.abifadel@fi.usj.edu.lb riso@lrg.ufsc.br risso@polito.it risso@polito.it rjb@maths.bath.ac.uk rkoblin@ia.pw.edu.pl rkumar@ee.iitd.ernet.in rlakshmi@in.ibm.com rlevitt@originalsim.com rlfreeman@tasc.com rludwig@huginn.CS.Berkeley.EDU rmielke@odu.edu rmittal@hss.hns.com roadrunnersports@roadrunnersports.net robby@infocom.ing.uniroma1.it robert.lutz@jhuapl.edu robert.macredie@brunel.ac.uk roberto@ee.uwa.edu.au robertr@it.kth.se robink@cc.gatech.edu roch.glitho@lmc.ericsson.se rod_deyo@es.com roger@ccrc.wustl.edu roger@ccrc.wustl.edu rohitg@rice.edu rolland@creol.ucf.edu roman@cs.wustl.edu roosek@nichols.com ros@regent.e-technik.tu-muenchen.de roussosg@mtry.trac.nps.navy.mil roy@ee.washington.edu roy@inrs-telecom.uquebec.ca rpainter@hq.caci.com rrao@ucsd.edu rrt@vagrant.bellcore.com rs@ecs.soton.ac.uk rsargent@syr.edu rsell@aegistg.com rsells@dese.com rsmith1@west.raytheon.com rsrikant@uiuc.edu rueme@uni-paderborn.de ruenger@cs.uni-sb.de runghung@anise.ee.cornell.edu rusj@celsiustech.se russ@erc.msstate.edu russell@dra.hmg.gb rwjs@maths.bath.ac.uk ryates@winlab.rutgers.edu ryuji@sfc.wide.ad.jp s.vahid@ee.surrey.ac.uk saday@cis.ohio-state.edu saejoon@ee.cornell.edu sahni@cise.ufl.edu sai@is.aist-nara.ac.jp sakchai@nztl.cs.gunma-u.ac.jp salki@ece.ubc.ca sampaiop@cs.man.ac.uk sampth@research.bell-labs.com sandyk@fi.edu sanjoy@nortelnetworks.com sankar@eng.usf.edu santos@cs.ucla.edu saquib@liman.Rutgers.EDU saran@cse.iitd.ernet.in sarit@research.panasonic.com sarita@icmc.sc.usp.br sasaki@amyux2.kek.jp satlas@telecom.ntua.gr savari@research.bell-labs.com sbc-l@sbc.org.br sbenbern@yahoo.com sbishop@nvl.army.mil scalo@us.ibm.com schembra@iit.unict.it schmidtm@ifn.et.tu-dresden.de schowg@stricom.army.mil schuelj@entlw7.et.tu-dresden.de schwan@cc.gatech.edu schweige@entlw7.et.tu-dresden.de scott.a.vanhoften@boeing.com scott@npac.syr.edu sczittnick@ls4.informatik.uni-dortmund.de sdas@ececs.uc.edu segarra@irisa.fr seguti@ics.uci.edu seibold@ind.uni-stuttgart.de selma.boumerdes@prism.uvsq.fr sens@src.lip6.fr senthil.sengodan@nokia.com serpanos@ee.upatras.gr servaj@volcans-ia.univ-bpclermont.fr sfaizull@paul.rutgers.edu shakkott@uiuc.edu shambhu@cse.bufallo.edu shamid@sce.carleton sharman@clarkson.edu shchoi@eecs.umich.edu sheikh@erc.msstate.edu shen@mcrlab.uottawa.ca sherif@lucent.com shervin@mcrlab.uottawa.edu shigea-t@is.aist-nara.ac.jp shiquanw@nortelnetworks.com shirazi@cse.uta.edu shiva@aries.iitm.ernet.in shkin@vt.edu sholson@tasc.com shorey@ece.iisc.ernet.in shougo-n@is.aist-nara.ac.jp showyang@csie.ndhu.edu.tw shree@cse.ucsc.edu shriver@research.bell-labs.com shroff@ecn.purdue.edu sibelius@cultura.com.br sidi@univ-valenciennes.fr sig-dsm@doc.ic.ac.uk sigmedia@bellcore.com sigmob@acm.org sigsim@acm.org simha@cs.wm.edu simmonds@cpsc.ucalgray.ca simon.taylor@brunel.ac.uk simon@cs.gmu.edu simon@cs.gmu.edu simonw@cs.ucla.edu singh@ECE.ORST.EDU singhal@cis.ohio-state.edu sivakumr@timely.crhc.uiuc.edu sivarama@scs.carleton.ca sizheng@utdallas.edu sjacobs@gte.com sjain@gintic.gov.sg sjb@ecs.soton.ac.uk sjg@cs.cmu.edu sjlee@exch.hpl.hp.com skb@ccrl.nj.nec.com skosunen@lut.fi slbaumgartner@tasc.com slpeterson@nsu.edu slu@garuda.crhc.uiuc.edu smit@cs.utwente.nl smith@dra.hmg.gb smithpm@mcmaster.ca smithr@magicnet.net smithr@modelbenders.com smjin@corp.thrunet.com smorrisn@eecs.tufts.edu solange@npd.ufsc.br somprakash.bandyopadhyay@in.pwcglobal.com soraia@dcc.ufmg.br sourav@asu.edu spalazzo@iit.unict.it speth@ert.rwth-aachen.de spirakis@cti.gr sprasad@cs.gsu.edu srajeev@in.ibm.com srikant@sambar.csl.uiuc.edu srikaya@u-aizu.ac.jp srimani@cs.clemson.edu srimani@cs.colostate.edu srini@acm.org srini@ieee.org sriram@cs.wisc.edu sriram@csa.iisc.ernet.in ss7a@virginia.edu sschmid@comp.lancs.ac.uk ssheasby@raytheon.com stanracz@netservice.com.mx stassin@telecom.ntua.gr stb@dctd.saic.com steelej@smdc.army.mil steenie@pop.ma.ultranet.com steinman@ca.metsci.com steinman@nosc.mil stekinay@megahertz.njit.edu steve.hall@lmco.com steve@atlas.ex.ac.uk steve@cdt.luth.se steve@dcs.exeter.ac.uk steve_slosser@ntsc.navy.mil stevef@cs.waikato.ac.nz stevens@mcs.anl.gov sthompson@systran.com strassbu@isg.cs.uni-magdeburg.de sturner1@ix.netcom.com subhus@cs.wm.edu sudipd@cal.vsnl.net.in sugawara@ice.uec.ac.jp sujata@icarus.lis.pitt.edu suleyman@ait.nrl.navy.mil sumit@research.telecordia.com surendar@cs.duke.edu surendar@cs.uga.edu suresh@seas.gwu.edu sven.pawletta@etechnik.uni-rostock.de sven@sto.foa.se svetha@cs.curtin.edu.au swata@isl.melco.co.jp syrotiuk@utdallas.edu szeswitz@msis.dmso.mil szucs@ttt-atm.ttt.bme.hu szymansk@cs.rpi.edu t.enderes@ieee.org taka@yrp-ktrl.co.jp takao@ccm.cl.nec.co.jp talukdar@cs.rutgers.edu tamer.khattab@alcatel.com tampakas@cti.gr tang@water.chpc.ict.ac.cn tao@research.telcordia.com tarau@cs.unt.edu tarek@science.gmu.edu taysengc@iscs.nus.edu.sg tbl@csie.nctu.edu.tw tccc@cs.umass.edu tccc@ieee.org tcwan@cs.usm.my tcwan@cs.usm.my tdahlber@uncc.edu teoym@comp.nus.edu.sg terrie@donanderson.com testnet@canarie.ca tf@par.univie.ac.at thcarter@ececs.uc.edu theorynt@vm1.nodak.edu thilo.reski@gmx.de thilo.reski@gmx.de thom@cc.gatech.edu thomas.lissajoux@utbm.fr thomas@isr.nmd.edu thudt@ztivax.zfe.siemens.de thyagu@timely.crhc.uiuc.edu tiernan@nosc.mil timoh@cc.jyu.fi tkim@eekaist/kaist.ac.kr tkkwon@mmlab.snu.ac.kr tkniola@systran.com tkuntz@sce.carleton.edu tkw@rs590.ndmc.edu.tw tmastaglio@odu.edu tmcclell@ist.ucf.edu tmoore@bvu-lads.loral.com tmoulton@eoir.com tneuberger@jtmd.abq.com to-kato@kdd.co.jp toddrepass@aol.com tokumoto@isl.melco.co.jp tolk@iabg.de tom@isg.cs.uni-magdeburg.de tony.jokikyyny@ericsson.com tony.larsson@era-t.ericsson.se tony@eng.umd.edu touch@ISI.EDU towsley@cs.umass.edu trdlicka@sun.felk.cvut.cz tripathi@cs.umn.edu tripathi@engr.ucr.edu tsai@cpsc.ucalgary.ca tsmith@paoli.atm.lmco.com tsom@us.ibm.com tstanzione@tasc.com ttanigue@fla.fujitsu.com tuahanj@cs.curtin.edu.au tuka@ise.eng.osaka-u.ac.jp tunceroren@turk.net turner@signal.dra.hmg.gb tusher@dra.hmg.gb tvrdik@sun.felk.cvut.cz twong@ece.ufl.edu tylin@csie.nctu.edu.tw tytti.varmavuo@nokia.com tzeng@cacs.usl.edu ucci@iit.edu uklein@iff.fhg.de uklein@isg.cs.uni-magdeburg.de ulana@mit.edu umesh.amin@attws.com unger@cpsc.ucalgary.ca urajasek@ececs.uc.edu urrutia@matem.unam.mx uthman@ece.concordia.ca utz@kom.tu-darmstadt.de uvarshney@gsu.edu uzun@oak.njit.edu v.melas@pobox.spbu.ru v_adimurty@vssc.org vab@isr.ist.utl.pt vahdat@cs.duke.edu vaidya@cs.tamu.edu valade@cae.ca vanecek@ipo.att.com vanhoudt@uia.ua.ac.be vanusa@cos.ufrj.br varg@eecs.berkeley.edu varghese@cs.wustl.edu varshney@cat.syr.edu vasilako@ath.forthnet.gr vass@meru.cecs.missouri.edu vassilis@ccs.neu.edu veit@rand.org vemula@cs.ucf.edu venieris@cs.ntua.gr venkat@crhc.uiuc.edu venky@utdallas.edu vergados@telecom.ntua.gr vermette@virtualprototypes.ca vernon.handley@dynetics.com vgolubic@wsmr-emh37.army.mil vicent.roy@microcell.ca victoria@csl.sri.com vijay@pine.ece.utexas.edu vilho.raisanen@nokia.com vin@cs.utexas.edu vin@cs.utexas.edu vincenzo.fiorentino@telital.it vipin@eng.wayne.edu virgilio@dcc.ufmg.br virtual@cs.tku.edu.tw vj@research.att.com vkg@rice.iit.edu vlarios@hds.utc.fr vli@eee.hku.hk vojcic@seas.gwu.edu vpholme@sandia.gov vprasad@cedt.iisc.ernet.in vsn@elefot.tsu.ru vutukury@cse.ucsc.edu vyvee@singnet.com.sg vzoi@telecom.ntua.gr w-davis@uiuc.edu w.adi@tu-bs.de wahab@cs.odu.edu wajib@infres.enst.fr walke@comnets.rwth-aachen.de walters.david@oscsystems.com walters@pc2.pc.maricopa.edu walther@ifn.et.tu-dresden.de wamsi@eng.umd.edu wan@delta.csam.iit.edu wangyongwlr@263.net wass@eecs.umich.edu wayne.pullan@dsto.defence.gov.au wcdaigle@cotton.vislab.olemiss.edu wchen@research.telcordia.com wchen@seas.smu.edu weather@mitre.org weatherly@mitre.org wei@murray.fordham.edu weihl@pa.dec.com weiping@csee.uq.edu.au wendi@mit.edu west@jade.saic.com west@jade.std.saic.com westphall@lrg.ufsc.br wetzel@mak.com wilke@ee.uwa.edu.au william.lee@zool.AirTouch.COM win@research.att.com wjliao@cc.ee.ntu.edu.tw wjohnson@darpa.mil wkatz@mak.com wkliao@top.cis.syr.edu wkuo@wiscomtech.com wlee@gte.com wli@louisiana.edu wlodek@cs.mun.ca wolisz@ee.tu-berlin.de wsmari@engr.udayton.edu wsshi@water.chpc.ict.ac.cn wsu@CS.UCLA.EDU wu@arctic.nadn.navy.mil wuerferd@wl.wpafb.af.mil wujsh@cc.ee.ntu.edu.tw wuwei@sdp.ee.tsinghua.edu.cn wwang@krdl.org.sg wwlu@ieee.org wwt@cs.wisc.edu www-security@nsmx.rutgers.edu xazzed00@stud.fee.vutbr.cz xcliu@cti.com.cn xfan@thor.ece.uc.edu xfu@gmu.edu xhafa@eng.buffalo.edu xiao@cpsc.ucalgary.ca xizhang@eecs.umich.edu xjf@dislab.nju.edu.cn xtp-relay@cs.concordia.ca xu@comnets.rwth-aachen.de xue@cs.uvm.edu xxx@ecst.csuchico.edu xxx@insa-rouen.fr y.pan@computer.org yanal@src.lip6.fr yangxiao@acm.org yavuz@eng.umd.edu ybreddy@alphao.gram.edu yctseng@csie.ncu.edu.tw yeh@engineering.ucsb.edu yener@research.bell-labs.com yew@cs.umn.edu yew@cs.umn.edu yew@csrd.uiuc.edu yfang@utdallas.edu yguo@ecs.umass.edu yhchoi@mmlab.snu.ac.kr yhkwon@ieee.org yhloh@ise.eng.osaka-u.ac.jp yhlow@gintic.gov.sg yikim@etri.re.kr yildiz@cs.unt.edu yile.guo@nokia.com yiqian@nortelnetworks.com yjc@wireless.ee.ncu.edu.tw yjsuh@postech.ac.kr ylz@research.bell-labs.com ymlam@americasm01.nt.com ymwang@research.att.com yong98@mails.tsinghua.edu.cn youn@icu.ac.kr youn@icu.ac.kr yuan880@yahoo.com yuan@cs.ucla.edu yuanyh@ece.nwu.edu yue@konan-u.ac.jp yuhlings@spawar.navy.mil yuri.kashtanov@paloma.spbu.ru yutonglu@cs.hn.cn ywang@mis.ttu.edu.tw ywh@us.ibm.com yxiao@cs.wright.edu yygang2@gmu.edu yzhu1@gmu.edu yzhul@gmu.edu yzhul@osfl.gmu.edu zakaria.maamar@drev.dnd.ca zaki@cs.rpi.edu zang@cs.ucdavis.edu zap@dist.unige.it zaruba@utdallas.edu zbrahimi@yahoo.com zeigler@ece.arizona.edu zeigler@ece.arizona.edu zhang@cs.ua.edu zhaohui@mcrlab.uottawa.ca zhengyq@sdp.ee.tsinghua.edu.cn zhzhang@cs.umn.edu zig@atri.curtin.edu.au zink@kom.tu-darmstadt.de zjh1@cornell.edu znati@cs.pitt.edu zoe.antoniou@nokia.com zomaya@ee.uwa.edu.au zorzal!eci@dc.uba.ar zorzi@cwc.ucsd.edu zsayeed@lucent.com ztang@mit.edu zubairi@cs.fredonia.edu zxu@ncic.ac.cn zyda@siggraph.org From ronyoung@nortelnetworks.com Thu Mar 1 19:13:38 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29145 for ; Thu, 1 Mar 2001 19:13:31 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 17:34:46 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 17:36:03 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id SAA08013 for ; Thu, 1 Mar 2001 18:31:38 -0500 (EST) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Thu, 1 Mar 2001 18:30:25 -0500 Received: from hosaka.smallworks.com ( [216.12.231.17]) by with SMTP (MailShield v1.5); Thu, 01 Mar 2001 18:32:05 -0500 Received: from PATH.Berkeley.EDU (PATH.Berkeley.EDU [128.32.234.234]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id RAA10433 for ; Thu, 1 Mar 2001 17:29:42 -0600 (CST) Received: from s53 (e78.RIC.Berkeley.EDU [169.229.53.157]) by PATH.Berkeley.EDU (8.9.1a/8.9.1) with SMTP id PAA22736 for ; Thu, 1 Mar 2001 15:29:41 -0800 (PST) From: "Marco Zennaro (PATH)" To: mobile-ip Subject: unsubscribe mobile-ip Date: Thu, 1 Mar 2001 15:29:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <0B61671CDB46D4118FA800508BCFF528849131@excsrv39.mayo.edu> X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: zennaro@PATH.Berkeley.EDU X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 19:47:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29950 for ; Thu, 1 Mar 2001 19:47:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22118; Thu, 1 Mar 2001 16:47:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10148; Thu, 1 Mar 2001 16:47:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f220iGF21621 for mobile-ip-dist; Thu, 1 Mar 2001 16:44:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f220i7V21614 for ; Thu, 1 Mar 2001 16:44:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21286 for ; Thu, 1 Mar 2001 16:44:07 -0800 (PST) Received: from prserv.net ([32.97.166.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20169 for ; Thu, 1 Mar 2001 16:44:07 -0800 (PST) Received: from attglobal.net (slip-32-101-120-245.il.us.prserv.net[32.101.120.245]) by prserv.net (out4) with SMTP id <2001030200440520402ni2cue>; Fri, 2 Mar 2001 00:44:05 +0000 Message-ID: <3A9EEC7C.5F4C1401@attglobal.net> Date: Thu, 01 Mar 2001 18:42:36 -0600 From: Sebastian Thalanany X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] Fast Handovers for MIPv6 - new Draft X-Priority: 1 (Highest) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, Thanks for providing an updated version of the fast handoff for mobile ipv6 draft. After reading the draft we have a few conceptual questions regarding the network determined handoff. Sorry for the delayed response(mailing list problems etc.). 1. The MIPv6 handoff draft adds most of the signaling in the critical path of handoff. Our impression is that the current proposal may not provide fast handoff support when some of the handoff message such as BU is dropped due to poor link condition. This limits the usability of the proposed scheme. We are aware that similar comments have been made in case of MIPv4 handoff discussion, but we would like to bring these points again in context of MIPv6. 2. In this draft it is evident that there are link layer dependencies that are not explicit. This is likely to obscure the methods proposed in the draft. For instance, this draft does not indicate the use of movement detection techniques for the handoff. 3. The network determined handoff method suggests that the old AR is able to predict the movement of the mobile node. This appears to be unreasonable since a network layer element cannot be expected to accurately determine the wireless link attachment of the mobile node. If the mobile node does not attach itself to the predicted new AR based on the wirless link conditions, then the signaling between the old AR and the new AR is wasted and may contribute to a loss of service, and an overall network performance degradation. 4. We believe that the link layer trigger(source or target) is available prior to the completion of a link layer handoff. For instance, in a cdma2000 based system, there are some messages sent from a source wireless access network to a target access network once the link layer handoff decision based on power management has occurred. Therfore, we recommend that options to use a generalized link layer trigger, if available, to initiate an MIPv6 handoff be included in the draft. This would allow an efficient initiation of the MIPv6 handoff signaling procedures. Regards, Sebastian and Ajoy George Tsirtsis wrote: > All, > > This was sent to the I-D directory today and should come out in a a couple > of days...in the mean time here is a sneak preview. > > This version is much improved over v00 and a lot different although the > basic ideas are the same. It is just more compact and with fewer options. > Suggestions and improvements are always very welcome. > > Comments and 'polite' flames :) on the mailing list or to any of the > co-authors if not of general interest. > > Best Regards > George (for the design team) > From ronyoung@nortelnetworks.com Thu Mar 1 21:08:48 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01481 for ; Thu, 1 Mar 2001 21:08:43 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 19:53:59 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 19:57:00 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id UAA10078 for ; Thu, 1 Mar 2001 20:49:35 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Thu, 1 Mar 2001 20:42:07 -0500 Received: from hosaka.smallworks.com ( [216.12.231.17]) by with SMTP (MailShield v1.5); Thu, 01 Mar 2001 20:43:19 -0500 Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id TAA11047 for ; Thu, 1 Mar 2001 19:41:14 -0600 (CST) Received: from gmgw06.oraclecorp.com (gmgw06.us.oracle.com [130.35.60.236]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id RAA24265 for ; Thu, 1 Mar 2001 17:41:09 -0800 (PST) Received: from oracle.com ([140.83.144.122]) by gmgw06.oraclecorp.com (8.8.8+Sun/8.8.8) with ESMTP id RAA29636 for ; Thu, 1 Mar 2001 17:41:06 -0800 (PST) Message-ID: <3A9EFB1F.CFCE9EDC@oracle.com> Date: Fri, 02 Mar 2001 08:45:03 +0700 From: Supachai X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aa Subject: unsubscribe mobile-ip Content-Type: multipart/mixed; boundary="------------8F62DFCE534F71845E3C714F" X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: mon@oracle.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.12.231.17] X-Orig: X-Orig: X-Orig: This is a multi-part message in MIME format. --------------8F62DFCE534F71845E3C714F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe mobile-ip --------------8F62DFCE534F71845E3C714F Content-Type: text/x-vcard; charset=us-ascii; name="mon.vcf" Content-Description: Card for Supachai Content-Disposition: attachment; filename="mon.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; x-mozilla-html:FALSE adr:;;;;;; version:2.1 note;quoted-printable:Eric Ryan=0D=0AOracle Corporation=0D=0ATechnical Sales Consultant - Core Technology=0D=0AInternet Sales Division, Waltham=0D=0A(617) 425-4173=0D=0Aeric.j.ryan@oracle.com=0D=0A __ __ _ __ __=0D=0A(__)|-< /-\(__ |__(-_=0D=0A=0D=0A The statements and opinions expressed here are my own and=0D=0A do not necessarily represent those of Oracle Corporation end:vcard --------------8F62DFCE534F71845E3C714F-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:28:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01964 for ; Thu, 1 Mar 2001 21:28:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16848; Thu, 1 Mar 2001 18:27:58 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25761; Thu, 1 Mar 2001 18:27:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221cND22064 for mobile-ip-dist; Thu, 1 Mar 2001 17:38:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221bIV22042 for ; Thu, 1 Mar 2001 17:37:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24189 for ; Thu, 1 Mar 2001 17:37:16 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21255 for ; Thu, 1 Mar 2001 17:37:15 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:23:36 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 12:17:26 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f213JDc18279 for seamoby-list; Wed, 28 Feb 2001 19:19:13 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f213J9o18274 for ; Wed, 28 Feb 2001 19:19:10 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id LAA197054; Thu, 1 Mar 2001 11:20:04 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01623; Wed, 28 Feb 2001 18:28:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02844; Wed, 28 Feb 2001 18:28:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f212QJu05321 for mobile-ip-dist; Wed, 28 Feb 2001 18:26:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f211xBE04716 for ; Wed, 28 Feb 2001 17:59:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26428 for ; Wed, 28 Feb 2001 17:42:18 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11001 for ; Wed, 28 Feb 2001 17:42:18 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f211g7g18040 for ; Wed, 28 Feb 2001 19:42:17 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Feb 2001 19:42:07 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Feb 2001 19:42:07 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 19:42:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, Comments inline: >Hi Raj, > >>Phil, >> >>I do not see anyone saying that Mobile IP is the only solution for all >>scenarios that require mobility. I am sure there are many scenarios >>that Mobile IP may or may not be the most optimal solution. If Mobile >>IP is unable to work as well as anything else you may have in mind >>for specific scenarios, then why deploy Mobile IP in such scenarios? > >Then where might these other solutions be standardized in the IETF? Seamoby??? Some other WG (MANET, Mobile IP, New WG)? Or is it the IRTF that Do these kind of scenarios and problems get covered in the mobility management problems statement I-D? If you believe this kind of mobility currently does not have a WG in the IETF that deals with it, then maybe that's what Seamoby should do. >Would this fall under the classification of micro-mobility even though >the "so-called" COA or routing prefix does indeed change? I guess what >I am getting at is there may be cases of infra-structure-less mobility >where the COA changes but there is no HA. Would this be micro or >macro mobility? > The terms micro and macro mobility are overloaded and perceptions are different w.r.t where micro mobility ends and macro mobility begins. The non-existence of an HA has no implications on whether you are dealing with micro or macro mobility. I mean do you consider macro mobility as only those cases wherein the MN sends a binding update to the HA? >>Can you be more specific on the kind of environments and requirements >>that these environments have that would make it impossible for Mobile >>IP to work in. > >Sure. Specifically, I am very interested in portable devices that will >find there way into homes. Wireless appliances, MP3 players, digital >radios, digital security devices, gaming units, VoIP devices, etc. I >am also interested in these types of devices that may be used in small >to medium business that may not have large infrastructures in place. > Is there any limitation in terms of having Mobile IP support for such devices? And why would you not be able to have Mobile IP in whatever infrastructure exists (either in the home network or the small business)? Are you concerned with the fact that if you have Mobile IP, then you need an HA at the least (in the case of IPv6)? >Thank you, > >Phil Neumiller > Regards, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:33:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02117 for ; Thu, 1 Mar 2001 21:33:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19287; Thu, 1 Mar 2001 18:32:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24398; Thu, 1 Mar 2001 18:32:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221bOh22044 for mobile-ip-dist; Thu, 1 Mar 2001 17:37:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221aOV22007 for ; Thu, 1 Mar 2001 17:36:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12907 for ; Thu, 1 Mar 2001 17:36:23 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from m018.com ([210.112.11.138]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22568 for ; Thu, 1 Mar 2001 17:36:21 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:10 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 11:29:46 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f212Wx518137 for seamoby-list; Wed, 28 Feb 2001 18:32:59 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f212Wuo18132 for ; Wed, 28 Feb 2001 18:32:56 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f211gVg18072 for ; Wed, 28 Feb 2001 19:42:31 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Feb 2001 19:42:07 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Feb 2001 19:42:07 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 19:42:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, Comments inline: >Hi Raj, > >>Phil, >> >>I do not see anyone saying that Mobile IP is the only solution for all >>scenarios that require mobility. I am sure there are many scenarios >>that Mobile IP may or may not be the most optimal solution. If Mobile >>IP is unable to work as well as anything else you may have in mind >>for specific scenarios, then why deploy Mobile IP in such scenarios? > >Then where might these other solutions be standardized in the IETF? Seamoby??? Some other WG (MANET, Mobile IP, New WG)? Or is it the IRTF that Do these kind of scenarios and problems get covered in the mobility management problems statement I-D? If you believe this kind of mobility currently does not have a WG in the IETF that deals with it, then maybe that's what Seamoby should do. >Would this fall under the classification of micro-mobility even though >the "so-called" COA or routing prefix does indeed change? I guess what >I am getting at is there may be cases of infra-structure-less mobility >where the COA changes but there is no HA. Would this be micro or >macro mobility? > The terms micro and macro mobility are overloaded and perceptions are different w.r.t where micro mobility ends and macro mobility begins. The non-existence of an HA has no implications on whether you are dealing with micro or macro mobility. I mean do you consider macro mobility as only those cases wherein the MN sends a binding update to the HA? >>Can you be more specific on the kind of environments and requirements >>that these environments have that would make it impossible for Mobile >>IP to work in. > >Sure. Specifically, I am very interested in portable devices that will >find there way into homes. Wireless appliances, MP3 players, digital >radios, digital security devices, gaming units, VoIP devices, etc. I >am also interested in these types of devices that may be used in small >to medium business that may not have large infrastructures in place. > Is there any limitation in terms of having Mobile IP support for such devices? And why would you not be able to have Mobile IP in whatever infrastructure exists (either in the home network or the small business)? Are you concerned with the fact that if you have Mobile IP, then you need an HA at the least (in the case of IPv6)? >Thank you, > >Phil Neumiller > Regards, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:39:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03076 for ; Thu, 1 Mar 2001 21:39:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22465; Thu, 1 Mar 2001 18:39:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25633; Thu, 1 Mar 2001 18:38:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221b8V22039 for mobile-ip-dist; Thu, 1 Mar 2001 17:37:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221aGV21982 for ; Thu, 1 Mar 2001 17:36:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12879 for ; Thu, 1 Mar 2001 17:36:17 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA12663 for ; Thu, 1 Mar 2001 18:36:16 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:37 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 03:18:01 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f21IQuG21190 for seamoby-list; Thu, 1 Mar 2001 10:26:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from eagle.aud.alcatel.com (host60d9.alcatel.com [128.251.96.217]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f21IQro21185 for ; Thu, 1 Mar 2001 10:26:53 -0800 Received: from mswitch.aud.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA18139; Thu, 1 Mar 2001 11:36:24 -0600 (CST) Received: from usa.alcatel.com by mswitch.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA14127; Thu, 1 Mar 2001 11:36:22 -0600 (CST) Message-ID: <3A9E8895.DD789091@usa.alcatel.com> Date: Thu, 01 Mar 2001 11:36:21 -0600 From: Behcet Sarikaya X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Raj and Phil, I think the critical question for micromobility (mm) branch of the Seamoby WG is to be or not to be, i.e. whether another routing protocol for mobility is required. Presently we have the MIP and the Manet routing approaches. The alternative seems to be per-host routes or host-based routing. I do not think there has been another breakthrough proposal significantly different. We all know Cellular IP and Hawaii proposals. Recently there is probably another one based on extending OSPF with host-based routes. Of course there are a lot of details but I think this is the crux of Seamoby mm problem. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:43:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03135 for ; Thu, 1 Mar 2001 21:43:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24538; Thu, 1 Mar 2001 18:43:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26698; Thu, 1 Mar 2001 18:42:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221bcc22051 for mobile-ip-dist; Thu, 1 Mar 2001 17:37:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221aKV21994 for ; Thu, 1 Mar 2001 17:36:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12891 for ; Thu, 1 Mar 2001 17:36:20 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA12685 for ; Thu, 1 Mar 2001 18:36:18 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:25 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 12:50:22 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f213hqC18378 for seamoby-list; Wed, 28 Feb 2001 19:43:52 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f213hno18372 for ; Wed, 28 Feb 2001 19:43:50 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id LAA138982; Thu, 1 Mar 2001 11:44:44 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24652; Wed, 28 Feb 2001 18:53:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29100; Wed, 28 Feb 2001 18:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1SNpjs03679 for mobile-ip-dist; Wed, 28 Feb 2001 15:51:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1SNj2E03460 for ; Wed, 28 Feb 2001 15:45:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01426 for ; Wed, 28 Feb 2001 14:39:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15276 for ; Wed, 28 Feb 2001 14:39:30 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SMdNC29492 for ; Wed, 28 Feb 2001 23:39:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 23:39:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 23:35:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 23:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Phil, > > > >I do not see anyone saying that Mobile IP is the only solution for all > >scenarios that require mobility. I am sure there are many scenarios > >that Mobile IP may or may not be the most optimal solution. If Mobile > >IP is unable to work as well as anything else you may have in mind > >for specific scenarios, then why deploy Mobile IP in such scenarios? > > Then where might these other solutions be standardized in the IETF? > Would this fall under the classification of micro-mobility even though > the "so-called" COA or routing prefix does indeed change? I guess what > I am getting at is there may be cases of infra-structure-less mobility > where the COA changes but there is no HA. > => There was a draft presented in San Diego about Homeless MIPv6. Just an example and I'm not trying to force MIP. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:44:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03152 for ; Thu, 1 Mar 2001 21:44:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20066; Thu, 1 Mar 2001 18:44:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29702; Thu, 1 Mar 2001 18:44:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221bdt22052 for mobile-ip-dist; Thu, 1 Mar 2001 17:37:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221aNV22004 for ; Thu, 1 Mar 2001 17:36:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15015 for ; Thu, 1 Mar 2001 17:36:22 -0800 (PST) Received: from m018.com ([210.112.11.138]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22560 for ; Thu, 1 Mar 2001 17:36:20 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:12 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 11:56:08 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f213A8a18244 for seamoby-list; Wed, 28 Feb 2001 19:10:08 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f2139To18239 for ; Wed, 28 Feb 2001 19:09:30 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id LAA229112; Thu, 1 Mar 2001 11:10:23 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02460; Wed, 28 Feb 2001 18:18:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01216; Wed, 28 Feb 2001 18:17:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1SNpjs03679 for mobile-ip-dist; Wed, 28 Feb 2001 15:51:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1SNj2E03460 for ; Wed, 28 Feb 2001 15:45:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01426 for ; Wed, 28 Feb 2001 14:39:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15276 for ; Wed, 28 Feb 2001 14:39:30 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SMdNC29492 for ; Wed, 28 Feb 2001 23:39:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 23:39:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 23:35:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 23:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Phil, > > > >I do not see anyone saying that Mobile IP is the only solution for all > >scenarios that require mobility. I am sure there are many scenarios > >that Mobile IP may or may not be the most optimal solution. If Mobile > >IP is unable to work as well as anything else you may have in mind > >for specific scenarios, then why deploy Mobile IP in such scenarios? > > Then where might these other solutions be standardized in the IETF? > Would this fall under the classification of micro-mobility even though > the "so-called" COA or routing prefix does indeed change? I guess what > I am getting at is there may be cases of infra-structure-less mobility > where the COA changes but there is no HA. > => There was a draft presented in San Diego about Homeless MIPv6. Just an example and I'm not trying to force MIP. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:52:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03261 for ; Thu, 1 Mar 2001 21:52:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28136; Thu, 1 Mar 2001 18:51:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01417; Thu, 1 Mar 2001 18:51:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221bFa22040 for mobile-ip-dist; Thu, 1 Mar 2001 17:37:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221aIV21989 for ; Thu, 1 Mar 2001 17:36:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23905 for ; Thu, 1 Mar 2001 17:36:18 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27047 for ; Thu, 1 Mar 2001 17:36:17 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:36 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 03:08:02 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f21IVA121233 for seamoby-list; Thu, 1 Mar 2001 10:31:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f21IV7o21228 for ; Thu, 1 Mar 2001 10:31:07 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id CAA74944; Fri, 2 Mar 2001 02:32:03 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18709; Thu, 1 Mar 2001 09:38:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00081; Thu, 1 Mar 2001 09:38:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f21Hag316488 for mobile-ip-dist; Thu, 1 Mar 2001 09:36:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f21HaXV16481 for ; Thu, 1 Mar 2001 09:36:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29691 for ; Thu, 1 Mar 2001 09:36:32 -0800 (PST) Received: from eagle.aud.alcatel.com (host60d9.alcatel.com [128.251.96.217]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00342 for ; Thu, 1 Mar 2001 09:36:32 -0800 (PST) Received: from mswitch.aud.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA18139; Thu, 1 Mar 2001 11:36:24 -0600 (CST) Received: from usa.alcatel.com by mswitch.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA14127; Thu, 1 Mar 2001 11:36:22 -0600 (CST) Message-ID: <3A9E8895.DD789091@usa.alcatel.com> Date: Thu, 01 Mar 2001 11:36:21 -0600 From: Behcet Sarikaya X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Raj and Phil, I think the critical question for micromobility (mm) branch of the Seamoby WG is to be or not to be, i.e. whether another routing protocol for mobility is required. Presently we have the MIP and the Manet routing approaches. The alternative seems to be per-host routes or host-based routing. I do not think there has been another breakthrough proposal significantly different. We all know Cellular IP and Hawaii proposals. Recently there is probably another one based on extending OSPF with host-based routes. Of course there are a lot of details but I think this is the crux of Seamoby mm problem. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 21:55:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03311 for ; Thu, 1 Mar 2001 21:55:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22418; Thu, 1 Mar 2001 18:55:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00404; Thu, 1 Mar 2001 18:55:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221hcn22199 for mobile-ip-dist; Thu, 1 Mar 2001 17:43:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221f4V22098 for ; Thu, 1 Mar 2001 17:41:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16289 for ; Thu, 1 Mar 2001 17:41:03 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28719 for ; Thu, 1 Mar 2001 17:41:02 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:26:41 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 08:29:48 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1SNTv017427 for seamoby-list; Wed, 28 Feb 2001 15:29:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1SNToo17422 for ; Wed, 28 Feb 2001 15:29:50 -0800 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SMdNC29486 for ; Wed, 28 Feb 2001 23:39:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 23:39:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 23:35:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 23:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Phil, > > > >I do not see anyone saying that Mobile IP is the only solution for all > >scenarios that require mobility. I am sure there are many scenarios > >that Mobile IP may or may not be the most optimal solution. If Mobile > >IP is unable to work as well as anything else you may have in mind > >for specific scenarios, then why deploy Mobile IP in such scenarios? > > Then where might these other solutions be standardized in the IETF? > Would this fall under the classification of micro-mobility even though > the "so-called" COA or routing prefix does indeed change? I guess what > I am getting at is there may be cases of infra-structure-less mobility > where the COA changes but there is no HA. > => There was a draft presented in San Diego about Homeless MIPv6. Just an example and I'm not trying to force MIP. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 22:08:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03477 for ; Thu, 1 Mar 2001 22:08:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05606; Thu, 1 Mar 2001 19:08:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06346; Thu, 1 Mar 2001 19:07:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221h9u22189 for mobile-ip-dist; Thu, 1 Mar 2001 17:43:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221fEV22107 for ; Thu, 1 Mar 2001 17:41:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14039 for ; Thu, 1 Mar 2001 17:41:14 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28798 for ; Thu, 1 Mar 2001 17:41:13 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:26:45 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 12:28:08 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f213YnU18332 for seamoby-list; Wed, 28 Feb 2001 19:34:49 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f213Yko18327 for ; Wed, 28 Feb 2001 19:34:46 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id LAA155158; Thu, 1 Mar 2001 11:35:37 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19021; Wed, 28 Feb 2001 18:43:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25834; Wed, 28 Feb 2001 18:43:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1SNpjs03679 for mobile-ip-dist; Wed, 28 Feb 2001 15:51:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1SNj2E03460 for ; Wed, 28 Feb 2001 15:45:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01426 for ; Wed, 28 Feb 2001 14:39:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15276 for ; Wed, 28 Feb 2001 14:39:30 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SMdNC29492 for ; Wed, 28 Feb 2001 23:39:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 23:39:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 23:35:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 23:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Phil, > > > >I do not see anyone saying that Mobile IP is the only solution for all > >scenarios that require mobility. I am sure there are many scenarios > >that Mobile IP may or may not be the most optimal solution. If Mobile > >IP is unable to work as well as anything else you may have in mind > >for specific scenarios, then why deploy Mobile IP in such scenarios? > > Then where might these other solutions be standardized in the IETF? > Would this fall under the classification of micro-mobility even though > the "so-called" COA or routing prefix does indeed change? I guess what > I am getting at is there may be cases of infra-structure-less mobility > where the COA changes but there is no HA. > => There was a draft presented in San Diego about Homeless MIPv6. Just an example and I'm not trying to force MIP. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 22:32:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04791 for ; Thu, 1 Mar 2001 22:32:48 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15540; Thu, 1 Mar 2001 19:32:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10615; Thu, 1 Mar 2001 19:32:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f222rco24946 for mobile-ip-dist; Thu, 1 Mar 2001 18:53:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f222o0V24854 for ; Thu, 1 Mar 2001 18:50:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25321 for ; Thu, 1 Mar 2001 17:43:28 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16161 for ; Thu, 1 Mar 2001 18:43:27 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:27:56 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 04:33:23 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f21IrYS21292 for seamoby-list; Thu, 1 Mar 2001 10:53:34 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f21IrVo21287 for ; Thu, 1 Mar 2001 10:53:31 -0800 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14049; Thu, 1 Mar 2001 10:03:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV01622; Thu, 1 Mar 2001 10:02:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28818; Thu, 1 Mar 2001 10:02:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15006.36559.662301.41126@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 10:02:55 -0800 (PST) To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: Re: [seamoby] Arch discussions in IETF In-Reply-To: <3A9E8895.DD789091@usa.alcatel.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> <3A9E8895.DD789091@usa.alcatel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think this quite captures the finesse on the issue. I don't believe that the proper framing of the question is whether a new routing protocol needs to be invented or not: it may very well be that there is nothing to be done on the _routing protocol_ front to support injecting host routes if that's the ultimate solution. There may be work needed to support _signaling_ a router that it needs to change how a subnet is reachable. I know this is hair splitting, but I think it's important to separate out that it's quite possible that the heavy lifting can already be done by current protocols, and that all we need is the ability to trigger them to happen. You might call that a "routing protocol" too, but it ought not evoke the fear and loathing that postulating a Routing Protocol should. MIke Behcet Sarikaya writes: > Hi Raj and Phil, > > I think the critical question for micromobility (mm) branch of the > Seamoby WG is > to be or not to be, i.e. > whether another routing protocol for mobility is required. Presently we > have the MIP and > the Manet routing approaches. > The alternative seems to be per-host routes or host-based routing. I do > not think there > has been another breakthrough proposal significantly different. We all know > Cellular IP and > Hawaii proposals. Recently there is probably another one based on extending > OSPF with > host-based routes. > Of course there are a lot of details but I think this is the crux of > Seamoby mm problem. > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 1 22:34:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04839 for ; Thu, 1 Mar 2001 22:34:09 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16238; Thu, 1 Mar 2001 19:33:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14593; Thu, 1 Mar 2001 19:33:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f221h9u22189 for mobile-ip-dist; Thu, 1 Mar 2001 17:43:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f221fEV22107 for ; Thu, 1 Mar 2001 17:41:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14039 for ; Thu, 1 Mar 2001 17:41:14 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28798 for ; Thu, 1 Mar 2001 17:41:13 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:26:45 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 12:28:08 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f213YnU18332 for seamoby-list; Wed, 28 Feb 2001 19:34:49 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f213Yko18327 for ; Wed, 28 Feb 2001 19:34:46 -0800 Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id LAA155158; Thu, 1 Mar 2001 11:35:37 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19021; Wed, 28 Feb 2001 18:43:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25834; Wed, 28 Feb 2001 18:43:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1SNpjs03679 for mobile-ip-dist; Wed, 28 Feb 2001 15:51:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1SNj2E03460 for ; Wed, 28 Feb 2001 15:45:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01426 for ; Wed, 28 Feb 2001 14:39:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15276 for ; Wed, 28 Feb 2001 14:39:30 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SMdNC29492 for ; Wed, 28 Feb 2001 23:39:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 23:39:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 23:35:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 23:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Phil, > > > >I do not see anyone saying that Mobile IP is the only solution for all > >scenarios that require mobility. I am sure there are many scenarios > >that Mobile IP may or may not be the most optimal solution. If Mobile > >IP is unable to work as well as anything else you may have in mind > >for specific scenarios, then why deploy Mobile IP in such scenarios? > > Then where might these other solutions be standardized in the IETF? > Would this fall under the classification of micro-mobility even though > the "so-called" COA or routing prefix does indeed change? I guess what > I am getting at is there may be cases of infra-structure-less mobility > where the COA changes but there is no HA. > => There was a draft presented in San Diego about Homeless MIPv6. Just an example and I'm not trying to force MIP. Regards, Hesham From ronyoung@nortelnetworks.com Thu Mar 1 23:04:14 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05356 for ; Thu, 1 Mar 2001 23:04:14 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 21:50:01 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 21:53:02 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id WAA11832 for ; Thu, 1 Mar 2001 22:45:20 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Thu, 1 Mar 2001 22:49:02 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 22:44:56 -0500 Received: from hotmail.com (f7.law11.hotmail.com [64.4.17.7]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id VAA11655 for ; Thu, 1 Mar 2001 21:44:54 -0600 (CST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Mar 2001 19:44:23 -0800 Received: from 24.24.218.5 by lw11fd.law11.hotmail.msn.com with HTTP; Fri, 02 Mar 2001 03:44:23 GMT X-Originating-IP: [24.24.218.5] From: Mark DuVall To: mobile-ip@smallworks.com Subject: Re: unsubscribe mobile-ip Date: Thu, 01 Mar 2001 19:44:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Mar 2001 03:44:23.0937 (UTC) FILETIME=[12887F10:01C0A2CB] X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: duvallmark@hotmail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: unsubscribe mobile-ip _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ronyoung@nortelnetworks.com Thu Mar 1 23:20:58 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05561 for ; Thu, 1 Mar 2001 23:20:58 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 22:07:14 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 22:09:49 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id XAA12122 for ; Thu, 1 Mar 2001 23:04:21 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Thu, 1 Mar 2001 23:03:21 -0500 Received: from hosaka.smallworks.com ( [216.12.231.17]) by with SMTP (MailShield v1.5); Thu, 01 Mar 2001 23:04:32 -0500 Received: from attila.stevens-tech.edu (root@attila.stevens-tech.edu [155.246.14.11]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA11745 for ; Thu, 1 Mar 2001 22:02:42 -0600 (CST) Received: from pino (p13.slip.stevens-tech.edu [155.246.189.33]) by attila.stevens-tech.edu (SGI-8.9.3/8.9.3/7) with SMTP id XAA03590 for ; Thu, 1 Mar 2001 23:02:39 -0500 (EST) From: Zhongren Arnold Cao To: mobile-ip Subject: unsubscribe mobile-ip Date: Thu, 1 Mar 2001 23:04:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: zrcao@bigfoot.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Thu Mar 1 23:37:02 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06028 for ; Thu, 1 Mar 2001 23:36:57 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 22:23:22 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 22:25:48 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id XAA12318 for ; Thu, 1 Mar 2001 23:20:11 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Thu, 1 Mar 2001 20:18:53 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 20:22:06 -0800 Received: from hotmail.com (f179.law9.hotmail.com [64.4.9.179]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA11876 for ; Thu, 1 Mar 2001 22:19:55 -0600 (CST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Mar 2001 20:19:24 -0800 Received: from 143.183.152.10 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 02 Mar 2001 04:19:24 GMT X-Originating-IP: [143.183.152.10] From: Subas Bastola To: mobile-ip@smallworks.com Subject: unsubscribe mobile-ip Date: Fri, 02 Mar 2001 10:04:24 +0545 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Mar 2001 04:19:24.0965 (UTC) FILETIME=[F6D7ED50:01C0A2CF] X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: subas_bastola@hotmail.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: unsubscribe mobile-ip _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From ronyoung@nortelnetworks.com Fri Mar 2 00:14:19 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06597 for ; Fri, 2 Mar 2001 00:14:19 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 22:56:16 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 22:58:39 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id XAA12728 for ; Thu, 1 Mar 2001 23:52:33 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Thu, 1 Mar 2001 23:52:26 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 23:52:25 -0500 Received: from fsnt.future.futsoft.com ([203.197.140.35]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA12000 for ; Thu, 1 Mar 2001 22:52:23 -0600 (CST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 02 Mar 2001 10:28:06 +0530 Received: from prachimp (prachimp.future.futsoft.com [10.0.40.11]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f22APoc10481 for ; Fri, 2 Mar 2001 15:55:50 +0530 Reply-To: prachimp From: Prachi Pande To: mobile-ip Subject: unsubscribe mobile-ip Date: Fri, 2 Mar 2001 10:21:47 +0530 Message-Id: <000c01c0a2d4$7d9ecee0$0b28000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: prachimp@future.futsoft.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit From ronyoung@nortelnetworks.com Fri Mar 2 00:56:17 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07298 for ; Fri, 2 Mar 2001 00:56:17 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 23:34:47 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 23:33:13 -0600 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id AAA13160 for ; Fri, 2 Mar 2001 00:25:44 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s001.baynetworks.com; Thu, 1 Mar 2001 21:19:09 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 21:25:07 -0800 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id XAA12182 for ; Thu, 1 Mar 2001 23:25:20 -0600 (CST) Received: from mkiranntpc ([192.122.174.30]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA05966 for ; Fri, 2 Mar 2001 10:54:36 +0530 (IST) Message-ID: <127a01c0a2d9$834f2920$1eae7ac0@cisco.com> From: "M.Sreenivasa Kiran" To: mobile-ip References: Date: Fri, 2 Mar 2001 10:53:03 +0530 Organization: HCL CISCO ODC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: mkiran@cisco.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobileip From ronyoung@nortelnetworks.com Fri Mar 2 00:56:19 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07315 for ; Fri, 2 Mar 2001 00:56:18 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 1 Mar 2001 23:44:49 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 1 Mar 2001 23:33:10 -0600 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id AAA13157 for ; Fri, 2 Mar 2001 00:25:43 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s001.baynetworks.com; Thu, 1 Mar 2001 21:19:09 -0800 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 01 Mar 2001 21:25:07 -0800 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id XAA12183 for ; Thu, 1 Mar 2001 23:25:21 -0600 (CST) Received: from mkiranntpc ([192.122.174.30]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA05972 for ; Fri, 2 Mar 2001 10:54:36 +0530 (IST) Message-ID: <127b01c0a2d9$83726890$1eae7ac0@cisco.com> From: "M.Sreenivasa Kiran" To: mobile-ip References: Subject: Re: unsubscribe mobile-ip Date: Fri, 2 Mar 2001 10:53:45 +0530 Organization: HCL CISCO ODC MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: mkiran@cisco.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Fri Mar 2 01:47:20 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11956 for ; Fri, 2 Mar 2001 01:47:18 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 00:16:03 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 00:13:18 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id BAA13915 for ; Fri, 2 Mar 2001 01:07:52 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Fri, 2 Mar 2001 01:07:43 -0500 Received: from fsnt.future.futsoft.com ( [203.197.140.35]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 01:07:42 -0500 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 02 Mar 2001 11:44:00 +0530 Received: from shankarv (shankarv.future.futsoft.com [10.0.14.15]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f22Bfic16042 for ; Fri, 2 Mar 2001 17:11:45 +0530 Reply-To: shankarv From: Shankar V To: mobile-ip@marvin.corpeast.baynetworks.com Subject: Pls. dont send the subscribe/unsubscribe commands to the list.. ID. send ur commands to MAJORDOMO or LISTSERV which ever is the software for this list Date: Fri, 2 Mar 2001 11:35:28 +0530 Message-Id: <000d01c0a2de$c9999960$0f0e000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: fsnt.future.futsoft.com X-SMTP-MAIL-FROM: shankarv@future.futsoft.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [203.197.140.35] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit My inbox is flooded with such mails From ronyoung@nortelnetworks.com Fri Mar 2 01:54:32 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11955 for ; Fri, 2 Mar 2001 01:47:18 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 00:16:03 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 00:13:21 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id BAA13900 for ; Fri, 2 Mar 2001 01:06:40 -0500 (EST) Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com; Fri, 2 Mar 2001 01:04:25 -0500 Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 01:06:33 -0500 Received: from PATH.Berkeley.EDU (PATH.Berkeley.EDU [128.32.234.234]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA12415 for ; Fri, 2 Mar 2001 00:06:31 -0600 (CST) Received: from s53 (e78.RIC.Berkeley.EDU [169.229.53.157]) by PATH.Berkeley.EDU (8.9.1a/8.9.1) with SMTP id WAA09594 for ; Thu, 1 Mar 2001 22:06:30 -0800 (PST) From: "Marco Zennaro (PATH)" To: mobile-ip Subject: unsubscribe mobile-ip Date: Thu, 1 Mar 2001 22:06:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000c01c0a2d4$7d9ecee0$0b28000a@future.futsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: zennaro@PATH.Berkeley.EDU X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: hosaka.SmallWorks.COM [192.207.126.1] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit Please remove me from the mailing list. This is my 5th message. Thanks, Marco Zennaro From ronyoung@nortelnetworks.com Fri Mar 2 02:09:48 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21947 for ; Fri, 2 Mar 2001 02:09:48 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 00:35:32 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 00:37:04 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14160 for ; Fri, 2 Mar 2001 01:31:05 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Fri, 2 Mar 2001 01:30:40 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 01:30:39 -0500 Received: from aries.starnet.gov.sg ([203.116.59.243]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id AAA12570 for ; Fri, 2 Mar 2001 00:30:36 -0600 (CST) Received: from dell (dialup-8.starnet.gov.sg [172.16.140.8]) by aries.starnet.gov.sg (8.11.0/8.10.1) with SMTP id f226ToV06816 for ; Fri, 2 Mar 2001 14:29:50 +0800 Message-ID: <001d01c0a2e4$7c98b640$088c10ac@dell> From: Brenda To: mobile-ip References: Subject: unsubscribe mobile-ip Date: Fri, 2 Mar 2001 14:46:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: ybrenda@starnet.gov.sg X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Fri Mar 2 02:24:31 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21948 for ; Fri, 2 Mar 2001 02:09:48 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 00:35:33 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 00:34:15 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14110 for ; Fri, 2 Mar 2001 01:27:52 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Fri, 2 Mar 2001 01:27:42 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 01:27:41 -0500 Received: from tmosmtp.turkcell.com.tr (tmoexh3.turkcell.com.tr [212.58.18.132]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id AAA12564 for ; Fri, 2 Mar 2001 00:27:36 -0600 (CST) Received: by TMOEXH3 with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 08:25:17 +0200 Message-ID: From: "ALI OZDEMIR (NP-NS)" To: "'mobile-ip@smallworks.com'" Subject: unsubscribe Date: Fri, 2 Mar 2001 08:26:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-9" X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: ali.ozdemir@turkcell.com.tr X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: *************************************************************************** This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited. The opinions expressed in this message belong to sender alone. There is no implied endorsement by TURKCELL. This e-mail has been scanned for all known computer viruses. *************************************************************************** From ronyoung@nortelnetworks.com Fri Mar 2 02:57:23 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23035 for ; Fri, 2 Mar 2001 02:57:22 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 01:42:14 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 01:45:21 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id CAA15128 for ; Fri, 2 Mar 2001 02:39:17 -0500 (EST) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Fri, 2 Mar 2001 02:37:11 -0500 Received: from hosaka.smallworks.com ( [216.12.231.17]) by with SMTP (MailShield v1.5); Fri, 02 Mar 2001 02:38:46 -0500 Received: from n13.sp.op.dlr.de (gw.sp.op.dlr.de [129.247.188.16]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA12854 for ; Fri, 2 Mar 2001 01:36:29 -0600 (CST) Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n13.sp.op.dlr.de (8.10.1/8.10.1) with ESMTP id f227aL080428 for ; Fri, 2 Mar 2001 08:36:21 +0100 Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by zeus.nt.op.dlr.de (8.9.3+Sun/8.9.1) with ESMTP id IAA07973 for ; Fri, 2 Mar 2001 08:36:06 +0100 (MET) Message-ID: <3A9F4D73.2500AB85@zeus.nt.op.dlr.de> Date: Fri, 02 Mar 2001 08:36:20 +0100 From: Matteo Berioli Reply-To: mberio@libero.it X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@smallworks.com Subject: unsubscribe mobile-ip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: berioli@zeus.nt.op.dlr.de X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.12.231.17] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Fri Mar 2 03:47:23 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23616 for ; Fri, 2 Mar 2001 03:47:23 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 02:29:25 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 02:32:22 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id DAA21833 for ; Fri, 2 Mar 2001 03:26:02 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Fri, 2 Mar 2001 00:24:35 -0800 Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 00:27:53 -0800 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Mar 2001 09:25:39 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201931428@lat3721.lannion.cnet.fr> From: AUVRAY Sebastien FTRD/DMI/CAE To: MOBILE-IP@marvin.corpeast.baynetworks.com Date: Fri, 2 Mar 2001 09:23:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: p-mail1.cnet.fr X-SMTP-MAIL-FROM: sebastien.auvray@rd.francetelecom.fr X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: p-mail1.rd.francetelecom.fr [193.49.124.31] X-Orig: X-Orig: X-Orig: unsubscribe From ronyoung@nortelnetworks.com Fri Mar 2 04:03:52 2001 Received: from smtprch2.nortel.com ([192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23986 for ; Fri, 2 Mar 2001 04:03:52 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 02:46:54 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 02:50:30 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id DAA26166 for ; Fri, 2 Mar 2001 03:43:44 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Fri, 2 Mar 2001 03:42:46 -0500 Received: from m018.com ( [210.112.11.138]) by with SMTP (MailShield v1.5); Fri, 02 Mar 2001 03:43:57 -0500 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 11:18:11 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:41:58 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 05:18:27 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1SKWk816728 for seamoby-list; Wed, 28 Feb 2001 12:32:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1SKWho16723 for ; Wed, 28 Feb 2001 12:32:44 -0800 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SJgGC01869 for ; Wed, 28 Feb 2001 20:42:16 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 20:42:17 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 20:42:15 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBAB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , mobile-ip@marvin.corpeast.baynetworks.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff Date: Wed, 28 Feb 2001 20:42:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk X-SMTP-HELO: m018.com X-SMTP-MAIL-FROM: Hesham.Soliman@era.ericsson.se X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [210.112.11.138] X-Orig: X-Orig: X-Orig: > (Hoping this gets through the MIP mailing list problems...) > => It didn't. I think this is definitely a MIP issue so we should discuss it on the MIP list. You need to send your mail to mobile-ip@standards.nortelnetworks.com > In draft-thomas-seamoby-rsvp-analysis-00.txt, some serious problems with MIP > and RSVP signalling are identified. > => Sure RSVP doesn't handle IP mobility. > Specifically, when a handoff occurs, > a round-trip BU must occur before the CN can issue an RSVP PATH message > to assure QoS over the new route. Aggregated RSVP (see > draft-ietf-rsvp-aggr-02.txt) > doesn't help, because the BU must still propogate to the CN for the CN to issue > the PATH. All aggregation does is reduce the state in routers internal to the > aggregation region, it does not reduce signalling requirements over > standard RSVP. > => Yes. > There is a case where signalling can be optimized that is identified in > draft-thomas-seamoby-rsvp-analysis-00.txt. This is the case where the movement > of the mobile does not involve a change in CoA but rather is handled by > installing > a new host route up to the join router between the old and new path. > Establishment > of the new route is followed by a PATH message from the new join router > to the MN, and a RESV from the MN back to the join router (pg. 10 in the > draft). > > In draft-malinen-mobileip-regreg6-00.txt, a hierarchical MIP mechanism (called > regional registrations) is defined that works very much like a host route. > Routers > => No it doesn't. The MN's CoA changes when the MN moves. > between the new access router and the join router (called a crossover router > in the draft) examine a BU routing option and the join router reconfigures its > binding table to take account of the new route. The routers here are defined > to be special regional aware routers, but the principle is the same. > > Note that in HMIPv6 (draft-ietf-mobileip-hmipv6-01.txt), since the > intervening routers between the MAP and the mobile node never see the > topology change, the same severe performance penalties w.r.t. RSVP > signalling as in the standard > MIPv6 case should occur. > => If you believe a crossover router solves the problem then you can see the MAP as the same thing. But the fact is neither a cross over router (in draft-malinen-...) nor HMIPv6 solves that problem. A new PATH needs to be setup anyway for the outgoing traffic. The path between the MAP and the CN is unchanged for incoming traffic. > So, I'm wondering if the regional registration BU routing option could > serve as a trigger for redoing the RSVP signalling for QoS? Comments? > => I think the problem is much bigger than that. The issue of mobility and QoS needs to be addressed in more detail. Michael's draft (I haven't finished it yet) is a very good start. We can't solve it for HMIP only, the problem needs to be addressed for MIP in general. Regards, Hesham From ronyoung@nortelnetworks.com Fri Mar 2 06:08:51 2001 Received: from smtprch2.nortel.com ([192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25301 for ; Fri, 2 Mar 2001 06:08:51 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 04:52:02 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 04:55:03 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id FAA08815 for ; Fri, 2 Mar 2001 05:48:22 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Fri, 2 Mar 2001 05:47:28 -0500 Received: from mailserv.intranet.gr ( [146.124.14.106]) by with SMTP (MailShield v1.5); Fri, 02 Mar 2001 05:48:40 -0500 Received: from patreas.patra.intranet.gr (patreas.intranet.GR [146.124.171.10]) by mailserv.intranet.gr (8.11.2/8.11.1) with ESMTP id f22AgT414360 for ; Fri, 2 Mar 2001 12:42:29 +0200 (EET) Received: from patdpd19.intranet.gr (patdpd19 [146.124.171.45]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with SMTP id MAA21885 for ; Fri, 2 Mar 2001 12:56:10 +0200 (EET) From: Dionisios Gatzounas Organization: INTRACOM S.A. To: MOBILE-IP@marvin.corpeast.baynetworks.com Date: Fri, 2 Mar 2001 12:41:06 +0200 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01030212410600.00846@patdpd19.intranet.gr> Content-Transfer-Encoding: 8bit X-SMTP-HELO: mailserv.intranet.gr X-SMTP-MAIL-FROM: dgat@intracom.gr X-SMTP-RCPT-TO: MOBILE-IP@standards.nortelnetworks.com X-SMTP-PEER-INFO: [146.124.14.106] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 8bit unsubscribe From ronyoung@nortelnetworks.com Fri Mar 2 06:25:17 2001 Received: from smtprch2.nortel.com ([192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25390 for ; Fri, 2 Mar 2001 06:25:17 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 05:09:10 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 05:12:39 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id GAA09134 for ; Fri, 2 Mar 2001 06:07:07 -0500 (EST) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Fri, 2 Mar 2001 06:05:26 -0500 Received: from hosaka.smallworks.com ( [192.207.126.1]) by with SMTP (MailShield v1.5); Fri, 02 Mar 2001 06:07:06 -0500 Received: from smtp4s.retemail.es (smtp4.iddeo.es [62.81.31.73]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA13752 for ; Fri, 2 Mar 2001 05:04:25 -0600 (CST) Received: from zipi ([62.81.29.130]) by smtp4s.retemail.es (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010302110422.WOSC961.smtp4s.retemail.es@zipi> for ; Fri, 2 Mar 2001 12:04:22 +0100 Message-ID: <001601c0a309$02e5c660$821d513e@CATALUNYA> From: Oscar de Luis To: mobile-ip Subject: unsubscribe mobile-ip Date: Fri, 2 Mar 2001 12:07:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C0A311.6415DDA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: oscar.de.luis@upcnet.es X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [192.207.126.1] X-Orig: X-Orig: X-Orig: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C0A311.6415DDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe mobile-ip ------=_NextPart_000_0013_01C0A311.6415DDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe=20 mobile-ip

------=_NextPart_000_0013_01C0A311.6415DDA0-- From ronyoung@nortelnetworks.com Fri Mar 2 06:52:09 2001 Received: from smtprch2.nortel.com ([192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25826 for ; Fri, 2 Mar 2001 06:52:09 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 05:38:31 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 05:41:24 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id GAA09470 for ; Fri, 2 Mar 2001 06:35:27 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Fri, 2 Mar 2001 06:35:21 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 06:35:20 -0500 Received: from baldo.fub.it (baldo.fub.it [193.204.211.129]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA13884 for ; Fri, 2 Mar 2001 05:35:10 -0600 (CST) Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3 release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for ; Fri, 2 Mar 2001 12:38:23 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Mar 2001 12:40:16 +0100 To: mobile-ip@smallworks.com From: wnk@fub.it (Roberto Winkler) Subject: test X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: wnk@fub.it X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: From ronyoung@nortelnetworks.com Fri Mar 2 07:24:46 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27107 for ; Fri, 2 Mar 2001 07:24:46 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 06:06:31 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 06:05:34 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id GAA09726 for ; Fri, 2 Mar 2001 06:57:27 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Fri, 2 Mar 2001 06:55:53 -0500 Received: from hosaka.smallworks.com ( [216.12.231.17]) by with SMTP (MailShield v1.5); Fri, 02 Mar 2001 06:57:05 -0500 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA13962 for ; Fri, 2 Mar 2001 05:55:14 -0600 (CST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f22BtDd05780 for ; Fri, 2 Mar 2001 12:55:13 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 02 12:54:49 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 2 Mar 2001 12:54:48 +0100 Message-ID: From: "Evaristo-Jose Camarero (ECE)" To: "'mobile-ip@smallworks.com'" Subject: unsubscribe mobile-ip Date: Fri, 2 Mar 2001 12:54:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: Evaristo-Jose.Camarero@ece.ericsson.se X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.12.231.17] X-Orig: X-Orig: X-Orig: unsubscribe mobile-ip From ronyoung@nortelnetworks.com Fri Mar 2 09:05:33 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29709 for ; Fri, 2 Mar 2001 09:05:32 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 07:48:22 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 07:51:21 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id IAA11378 for ; Fri, 2 Mar 2001 08:41:58 -0500 (EST) Received: from zsc4s002.baynetworks.com by zsc4s000.baynetworks.com; Fri, 2 Mar 2001 05:40:44 -0800 Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by zsc4s002.baynetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 05:44:02 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id HAA14495 for ; Fri, 2 Mar 2001 07:41:41 -0600 (CST) Received: from 1e3wl (user-38lddlh.dialup.mindspring.com [209.86.182.177]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id IAA04186 for ; Fri, 2 Mar 2001 08:41:36 -0500 (EST) Message-ID: <003a01c0a31e$c6a7b580$b1b656d1@1e3wl> Reply-To: Frank Walker From: Frank Walker To: mobile-ip Subject: UNsubscribe mobile-ip Date: Fri, 2 Mar 2001 08:43:33 -0500 Organization: Boca Performance Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: fwalker@bocaperformance.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: hosaka.SmallWorks.COM [192.207.126.1] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit UNsubscribe mobile-ip From ronyoung@nortelnetworks.com Fri Mar 2 09:49:49 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01064 for ; Fri, 2 Mar 2001 09:49:48 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 2 Mar 2001 08:36:13 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 2 Mar 2001 08:38:48 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id JAA12273 for ; Fri, 2 Mar 2001 09:30:18 -0500 (EST) Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com; Fri, 2 Mar 2001 09:27:50 -0500 Received: from hosaka.smallworks.com (jim0.corp.aus.wayport.net [216.12.231.17]) by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 02 Mar 2001 09:29:57 -0500 Received: from baldo.fub.it (baldo.fub.it [193.204.211.129]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id IAA14760 for ; Fri, 2 Mar 2001 08:29:55 -0600 (CST) Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3 release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for ; Fri, 2 Mar 2001 15:33:23 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Mar 2001 15:35:16 +0100 To: mobile-ip@smallworks.com From: wnk@fub.it (Roberto Winkler) Subject: please unsubscribe me (I've tried with listserv, but it does not work !) X-SMTP-HELO: hosaka.smallworks.com X-SMTP-MAIL-FROM: wnk@fub.it X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: jim0.corp.aus.wayport.net [216.12.231.17] X-Orig: X-Orig: X-Orig: From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 2 18:48:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24927 for ; Fri, 2 Mar 2001 18:48:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16943; Fri, 2 Mar 2001 15:48:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11506; Fri, 2 Mar 2001 15:46:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f22NilP29146 for mobile-ip-dist; Fri, 2 Mar 2001 15:44:47 -0800 (PST) Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f22Niae29136 for ; Fri, 2 Mar 2001 15:44:37 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA15436 for ; Fri, 2 Mar 2001 18:44:35 -0500 (EST) Date: Fri, 2 Mar 2001 18:44:38 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] Mobile-IP list woes - STOP AND READ!!! To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: We had to bring down the mobile-ip@sunroof.eng.sun.com last night due to mail loops, and lots of bad dst addrs. We think everything's OK, but for now... Please DO NOT post to this list until you get another confirmation message indicating it's OK to do so! The subject will say "mobile-ip@sunroof.eng.sun.com -- OK to post!" This email will contain some information on the configuration of the list, and some bits related to the list. Please allow us to make sure we've fixed the problem... Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 2 19:38:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25514 for ; Fri, 2 Mar 2001 19:38:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01533; Fri, 2 Mar 2001 16:36:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22036; Fri, 2 Mar 2001 16:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f230Xgn29335 for mobile-ip-dist; Fri, 2 Mar 2001 16:33:42 -0800 (PST) Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f230XX129328 for ; Fri, 2 Mar 2001 16:33:33 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA17915 for ; Fri, 2 Mar 2001 19:33:33 -0500 (EST) Date: Fri, 2 Mar 2001 19:33:37 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] mobile-ip@sunroof.eng.sun.com -- OK to post! To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Fellow mobile-ip participants, OK - I think we're through the worst of the readjustment period. It's obvious the list I inherited would suffer the same casualties as it did at Nortel, but I think I've worked out the [major, and now a lot more minor] problems. The major problem was a mail server in Korea looping mail, so they're gone. It's been nearly 50 minutes now since I sent out the test message; no loops, and only 6 bounces, 4 for over-quota reasons. I'm going to declare the list officially open again. In case one of the many distribution lists that are subscribed to the main mobile-ip distribution list contains a[n old] mail loop, I've asked the folks at Nortel to bounce email to mobile-ip@standards.nortelnetworks.com with a message indicating posting should be to mobile-ip@sunroof.eng.sun.com. I don't know if they've done this, but if you get this bounce, check where you sent your post! You MUST post from the email address that's subscribed in order to actually have your email delivered to the list. This is to combat the spam that's given us a lot of angst. I've got mungedomain enabled, so that helps, but it's not completely forgiving. If you're getting list mail, and you don't see what you're posting on the list, you're probably subsribed using a different email address. Either email me (from the same account, please) and I'll look into it, or resubscribe then repost (yes, you'll likely then get two coppies of everything, but you'll be able to post while we talk about what other address you may have subscribed). For those that are curious: # mungedomain [bool] (no) # If set to yes, a different method is used to determine a matching # address. When set to yes, addresses of the form user@dom.ain.com # are considered equivalent to addresses of the form user@ain.com. # This allows a user to subscribe to a list using the domain address # rather than the address assigned to a particular machine in the # domain. This keyword affects the interpretation of addresses for # subscribe, unsubscribe, and all private options. mungedomain = yes The max message size you can post to the list is the 'default' of 40K. This is HUGE, so I'm thinking of decreasing it. Still, people are trying to post messages larger than this! Don't. Use pointers. To me, 10K seems like a far more reasonable max, but I'm willing to compromize. I'll entertain votes for to decrease this to specific values. Unsubscribe to mobile-ip-request@sunroof.eng.sun.com is now working. Sunroof.eng.sun.com had a small conflict between Majordomo's passwd:uid and nis:uid, but we're over it. If you want to unsubscribe (here, I'll make it easy for you): Email is being archived, so no worries, but it wont be accessible from outside of Sun until later (which means the header List-Archive: is currently broken). The archives from when the list was at Nortel are still available at Nortel, Archive: http://www.nortelnetworks.com/standards as it says on the mobile IP WG webpage. When the archives are reachable at Sun I'll send out another announcement. As an advisary, I've been and will be fairly tolerant about full-queues, especially if we have another looping issue. However, if I keep seeing bounces to your address because you've been over-quota for a while, you're going to need to resubscribe when you catch up! FYI: mobile-ip@smallworks.com : This is the old working group list from many years ago. Someone apparently posted their subscriber list, I don't know why. The mail headers from posts to that list seem to indicate it just points to the list address at baynetworks.com (nortel). I'd think that those who are subscribed to it would have been around long enough to know the right way to unsubscribe is NOT to post to the list. If you wish to get off the smallworks list, send email to smallworks, but NOT to the list! If you send unsubscribe email to (any of) the list(s), best case is it simply goes in my inbox, and you *will* have to wait until I get to it. I don't care how many emails you send before I have time to grok the first one (well, OK, I do), but what you'll experience is a queueing problem. If you can't unsubscribe automatically, then please be patient. The good news is all [un]subscribe email to mobile-ip@sunroof.eng.sun.com seems to be getting caught, and delivered to me. The caveat is [un]subscribe to another alias, who knows. Any other issues, please let me know. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 2 19:59:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25765 for ; Fri, 2 Mar 2001 19:59:33 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06860; Fri, 2 Mar 2001 16:58:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25661; Fri, 2 Mar 2001 16:58:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f230u4I29458 for mobile-ip-dist; Fri, 2 Mar 2001 16:56:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f230tt129451 for ; Fri, 2 Mar 2001 16:55:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25273 for ; Fri, 2 Mar 2001 16:55:55 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00305 for ; Fri, 2 Mar 2001 16:55:53 -0800 (PST) Received: by fridge.docomo-usa.com (Postfix, from userid 119) id 341BA97406; Fri, 2 Mar 2001 17:00:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fridge.docomo-usa.com (Postfix) with ESMTP id 330AD97801 for ; Fri, 2 Mar 2001 17:00:36 -0800 (PST) Date: Fri, 2 Mar 2001 17:00:36 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: IETF Mobile-IP Working Group Subject: [mobile-ip] New I-D: draft-gwon-mobileip-l3mp-mipv4-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To all, I submitted a working document that can be located at http://search.ietf.org/internet-drafts/draft-gwon-mobileip-l3mp-mipv4-00.txt FYI, the abstract of the document is below Thank you, Abstract This draft describes a network layer (layer 3) handoff-triggering mechanism and associated Mobile IPv4 predictive handoff scheme that is free of the link layer (layer 2) triggering events. By utilizing layer 3 information only, the network layer mobility prediction (L3MP) mechanism first predicts the future per packet latency. Then, the L3MP selects the future access point given the predicted values in advance. The future access point suggestion by the L3MP triggers the Mobile IP predictive handoff. The predictive handoff scheme described in this draft encompasses three significant steps before switching the actual access point: L3MP handoff triggering, pre-register, and route pre-optimization. ---------------------------------------------- Youngjune Gwon DoCoMo Communications Laboratories USA, Inc. And, the Truth will set you free. - John 8:32 ---------------------------------------------- From ronyoung@nortelnetworks.com Sat Mar 3 15:29:39 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24620 for ; Sat, 3 Mar 2001 15:29:39 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sat, 3 Mar 2001 14:16:37 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sat, 3 Mar 2001 14:19:31 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA27879 for ; Sat, 3 Mar 2001 15:05:30 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Sat, 3 Mar 2001 15:04:41 -0500 Received: from poseidon.dcs.napier.ac.uk ( [146.176.161.4]) by with SMTP (MailShield v1.5); Sat, 03 Mar 2001 15:05:54 -0500 Received: from epcc.ed.ac.uk (circe [146.176.164.182]) by poseidon.dcs.napier.ac.uk (8.9.3/8.9.3) with ESMTP id RAA00989; Sat, 3 Mar 2001 17:54:42 GMT Sender: paulc@poseidon.dcs.napier.ac.uk Message-ID: <3AA1307C.743E9F2E@epcc.ed.ac.uk> Date: Sat, 03 Mar 2001 17:57:16 +0000 From: Paul Cristea Reply-To: pcristea@epcc.ed.ac.uk X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4m) MIME-Version: 1.0 To: iwssip2001@dsp.pub.ro Subject: IWSSIP 2001 deadline extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: poseidon.dcs.napier.ac.uk X-SMTP-MAIL-FROM: pcristea@epcc.ed.ac.uk X-SMTP-RCPT-TO: nseddigh@nortelnetworks.com,mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [146.176.161.4] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit 8th International Workshop on Systems, Signals and Image Processing IWSSIP 2001 June 7 - 9, 2001 - Bucharest, Romania http://www.dsp.pub.ro/iwssip2001/ Please accept our apologies in case of multiple copies of this letter ************************************************* The deadline for paper submission for IWSSIP 2001 has been extended till March 10, 2001 ************************************************* Please find other information on the IWSSIP 2001 web site: http://www.dsp.pub.ro/iwssip2001/ Looking forward to your contribution to IWSSIP 2001. Best regards, Paul Cristea General Chair of IWSSIP 2001 iwssip2001@dsp.pub.ro From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 18:30:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16271 for ; Sun, 4 Mar 2001 18:30:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28680; Sun, 4 Mar 2001 15:29:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17855; Sun, 4 Mar 2001 15:29:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f24NRx401774 for mobile-ip-dist; Sun, 4 Mar 2001 15:27:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f24NRo101767 for ; Sun, 4 Mar 2001 15:27:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00292 for ; Sun, 4 Mar 2001 15:27:51 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04022 for ; Sun, 4 Mar 2001 15:27:50 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA02425 for ; Sun, 4 Mar 2001 15:28:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY08450; Sun, 4 Mar 2001 15:27:49 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA24098; Sun, 4 Mar 2001 15:27:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15010.53109.244043.829231@thomasm-u1.cisco.com> Date: Sun, 4 Mar 2001 15:27:49 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] wither home address destination option? X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, at least maybe a close re-examination of it? In the last week I've managed to stumble on two serious side effects of the home address destination option. The first was when I realized that I made a mistake in my rsvp/mip draft with my general hope that fixing a problem with rsvp would help mipv6 as well. In particular, my mistake was in expecting that the reservation could heal locally with a different kind of reservation type. This turns out to not be the case, and it was startlingly obvious after I thought about it a bit: when you change care of addresses, _all_ of the routers who are party to the reservation need to get updated filterspecs with the new care of address. I believe that there is a draft (Shen) which suggests using the home address destination option as part of the flow key, but I'm afraid that that is going to be terribly slow since chasing down variable headers is not terribly efficient for routers. Note that the root cause of this is the we're assuming that the care of address must be placed as the source address, not the home address. In fact, if the home address were used instead of the care of address, it would produce the desired result of local healing at the join point of the reservation. The second thing I found -- and I think far more devestating -- is the observation of what would happen to hosts behind a mobile router. I've mentioned that I think that it is untenable for hosts behind a mobile router to be knowledgeable of the _mobile router's_ mobility. If nothing else, otherwise usable fixed line devices -- like oh say everybody's PC -- would cease to work on a boat or train or plane which had a nice mobile router connecting it up to the Internet. The thing that really opened my eyes is when a coworker mentioned that if the hosts behind the mobile router weren't mobile aware, they wouldn't be putting a home address option in, and would likely fail RPF checks. Ugh. In both of these cases doing the natural thing of putting the home address in the IP header would solve these unfortunate side effects. Reading the current draft, as far as I can tell the recommendation for using the destination option seems to have to main rationale: 1) RPF checks 2) Multicast works better RPF, IMO, is hardly sacrosanct: there is a well known failure mode of RPF which has to do with asynchronous routes which is sometimes tickled by multihomed hosts. I'm coming to the conclusion that this may be another limitation of RFP which if you consider it is not entirely surprising: mobility isn't entirely dissimilar to multihoming. RPF's main attraction is that it's trivial for routers to perform, however there are potentially other means of doing source filtering -- so called ACL's could be enabled to perform a similar function. The Multicast angle is new to me, so I'm hoping that maybe somebody can explain what the issues are. However it seems that at least in some cases it would be whole lot more natural to use the home address as the IP source address. Mike, who knows worm cans when he sees them From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 18:54:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16404 for ; Sun, 4 Mar 2001 18:54:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00881; Sun, 4 Mar 2001 15:53:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19449; Sun, 4 Mar 2001 15:53:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f24NovQ01849 for mobile-ip-dist; Sun, 4 Mar 2001 15:50:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f24Nof101842 for ; Sun, 4 Mar 2001 15:50:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18994 for ; Sun, 4 Mar 2001 15:50:42 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29668 for ; Sun, 4 Mar 2001 15:50:38 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:42:27 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:57:28 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:03:58 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 18:17:19 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f229fgc03224 for seamoby-list; Fri, 2 Mar 2001 01:41:42 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f229fdt03219 for ; Fri, 2 Mar 2001 01:41:39 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 11:19:57 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:57:17 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 08:06:48 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f21N9kF22316 for seamoby-list; Thu, 1 Mar 2001 15:09:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f21N9ho22311 for ; Thu, 1 Mar 2001 15:09:43 -0800 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA02681; Thu, 1 Mar 2001 14:19:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV08482; Thu, 1 Mar 2001 14:19:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28891; Thu, 1 Mar 2001 14:19:13 -0800 (PST) From: Michael Thomas Message-ID: <15006.51937.60735.267223@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 14:19:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Hemant.Chaskar@nokia.com Cc: mat@cisco.com, hchaskar@hotmail.com, Hesham.Soliman@era.ericsson.se, james.kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] Hierarchical MIP, QoS, and Handoff In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I really don't even know where to begin. It seems that your claim is that RSVP's receiver oriented PATH/RESV is either flawed, or should have a mode which allows a single pass. I believe this leads to overbooking for multicast since you don't get to do flow merging properly and a host of other reasons that I don't purport to understand well. What I really don't understand is why MIP would be the right place to solve this problem. If it has merit, the RSVP folks seems like a much more appropriate set of people to entertain such a proposal. I suspect that they'd be able to supply a lot more reasons why they designed RSVP the way they did. Suggesting that mobileip is a breed apart that requires its own QoS mechanisms sounds just as wrong headed as RSVP folks designing their own mobility protocol. Mike Hemant.Chaskar@nokia.com writes: > Yes, it goes end to end. But there is a basic difference illustrated > by following example. If we look at the latency between time end nodes > are ready to use new CoA and the time QoS forwarding treatment is programmed > > over the new path, it can be seen that RSVP takes one end-to-end round trip > time > between these two events. On the other hand, including QoS object with > binding > messages performs QoS programming before the nodes release packets using > new CoA. This is shown by following illustration. > > Suppose MN is currently at CoA1. Consider data traffic from the > CN towards the MN (downlink direction). > > o MN moves to CoA2. > > o MN sends BU from CoA2. > > ----[One way end-to-end delay]---- > > o BU reaches CN. CN sends BA to MN at CoA2. > > In RSVP, CN sends PATH message to MN at CoA2. > > In our approach, QoS OBJECT OPTION for downlink packet stream(s) > is included in HOP-by-HOP OPTIONS EXTENSION HEADER with the BA. > > o CN may start sending MN's packets to CoA2. These packets > contain CoA2 as destination address. > > **In RSVP approach, they are not identified by existing > reservations for MN's sessions. This is because, RSVP session is > primarily identified by destination address which now has changed > from CoA1 to CoA2. Hence, these packets will get default > forwarding treatment.** > > **In our approach, the packet carrying QoS information about these > packets precedes these packets, and hence, they can get proper > forwarding treatment.** > > ----[One way end-to-end delay]---- > > o BA reaches MN at CoA2. In RSVP approach, PATH message reaches > MN at CoA2. > > o In RSVP approach, MN sends RESV to CN. > > ----[One way end-to-end delay]---- > > o In RSVP approach, RESV reaches CN. > > **In RSVP approach, it is at this time that the proper QoS > forwarding treatment is programmed at the intermediate network > domains for packets destined to CoA2.** > > > Hemant > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 01. March 2001 13:33 > To: Hemant Chaskar > Cc: Hesham.Soliman@era.ericsson.se; james.kempf@sun.com; > mobile-ip@marvin.corpeast.baynetworks.com; seamoby@diameter.org > Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff > > > > I don't see how this fundamentally changes > anything that James brought up. It still has to go > end to end, and it's still touching every router > in between MN and CN. > > What I do see is a lot of reinvention of RSVP > Rspec and Tspec's for no known reason. The only > thing I can see of possible value is the ability > to piggyback the QoS update with the BU, but even > if this is the sole goal -- and that it's a worthy > goal which is not at all apparent to me -- I > imagine that there are better ways of doing this > with out reinventing RSVP: like, maybe, > piggybacking the BU on the PATH, or some such. > > Mike > > > Hemant Chaskar writes: > > Regarding the issue of round-trip latency in programming QoS forwarding > > treatment along new path after change in CoA: > > > > This is intrinsic drawback of OPWA model of resource reservation of RSVP. > In > > the worst case, one round-trip time will include traversals of four > wireless > > links. This happens when both CN and MN are mobile. > > > > Note that this drawback is eliminated in the approach to QoS signaling > based > > on including QoS Object in hop-by-hop options extension header along with > > > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was > > presented in SD and revised version (01) will be submitted soon. > > > > Hemant > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 19:05:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16515 for ; Sun, 4 Mar 2001 19:05:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05644; Sun, 4 Mar 2001 16:05:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04218; Sun, 4 Mar 2001 16:05:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2501Eh03008 for mobile-ip-dist; Sun, 4 Mar 2001 16:01:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2500i102986 for ; Sun, 4 Mar 2001 16:00:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11305 for ; Sun, 4 Mar 2001 16:00:44 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from m018.com ([210.112.11.138]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18531 for ; Sun, 4 Mar 2001 16:00:43 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:52:08 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:56:29 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:03:26 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 18:08:10 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f229Z6e03024 for seamoby-list; Fri, 2 Mar 2001 01:35:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f229Ymt02989 for ; Fri, 2 Mar 2001 01:34:49 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 11:18:25 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:42:10 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 08:07:10 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1SMbuU17153 for seamoby-list; Wed, 28 Feb 2001 14:37:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1SMbro17148 for ; Wed, 28 Feb 2001 14:37:53 -0800 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1SLl7g00574 for ; Wed, 28 Feb 2001 15:47:17 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Feb 2001 15:47:02 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Feb 2001 15:47:02 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213560@daeis07nok> To: Phil_Neumiller@3Com.com, mobile-ip@sunroof.eng.sun.com Cc: seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 15:47:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, I do not see anyone saying that Mobile IP is the only solution for all scenarios that require mobility. I am sure there are many scenarios that Mobile IP may or may not be the most optimal solution. If Mobile IP is unable to work as well as anything else you may have in mind for specific scenarios, then why deploy Mobile IP in such scenarios? Can you be more specific on the kind of environments and requirements that these environments have that would make it impossible for Mobile IP to work in. -Basavaraj Pls. note that the Mobile IP mailing list has a new address. > -----Original Message----- > From: ext Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com] > Sent: Wednesday, February 28, 2001 1:46 PM > To: mobile-ip@marvin.corpeast.baynetworks.com > Cc: seamoby@diameter.org > Subject: [seamoby] Arch discussions in IETF > > > > > > We have said countless times that IETF does not define > architecture. However > MIP did. > Many of the problems people have with MIP are with its basic > architecture, not > the protocol. > Why can't their be an architectural debate on MIP in the IETF > (not protocol). > There are > boxes defined. There is a CN, a MN, an HA, a set of routers. > Lets talk about > how these > need to play in today's modern residential and business > deployments. Why do we > always > have to cater to cellular? Why do the cellular guys get most > the say? The > Internet has > new stuff like FTC, VoIP, SLP, RSVP, diffserv, and new radio access > technologies that > can enable different types of mobility architectures. Is an > HA still a good > idea in > every scenario? Why? Can we talk about this? If not why > not? Inquiring minds > want to > know. > > Here is an example. Why do I always need to use MIP? Let's > say I have a > community of > VPN's defined to interlink residences that interoperate with > mobility (a bunch > of families > allows their mobiles to operate in each other's premises), > i.e. mobile hosts are > allowed > to seamless travel within theses spaces but only in theses > spaces (could be set > up > in hotel rooms, conferences, etc). The COA changes but there > is no HA. > > I have lots of scenarios like this. > > Thanks, > > Phil > > > > I believe that the problem statement does have some things > that Mobile IP will > have a REALLY hard time handling. However, as I have stated > numerous times, > statements like "MIP is too slow" just doesn't cut it. Let's > get to the meat > of the requirements, and then we can identify whether MIP can > do the job. > > PatC > > From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 19:07:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16540 for ; Sun, 4 Mar 2001 19:07:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05608; Sun, 4 Mar 2001 16:05:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04217; Sun, 4 Mar 2001 16:05:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f25018s03007 for mobile-ip-dist; Sun, 4 Mar 2001 16:01:08 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2500i102985 for ; Sun, 4 Mar 2001 16:00:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11303 for ; Sun, 4 Mar 2001 16:00:44 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04231 for ; Sun, 4 Mar 2001 16:00:43 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:52:07 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:56:21 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 20:03:21 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f22BUO205000 for seamoby-list; Fri, 2 Mar 2001 03:30:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f22BUAt04966 for ; Fri, 2 Mar 2001 03:30:10 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 19:31:04 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 18:35:59 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f229Yvw03003 for seamoby-list; Fri, 2 Mar 2001 01:34:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f229Ymt02991 for ; Fri, 2 Mar 2001 01:34:49 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 11:18:25 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:42:08 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 07:37:27 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1SMekh17187 for seamoby-list; Wed, 28 Feb 2001 14:40:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1SMego17182 for ; Wed, 28 Feb 2001 14:40:42 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1SLoGg00941 for ; Wed, 28 Feb 2001 15:50:16 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Feb 2001 15:49:45 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Feb 2001 15:49:45 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213561@daeis07nok> To: Hesham.Soliman@era.ericsson.se, james.kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com Cc: claude.castelluccia@inrialpes.fr, seamoby@diameter.org, gdommety@cisco.com Subject: [mobile-ip] RE: [seamoby] Is Mobile IP too slow or is Routing Table UpdateTo o slow? (was....) Date: Wed, 28 Feb 2001 15:49:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > Hi James > > > Can you elaborate why you believe a design that > accommodates multiple levels of > > hierarchy is a bad idea? The draft doesn't go into much > detail on this point. > > > => Well since the MIP list is broken we can take the discusion > on the sister list :) The new MIP list is located at : mobile-ip@sunroof.eng.sun.com -Basavaraj From ronyoung@nortelnetworks.com Sun Mar 4 19:46:16 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16708 for ; Sun, 4 Mar 2001 19:46:16 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sun, 4 Mar 2001 18:28:36 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sun, 4 Mar 2001 18:31:35 -0600 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id TAA10356 for ; Sun, 4 Mar 2001 19:10:46 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s001.baynetworks.com; Sun, 4 Mar 2001 16:04:01 -0800 Received: from m018.com ( [210.112.11.138]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Sun, 04 Mar 2001 16:10:00 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:54:59 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:57:45 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:03:48 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 18:32:00 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f229Xte02914 for seamoby-list; Fri, 2 Mar 2001 01:33:55 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f229Xqt02908 for ; Fri, 2 Mar 2001 01:33:52 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 11:18:11 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:41:58 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 05:18:27 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f1SKWk816728 for seamoby-list; Wed, 28 Feb 2001 12:32:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f1SKWho16723 for ; Wed, 28 Feb 2001 12:32:44 -0800 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1SJgGC01869 for ; Wed, 28 Feb 2001 20:42:16 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Feb 28 20:42:17 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 20:42:15 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBAB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , mobile-ip@marvin.corpeast.baynetworks.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff Date: Wed, 28 Feb 2001 20:42:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk X-SMTP-HELO: m018.com X-SMTP-MAIL-FROM: Hesham.Soliman@era.ericsson.se X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [210.112.11.138] X-Orig: X-Orig: X-Orig: > (Hoping this gets through the MIP mailing list problems...) > => It didn't. I think this is definitely a MIP issue so we should discuss it on the MIP list. You need to send your mail to mobile-ip@standards.nortelnetworks.com > In draft-thomas-seamoby-rsvp-analysis-00.txt, some serious problems with MIP > and RSVP signalling are identified. > => Sure RSVP doesn't handle IP mobility. > Specifically, when a handoff occurs, > a round-trip BU must occur before the CN can issue an RSVP PATH message > to assure QoS over the new route. Aggregated RSVP (see > draft-ietf-rsvp-aggr-02.txt) > doesn't help, because the BU must still propogate to the CN for the CN to issue > the PATH. All aggregation does is reduce the state in routers internal to the > aggregation region, it does not reduce signalling requirements over > standard RSVP. > => Yes. > There is a case where signalling can be optimized that is identified in > draft-thomas-seamoby-rsvp-analysis-00.txt. This is the case where the movement > of the mobile does not involve a change in CoA but rather is handled by > installing > a new host route up to the join router between the old and new path. > Establishment > of the new route is followed by a PATH message from the new join router > to the MN, and a RESV from the MN back to the join router (pg. 10 in the > draft). > > In draft-malinen-mobileip-regreg6-00.txt, a hierarchical MIP mechanism (called > regional registrations) is defined that works very much like a host route. > Routers > => No it doesn't. The MN's CoA changes when the MN moves. > between the new access router and the join router (called a crossover router > in the draft) examine a BU routing option and the join router reconfigures its > binding table to take account of the new route. The routers here are defined > to be special regional aware routers, but the principle is the same. > > Note that in HMIPv6 (draft-ietf-mobileip-hmipv6-01.txt), since the > intervening routers between the MAP and the mobile node never see the > topology change, the same severe performance penalties w.r.t. RSVP > signalling as in the standard > MIPv6 case should occur. > => If you believe a crossover router solves the problem then you can see the MAP as the same thing. But the fact is neither a cross over router (in draft-malinen-...) nor HMIPv6 solves that problem. A new PATH needs to be setup anyway for the outgoing traffic. The path between the MAP and the CN is unchanged for incoming traffic. > So, I'm wondering if the regional registration BU routing option could > serve as a trigger for redoing the RSVP signalling for QoS? Comments? > => I think the problem is much bigger than that. The issue of mobility and QoS needs to be addressed in more detail. Michael's draft (I haven't finished it yet) is a very good start. We can't solve it for HMIP only, the problem needs to be addressed for MIP in general. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 19:48:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16735 for ; Sun, 4 Mar 2001 19:48:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20663; Sun, 4 Mar 2001 16:47:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10726; Sun, 4 Mar 2001 16:47:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f250ehS08468 for mobile-ip-dist; Sun, 4 Mar 2001 16:40:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f250dK108294 for ; Sun, 4 Mar 2001 16:39:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05367 for ; Sun, 4 Mar 2001 16:09:24 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23471 for ; Sun, 4 Mar 2001 16:09:23 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:54:59 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:57:45 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:03:55 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 18:23:56 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f222PrF23042 for seamoby-list; Thu, 1 Mar 2001 18:25:53 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f222Peo23026 for ; Thu, 1 Mar 2001 18:25:41 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:21:10 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 1 Mar 2001 11:29:46 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f212Wx518137 for seamoby-list; Wed, 28 Feb 2001 18:32:59 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f212Wuo18132 for ; Wed, 28 Feb 2001 18:32:56 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f211gVg18072 for ; Wed, 28 Feb 2001 19:42:31 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Feb 2001 19:42:07 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Feb 2001 19:42:07 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] Arch discussions in IETF Date: Wed, 28 Feb 2001 19:42:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, Comments inline: >Hi Raj, > >>Phil, >> >>I do not see anyone saying that Mobile IP is the only solution for all >>scenarios that require mobility. I am sure there are many scenarios >>that Mobile IP may or may not be the most optimal solution. If Mobile >>IP is unable to work as well as anything else you may have in mind >>for specific scenarios, then why deploy Mobile IP in such scenarios? > >Then where might these other solutions be standardized in the IETF? Seamoby??? Some other WG (MANET, Mobile IP, New WG)? Or is it the IRTF that Do these kind of scenarios and problems get covered in the mobility management problems statement I-D? If you believe this kind of mobility currently does not have a WG in the IETF that deals with it, then maybe that's what Seamoby should do. >Would this fall under the classification of micro-mobility even though >the "so-called" COA or routing prefix does indeed change? I guess what >I am getting at is there may be cases of infra-structure-less mobility >where the COA changes but there is no HA. Would this be micro or >macro mobility? > The terms micro and macro mobility are overloaded and perceptions are different w.r.t where micro mobility ends and macro mobility begins. The non-existence of an HA has no implications on whether you are dealing with micro or macro mobility. I mean do you consider macro mobility as only those cases wherein the MN sends a binding update to the HA? >>Can you be more specific on the kind of environments and requirements >>that these environments have that would make it impossible for Mobile >>IP to work in. > >Sure. Specifically, I am very interested in portable devices that will >find there way into homes. Wireless appliances, MP3 players, digital >radios, digital security devices, gaming units, VoIP devices, etc. I >am also interested in these types of devices that may be used in small >to medium business that may not have large infrastructures in place. > Is there any limitation in terms of having Mobile IP support for such devices? And why would you not be able to have Mobile IP in whatever infrastructure exists (either in the home network or the small business)? Are you concerned with the fact that if you have Mobile IP, then you need an HA at the least (in the case of IPv6)? >Thank you, > >Phil Neumiller > Regards, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 4 19:58:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16866 for ; Sun, 4 Mar 2001 19:58:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24242; Sun, 4 Mar 2001 16:57:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22308; Sun, 4 Mar 2001 16:57:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f250egs08465 for mobile-ip-dist; Sun, 4 Mar 2001 16:40:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f250dH108287 for ; Sun, 4 Mar 2001 16:39:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04927 for ; Sun, 4 Mar 2001 16:07:43 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06925 for ; Sun, 4 Mar 2001 16:07:43 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 08:54:53 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:56:28 +0900 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 20:03:25 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 17:44:33 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f222XZo23255 for seamoby-list; Thu, 1 Mar 2001 18:33:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from m018.com ([210.112.11.138]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f222XWo23250 for ; Thu, 1 Mar 2001 18:33:32 -0800 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:27:56 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 2 Mar 2001 04:33:23 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id f21IrYS21292 for seamoby-list; Thu, 1 Mar 2001 10:53:34 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f21IrVo21287 for ; Thu, 1 Mar 2001 10:53:31 -0800 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14049; Thu, 1 Mar 2001 10:03:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV01622; Thu, 1 Mar 2001 10:02:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28818; Thu, 1 Mar 2001 10:02:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15006.36559.662301.41126@thomasm-u1.cisco.com> Date: Thu, 1 Mar 2001 10:02:55 -0800 (PST) To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: [mobile-ip] Re: [seamoby] Arch discussions in IETF In-Reply-To: <3A9E8895.DD789091@usa.alcatel.com> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321356A@daeis07nok> <3A9E8895.DD789091@usa.alcatel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think this quite captures the finesse on the issue. I don't believe that the proper framing of the question is whether a new routing protocol needs to be invented or not: it may very well be that there is nothing to be done on the _routing protocol_ front to support injecting host routes if that's the ultimate solution. There may be work needed to support _signaling_ a router that it needs to change how a subnet is reachable. I know this is hair splitting, but I think it's important to separate out that it's quite possible that the heavy lifting can already be done by current protocols, and that all we need is the ability to trigger them to happen. You might call that a "routing protocol" too, but it ought not evoke the fear and loathing that postulating a Routing Protocol should. MIke Behcet Sarikaya writes: > Hi Raj and Phil, > > I think the critical question for micromobility (mm) branch of the > Seamoby WG is > to be or not to be, i.e. > whether another routing protocol for mobility is required. Presently we > have the MIP and > the Manet routing approaches. > The alternative seems to be per-host routes or host-based routing. I do > not think there > has been another breakthrough proposal significantly different. We all know > Cellular IP and > Hawaii proposals. Recently there is probably another one based on extending > OSPF with > host-based routes. > Of course there are a lot of details but I think this is the crux of > Seamoby mm problem. > > -- > Behcet > From ronyoung@nortelnetworks.com Sun Mar 4 20:22:52 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17062 for ; Sun, 4 Mar 2001 20:22:51 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sun, 4 Mar 2001 19:01:44 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sun, 4 Mar 2001 19:04:21 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id TAA10865 for ; Sun, 4 Mar 2001 19:53:19 -0500 (EST) Message-Id: <200103050053.TAA10865@marvin.corpeast.baynetworks.com> Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Sun, 4 Mar 2001 19:52:21 -0500 Received: from treca.org.tw ( [203.73.7.129]) by with SMTP (MailShield v1.5); Sun, 04 Mar 2001 19:53:28 -0500 Received: from host [208.161.7.141] by treca.org.tw with ESMTP (SMTPD32-4.03) id A3521B590246; Mon, 05 Mar 2001 08:48:18 PST From: Victor Prestern Subject: The Web is Open #3B78 To: li4fd@nortel.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sun, 04 Mar 2001 19:45:26 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit X-SMTP-HELO: treca.org.tw X-SMTP-MAIL-FROM: pgkd@whomail.net X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [203.73.7.129] X-Orig: X-Orig: X-Orig: This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

Do you accept credit cards? Your competition does!

 

Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to thrid parties!
Home Businesses OK! Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!

Everyone Approved!

Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
 

Service Industry Standard

US
Site Inspection $50 - $75 FREE
Shipping $50 - $75 FREE
Warranty $10 Per Month= FREE
Sales Receipts $10 - $50&nbs= p; FREE
Fraud Screening

$=2E50 - $1=2E00
Per Transaction

 FREE
Amex Set Up $50 - $75 FREE
24 Hour Help Line $10 Month FREE
Security Bond $5000- $10,00= 0
Or More		 NONE

This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

<= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

Apply Free With No Risk!

Pleas= e fill out the express application form completely=2E
Incomplete information m= ay prevent us from properly processing your application=2E
Your Full Emai= l Address:
be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
Your Name:
Business Name:=
Business Phone= Number:
Home Phone Num= ber:
Type of Busine= ss:
Retail Business
Mail Order Business
Internet Based Busines= s
Personal Credi= t Rating:
Excellent
Good
Fair
Poor
How Soon Would= You Like a Merchant Account?


Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From ronyoung@nortelnetworks.com Sun Mar 4 20:33:38 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17129 for ; Sun, 4 Mar 2001 20:33:38 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sun, 4 Mar 2001 19:12:47 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sun, 4 Mar 2001 19:15:19 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id UAA11042 for ; Sun, 4 Mar 2001 20:04:31 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Sun, 4 Mar 2001 20:08:20 -0500 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Sun, 04 Mar 2001 20:04:11 -0500 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA04852 for ; Sun, 4 Mar 2001 17:59:13 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA00558 for ; Sun, 4 Mar 2001 18:04:04 -0700 (MST)] Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [10.238.80.11]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f25141i00484 for ; Mon, 5 Mar 2001 12:04:02 +1100 (EST) Received: (from kwchin@localhost) by beast.arc.corp.mot.com (8.10.2/8.10.2) id f25140731688 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Mar 2001 12:04:00 +1100 From: Kwan-Wu Chin Message-Id: <200103050104.f25140731688@beast.arc.corp.mot.com> Subject: TECHNICAL PROGRAM, IPDPS-2001 Workshops on PDC Issues in Wireless Networks To: MOBILE-IP@marvin.corpeast.baynetworks.com Date: Mon, 5 Mar 2001 12:04:00 +1100 (EST) X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: motgate3.mot.com X-SMTP-MAIL-FROM: kwchin@homer.arc.corp.mot.com X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: motgate3.mot.com [144.189.100.103] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit Dear Collegues, My applogies if you received multiple copies of this email. The following is the final technical program for the 1st IPDPS 2001 Workshop in San Francisco. Feel free to redistribute the technical program to your collegues. Hope to see you there Cheers Kwan-Wu Chin Communications and Networks Lab., Motorola Australia Research Centre, Sydney, Australia --------------------------------------------------------------------- 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS Hyatt Regency San Francisco April 23-27 , 2001 ******************************************************************* General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan J. Kumar, The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************************* Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Accepted papers will be published (by IEEE CS Press) in the proceedings of the IPDPS workshops. ========================================================================== Program Schedule Morning Session Adhoc Networks 9:30 am to 10:50 am Chair : TBA 1. Mesh-based Geocast Routing Protocols in Ad Hoc Networks J Boleng T Camp and V Tolety Colorado School of Mines 2. A Performance Comparison of Routing Protocols for Ad Hoc Wireless Networks. Azzedine Boukerche University of North Texas 3. An Efficient Routing Protocol for Hierarchical Ad-hoc Mobile Networks I. Chatzigiannakis, S. Nikoletseas and P. Spirakis Computer Technology Institute Patras, Greece 4. An Agent-based Protocol to Support Multimedia Communication in Ad Hoc Wireless Networks. R RoyChoudhary, K Paul and S Bandyopadhyay Pricewaterhouse Coopers Ltd. Calcutta India ---------------------------------------------- Sensor Networks 11:00 am to 12:00 --------------------------------------- 5. Time Synchronization for Wireless Sensor Networks J Elson and D Estrin ISI 6. Data Gathering in Sensor Networks using the Energy Delay Metric S Lindsay, C. Raghavendra The Aerospace Corporation and K. Sivalingam, The Washington State University 7. A Protocol for Enhanced Efficiency in Wireless Sensor Networks A Manjeshwar and DP Agrawal. University of Cincinnati ----------------------------------------------------- Key note Address and Lunch 12:00- 2:00 Keynote Speaker : TBD ========================================== 2:00 - 3:00 PM Architectures -------------------------------------- Chair: TBD ---------------- 8. Optimal Packet Scheduling in Tree-Structured LEO Satellite Clusters. M Bonucelli, F. Martelli and S Pelagatti, University of Pisa 9. DNS-based Architectures for an Efficient Management of Mobile User in Internet. M. Conti, E Gregori and S Martelli, Coniglio Nazionale delle Ricerche, Pisa Italy 10: Mobile Computing : Models, Programming Models and Software Models V K Murthy, Australian National University ---------------------------------------------- Mobile Environments 3:15 to 4:15 PM. ------------------------------------------- Chair : TBD --------------- 11. Double T-thresholds Location Cache Scheme for 3-level Database Architecture in PCS Networks Youn-Hee Han, Joon-Min Gil, Seung-Hee Hwang, Chong-Sun Hwang, and Young-Sik Jeong, Korea University 12. An end-to-end QoS Architecture for Mobile Hosts G. Le Grand and E Horlait, University of Paris France 13. Supporting Read-Only Transaction based on Asynchronous Invalidation Report in Mobile Environments. S-H Nam, I Y Chung and C-S Hwang --------------------------------------------------------------------- 4:15 - 4:45 Windup and "PDC issues in WNMC 2002" ------------------------------------------------------------------- =============================================================Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 6845 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au and Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Technical Program Committee Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Maurizio Bonuccelli, University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen, University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Cristina Pinotti, University of Trento, Italy Sotiris Nikoletseas, Computer Technology Institute, Greece Don Sannella, University of Edinburgh, Scotland Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Jie Wu, Florida Atlantic University, USA Yongbing Zhang, University of Tsukuba, Japan Albert Zomaya, University of Western Australia, Perth, Australia Steering Commitee --------------------- Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Nortel Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, USA Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas Computer Technology Institute From ronyoung@nortelnetworks.com Mon Mar 5 11:35:38 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20390 for ; Mon, 5 Mar 2001 11:35:38 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Mon, 5 Mar 2001 09:56:06 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Mon, 5 Mar 2001 10:00:15 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id KAA15223 for ; Mon, 5 Mar 2001 10:47:16 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Mon, 5 Mar 2001 10:51:13 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Mon, 05 Mar 2001 10:47:04 -0500 Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 07:47:03 -0800 (Pacific Standard Time) Received: from na-hub-03.redmond.corp.microsoft.com ([157.54.2.50]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 5 Mar 2001 07:46:20 -0800 Received: from corp-hub-02.redmond.corp.microsoft.com ([157.54.2.43]) by na-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 5 Mar 2001 07:46:20 -0800 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.41.18]) by corp-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 5 Mar 2001 07:46:16 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MIPv6 operating over IPv4 PPP links X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Date: Mon, 5 Mar 2001 15:46:11 -0000 Message-ID: Thread-Topic: MIPv6 operating over IPv4 PPP links Thread-Index: AcCli2XKcjBQimPnTeSQtz4pVm9WRw== From: "Greg O'Shea" To: mobile-ip@marvin.corpeast.baynetworks.com X-OriginalArrivalTime: 05 Mar 2001 15:46:16.0662 (UTC) FILETIME=[6A2B1760:01C0A58B] X-SMTP-HELO: mail2.microsoft.com X-SMTP-MAIL-FROM: gregos@microsoft.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: mail2.microsoft.com [131.107.3.124] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA20390 Using our experimental mobile IPv6 stack on Windows2000 we discover that a mobile IPv6 node can operate successfully over an IPv4 PPP link using the IPv4-compatible form of its V4-PPP address as its IPv6 care-of address. You can see details here: http://research.microsoft.com/programs/europe/projects/MIPv6.asp http://research.microsoft.com/programs/europe/projects/MIPv6Conf.asp#IPv 4-PPP It needs a little bit of manual help to get it set up, but in the absence of any drafts (that we know of) we're not sure if this is a legitimate thing to be doing in the first place. Does anyone know? Thx Greg From ronyoung@nortelnetworks.com Mon Mar 5 15:38:34 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03031 for ; Mon, 5 Mar 2001 15:38:34 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Mon, 5 Mar 2001 14:19:33 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Mon, 5 Mar 2001 14:22:11 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA20278 for ; Mon, 5 Mar 2001 15:11:54 -0500 (EST) Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com; Mon, 5 Mar 2001 15:09:25 -0500 Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5); Mon, 05 Mar 2001 15:11:26 -0500 Received: from cse.uta.edu ([129.107.10.238]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id NAA14021; Mon, 5 Mar 2001 13:50:48 -0600 (CST) Message-ID: <3AA326BC.C6FC74F0@cse.uta.edu> Date: Mon, 05 Mar 2001 13:40:12 +0800 From: Mohan Kumar Reply-To: kumar@cse.uta.edu Organization: CSE@UTA X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: cktoh , MOBILE-IP@marvin.corpeast.baynetworks.com, mahmoud , dpa , rkakarap , acampora , rao , yschen , jwcho , xli2 , sharony , jace , prkumar , mjammer , ieeetcpc , performance , tcos-announce , DMANET , ipng , iptel , int-serv , pmanzoni , youngko , asj , news-announce-conferences , "andras.valko" , tripathi , aashaikh , seapahn , miodrag , rohit_dube , das@cse.uta.edu, bahl@microsoft.com Original-To: cktoh , "randy\\"" <"randy"@eecs.berkeley.eduhaas@ee.cornell.edu\">, eroyer , wendi , djw , tudball , jj , mrp12 , ramanath , prasun , xgeorge , jkkim , singh , sjlee , mayo , sodini , arppe , mgbaker , hong , "L.Andrew" , "s.hanly" , yuenck , ananda , asctlau , asadas , peggy , tschudin , gminden , calvert , goodman , "Petri.Jokela" , javierg , "m.zukerman" , liny , gupta , bli , "J.crowcroft" , htchuah , ksk , liao , tye , lili , pretty , hasung , ccchiang , lin , kumar , aklmiu , snoeren , roryg , rstainov , cldavis , itc , tccc , tcgn , alg , cabernet-events , cost237-transport , kuvs-elg , manet , announce , testnet , calendar , SIGMOB , eapls-request , amast , dbworld , enternet , xtp-relay , MOBILE-IP , mahmoud , dpa , rkakarap , acampora , rao , yschen , jwcho , xli2 , sharony , jace , prkumar , mjammer , ieeetcpc , performance , tcos-announce , DMANET , ipng , iptel , int-serv , pmanzoni , youngko , asj , news-announce-conferences , "andras.valko" , tripathi , aashaikh , seapahn , miodrag , rohit_dube , das@cse.uta.edu, bahl@microsoft.com PP-Warning: Parse error in original version of preceding To line Subject: ACM's Fourth Annual International Workshop on WIRELESS MOBILE MULTIMEDIA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: cse.uta.edu X-SMTP-MAIL-FROM: kumar@cse.uta.edu X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: cse.uta.edu [129.107.12.1] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit First Call for Papers ACM's Fourth Annual International Workshop on WIRELESS MOBILE MULTIMEDIA July 21 2001, Rome, Italy (in conjunction with MobiCom 2001) URL: http://www.acm.org/sigmobile/workshops/2001/WoWMoM01/ IMPORTANT DATES: Submissions due: May 1, 2001 Notification of acceptance: June 5, 2001 Camera-ready version due: June 15, 2001 SCOPE: Technical papers describing previously unpublished, original, completed research, not currently under review by another conference or journal are solicited on the following topics: - Multimedia Network Architectures and Protocols - Quality-of-Service and Admission Control - Third and Forth Generation Systems - Video over Wireless Channels - Multimedia Applications - Wireless Network Evolution - Broadband Wireless - Wireless ATM - Multicasting in Wireless Services - Delay and Jitter Management for Multimedia Services - Synchronization of Multimedia Wireless services - Data and Header Compression Techniques - Mobility Management & Fast Handover Techniques - QoS Routing - WWW Browsing - Telemetry Services - Broadcast Data INTERNATIONAL PROGRAM COMMITTEE Hamid Aghvami, King's College London, U.K. Victor Bahl, Microsoft Research, U.S.A Andrew Campbell, Columbia University, U.S.A Marco Conti, CNUCE, Pisa, Italy Nigel Davies, Lancaster University, U.K. Lajos Hanzo, University of Southampton, U.K. Edward W. Knightly, Rice University, U.S.A Werner Mohr, Siemens AG Hiroyuki Morikawa, University of Tokyo, Japan George Polyzos, Athens University, Greece Adam Wolisz, Technical University of Berlin ---------------------------------------------------------------- From ronyoung@nortelnetworks.com Tue Mar 6 04:43:35 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05852 for ; Tue, 6 Mar 2001 04:43:34 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Tue, 6 Mar 2001 03:22:58 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Tue, 6 Mar 2001 03:26:55 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id DAA14597 for ; Tue, 6 Mar 2001 03:56:12 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Tue, 6 Mar 2001 03:59:49 -0500 Received: from ms.info.sh.cn. ( [203.95.7.153]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Tue, 06 Mar 2001 03:55:40 -0500 Received: from hyzhu ([172.16.12.10]) by ms.info.sh.cn. (8.10.1/8.10.1) with SMTP id f268eAa09981 for ; Tue, 6 Mar 2001 16:40:11 +0800 (GMT+0800) Message-ID: <000c01c0a61b$55495150$0a0c10ac@hyzhu> From: =?gb2312?B?1uy6o9H0?= To: MOBILE-IP@marvin.corpeast.baynetworks.com Date: Tue, 6 Mar 2001 16:56:28 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0A65E.62EF4B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-SMTP-HELO: ms.info.sh.cn. X-SMTP-MAIL-FROM: oceanchu@263.net X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: [203.95.7.153] X-Orig: X-Orig: X-Orig: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0A65E.62EF4B00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3Vic2NyaWJlDQo= ------=_NextPart_000_0009_01C0A65E.62EF4B00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5zdWJzY3JpYmU8L0ZPTlQ+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0009_01C0A65E.62EF4B00-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 16:06:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22652 for ; Wed, 7 Mar 2001 16:06:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07238; Wed, 7 Mar 2001 13:05:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12010; Wed, 7 Mar 2001 13:05:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27L3Z901552 for mobile-ip-dist; Wed, 7 Mar 2001 13:03:35 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27L3Q101545 for ; Wed, 7 Mar 2001 13:03:31 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15452 for ; Wed, 7 Mar 2001 16:03:15 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA06535 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 16:03:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25Ew4119213 for ; Mon, 5 Mar 2001 06:58:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20283 for ; Mon, 5 Mar 2001 06:58:04 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23002 for ; Mon, 5 Mar 2001 06:58:03 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f25Ew2g16291 for ; Mon, 5 Mar 2001 08:58:02 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 5 Mar 2001 08:58:02 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Mon, 5 Mar 2001 08:58:02 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321359C@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Draft Agenda for Mobile IP WG meeting at IETf50 Date: Mon, 5 Mar 2001 08:57:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Draft agenda for the Mobile IP WG meeting at IETF50 Thursday March 22nd - 9:00 AM - 11.30 AM ---------------------------------------- Agenda bashing 5 Mins WG Doc Status 5 Mins MIP at Connectathon - Report 5 Mins Mobile IPv6 Discussion 30 Mins - Issues/solutions related to security - Proposed updates for router advts - Other open issues Handoffs - Panel discussion 40 Mins - V6 handoff design team - V4 handoff design team Hierarchical Mobility Schemes 20 Mins Dynamic configuration of Mobile hosts 15 Mins Registration revocation 10 Mins QoS Discussion 10 Mins WG Charter review 10 Mins s/ ^\S*:\s+ / /; From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 17:30:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25088 for ; Wed, 7 Mar 2001 17:30:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12823; Wed, 7 Mar 2001 14:29:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11029; Wed, 7 Mar 2001 14:29:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27MQQ801864 for mobile-ip-dist; Wed, 7 Mar 2001 14:26:26 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27MQF101857 for ; Wed, 7 Mar 2001 14:26:16 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11227 for ; Wed, 7 Mar 2001 17:26:16 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08142 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 17:26:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25FD9119292 for ; Mon, 5 Mar 2001 07:13:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15243 for ; Mon, 5 Mar 2001 07:13:10 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02975 for ; Mon, 5 Mar 2001 07:13:09 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18845; Mon, 5 Mar 2001 07:13:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY12234; Mon, 5 Mar 2001 07:13:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04723; Mon, 5 Mar 2001 07:12:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15011.44283.769856.977491@thomasm-u1.cisco.com> Date: Mon, 5 Mar 2001 07:12:59 -0800 (PST) To: Cc: mat@cisco.com, hchaskar@hotmail.com, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, mobile-ip@marvin.corpeast.baynetworks.com Subject: [mobile-ip] RE: [seamoby] QoS and Mobile IP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hemant.Chaskar@nokia.com writes: > > => The solution of enclosing QoS Object in hop-by-hop > > extension header, preferably with binding messages, performs > > fast reservation on forward path. > > No it doesn't. If it needs to go clear back to the > correspondent node to change filter specs, you're > already too slow in the degeneate case. > > -----> No, you don't get the point still. You have to > -----> realize that packet carrying QoS object PRECEDES any > -----> data packets using new CoA. Please read the illustration that > -----> I gave in previous email again. Hence, QoS forwarding will > -----> be in place when these new CoA packets hit the intermediate > -----> routers. RSVP takes one round trip time for that. What makes you think that other packets will not overtake the qos establishment packet? FIB based forwarding is a whole lot faster than installing a reservation. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 17:38:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25293 for ; Wed, 7 Mar 2001 17:38:15 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16211; Wed, 7 Mar 2001 14:37:40 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17090; Wed, 7 Mar 2001 14:37:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27MZVN02083 for mobile-ip-dist; Wed, 7 Mar 2001 14:35:31 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27MZI102068 for ; Wed, 7 Mar 2001 14:35:19 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01241 for ; Wed, 7 Mar 2001 17:35:19 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08346 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 17:35:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25FvA119447 for ; Mon, 5 Mar 2001 07:57:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01129 for ; Mon, 5 Mar 2001 07:57:09 -0800 (PST) From: Hemant.Chaskar@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00541 for ; Mon, 5 Mar 2001 08:57:08 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f25Fv7g24995 for ; Mon, 5 Mar 2001 09:57:07 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 5 Mar 2001 09:57:07 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 5 Mar 2001 09:57:07 -0600 Message-ID: To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org Subject: [mobile-ip] Latency if QoS programming Date: Mon, 5 Mar 2001 09:57:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Some packets may overtake the packet carrying QoS information packet. But let us look at the following math. Assume that T is forwarding delay (not counting processing time required) for a hop. Let P be the processing time of PATH or RESV or QoS Object hop-by-hop option at a network node. Assume 3 hops in the end-to-end path that are concerned with programming QoS forwarding treatment. Let us look at the packet stream from CN to MN and let us count the number of packets at each of these nodes that would get default forwarding treatment due to lack of QoS forwarding information. Let us take the time difference between the potential arrival of first packet at a network node and the time QoS forwarding treatment is programmed at that node as an indication of number of packets that would get default forwarding treatment at that node. Let us indicate the node closest to CN by Node 1. I.e. I am assuming the following scenario CN--->Node 1---->Node 2---->Node 3--->MN. I am also assuming that PATH packet/QoS Object hop-by-hop option packet and first data packet arrive at Node 1 one after another. RSVP QoS object hop-by-hop option Node 1 3T+3P (for PATH) + 3T+3P (RESV) P Node 2 3T+3P (for PATH) + 2T+2P (RESV) T+2P Node 3 3T+3P (for PATH) + T+P (RESV) 2T+3P It can be seen that the latencies in second column (and hence number of packets getting default treatment) are much smaller that those the first one. Hemant Chaskar Nokia -----Original Message----- From: ext Michael Thomas [mailto:mat@cisco.com] Sent: 05. March 2001 10:13 To: Hemant.Chaskar@nokia.com Cc: mat@cisco.com; hchaskar@hotmail.com; mobile-ip@sunroof.eng.sun.com; seamoby@diameter.org; mobile-ip@marvin.corpeast.baynetworks.com Subject: RE: [seamoby] QoS and Mobile IP Hemant.Chaskar@nokia.com writes: > > => The solution of enclosing QoS Object in hop-by-hop > > extension header, preferably with binding messages, performs > > fast reservation on forward path. > > No it doesn't. If it needs to go clear back to the > correspondent node to change filter specs, you're > already too slow in the degeneate case. > > -----> No, you don't get the point still. You have to > -----> realize that packet carrying QoS object PRECEDES any > -----> data packets using new CoA. Please read the illustration that > -----> I gave in previous email again. Hence, QoS forwarding will > -----> be in place when these new CoA packets hit the intermediate > -----> routers. RSVP takes one round trip time for that. What makes you think that other packets will not overtake the qos establishment packet? FIB based forwarding is a whole lot faster than installing a reservation. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 17:44:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25419 for ; Wed, 7 Mar 2001 17:44:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18710; Wed, 7 Mar 2001 14:43:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18342; Wed, 7 Mar 2001 14:43:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27Mg3v02248 for mobile-ip-dist; Wed, 7 Mar 2001 14:42:03 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27Mfw102241 for ; Wed, 7 Mar 2001 14:41:58 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13914 for ; Wed, 7 Mar 2001 17:41:58 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08515 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 17:42:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25BhU118450 for ; Mon, 5 Mar 2001 03:43:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04087 for ; Mon, 5 Mar 2001 03:43:29 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05421 for ; Mon, 5 Mar 2001 04:43:28 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10796; Mon, 5 Mar 2001 06:43:26 -0500 (EST) Message-Id: <200103051143.GAA10796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-glass-mobileip-agent-dhcp-proxy-01.txt Date: Mon, 05 Mar 2001 06:43:26 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP Agents as DHCP Proxies Author(s) : S. Glass Filename : draft-glass-mobileip-agent-dhcp-proxy-01.txt Pages : 21 Date : 02-Mar-01 Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-01.txt 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-glass-mobileip-agent-dhcp-proxy-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-glass-mobileip-agent-dhcp-proxy-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: <20010302131744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-glass-mobileip-agent-dhcp-proxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131744.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 17:50:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25544 for ; Wed, 7 Mar 2001 17:50:54 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06082; Wed, 7 Mar 2001 14:50:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19693; Wed, 7 Mar 2001 14:50:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27MmIR02438 for mobile-ip-dist; Wed, 7 Mar 2001 14:48:18 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27MmD102429 for ; Wed, 7 Mar 2001 14:48:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03137 for ; Wed, 7 Mar 2001 17:48:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08642 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 17:48:17 -0500 (EST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f253mv116302 for ; Sun, 4 Mar 2001 19:48:58 -0800 (PST) Received: from emirgan (awe173-12.AWE.Sun.COM [192.29.173.12]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f253mu8691265; Sun, 4 Mar 2001 19:48:56 -0800 (PST) Date: Sun, 4 Mar 2001 19:38:39 -0800 (PST) From: Subject: [mobile-ip] Connectathon mobile and wireless talks To: mobile-ip@sunroof.eng.sun.com Cc: carl.williams@eng.sun.com In-Reply-To: "Your message with ID" <15010.53109.244043.829231@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, Connectathon network interoperability testing event is taking place in San Jose, California this week. In addition to Mobile IP testing, the event features a number of mobile and wireless related presentations which are open to public: Monday 5th March 2:00 - 2:30 TTCN-3 Test Environment in IPv6 Test - Peter Kremer (Ericsson) 2:30 - 3:00 Mobile IPv6 TAHI Conformance Test - Yukiyo Akisada (TAHI) 3:00 - 3:30 Lessons from implementing Mobile IPv4/Mobile Node - Yoshiyuki Tsuda (Toshiba) 3:30 - 3:45 Mobile IP limited private Address Support Implementation - Samita Chakrabarti (Sun Microsystems) Tuesday 6th March 4:00 - 4:30 Wireless Without a Net - Why I lose sleep over 802.11b - Christopher Hertel (University of Minnesota) Wednesday 7th March 4:00 - 4:30 Mobile IPv6 interaction issues with IPsec - Carl Williams, Mohan Parthasarathy, Alper Yegin (Sun Microsystems) 4:30 - 5:00 The Mobile IPv6 implementation on the InternetCAR project - Ryuji Wakikawa (Keio University) For location and more information check out www.cthon.org Alper E. Yegin Mobile IP Technology Coordinator Connectathon 2001 From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 17:53:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25605 for ; Wed, 7 Mar 2001 17:53:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23044; Wed, 7 Mar 2001 14:53:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09637; Wed, 7 Mar 2001 14:52:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27MpWs02550 for mobile-ip-dist; Wed, 7 Mar 2001 14:51:32 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27MpQ102543 for ; Wed, 7 Mar 2001 14:51:27 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15389 for ; Wed, 7 Mar 2001 17:51:25 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08704 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 17:51:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f255Su116841 for ; Sun, 4 Mar 2001 21:28:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07610 for ; Sun, 4 Mar 2001 21:28:55 -0800 (PST) From: Hemant.Chaskar@nokia.com Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15574 for ; Sun, 4 Mar 2001 22:28:54 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Mar 2001 14:20:26 +0900 Received: from charizard.diameter.org ([24.20.167.220]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 3 Mar 2001 04:29:17 +0900 Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f22IE1914277 for seamoby-list; Fri, 2 Mar 2001 10:14:01 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f22IDqT14266 for ; Fri, 2 Mar 2001 10:13:52 -0800 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f22INJw01921 for ; Fri, 2 Mar 2001 12:23:19 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 2 Mar 2001 12:20:33 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 2 Mar 2001 12:20:33 -0600 Message-ID: To: mat@cisco.com, hchaskar@hotmail.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, mobile-ip@marvin.corpeast.baynetworks.com Subject: [mobile-ip] RE: [seamoby] QoS and Mobile IP Date: Fri, 2 Mar 2001 12:20:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => The solution of enclosing QoS Object in hop-by-hop > extension header, preferably with binding messages, performs > fast reservation on forward path. No it doesn't. If it needs to go clear back to the correspondent node to change filter specs, you're already too slow in the degeneate case. -----> No, you don't get the point still. You have to -----> realize that packet carrying QoS object PRECEDES any -----> data packets using new CoA. Please read the illustration that -----> I gave in previous email again. Hence, QoS forwarding will -----> be in place when these new CoA packets hit the intermediate -----> routers. RSVP takes one round trip time for that. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 18:24:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26999 for ; Wed, 7 Mar 2001 18:24:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05524; Wed, 7 Mar 2001 15:24:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27141; Wed, 7 Mar 2001 15:23:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27NM5r03127 for mobile-ip-dist; Wed, 7 Mar 2001 15:22:05 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NM0103120 for ; Wed, 7 Mar 2001 15:22:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08039 for ; Wed, 7 Mar 2001 18:22:01 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09308 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 18:22:04 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f258Gb117426 for ; Mon, 5 Mar 2001 00:16:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05909 for ; Mon, 5 Mar 2001 00:16:37 -0800 (PST) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA01164 for ; Mon, 5 Mar 2001 00:16:37 -0800 (PST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Mar 2001 09:16:27 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCCDF@lat3721.rd.francetelecom.fr> From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] New I-D: draft-kassi-mobileip-dmi-00.txt Date: Mon, 5 Mar 2001 09:13:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A54C.385361A0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0A54C.385361A0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable We recently submitted an I-D, please send comments Thanks -----Message d'origine----- De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Envoy=E9 : vendredi 23 f=E9vrier 2001 12:43 Objet : I-D ACTION:draft-kassi-mobileip-dmi-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic Mobile IP (DMI) Author(s) : M. Kassi-Lahlou et al. Filename : draft-kassi-mobileip-dmi-00.txt Pages : 12 Date : 22-Feb-01 =09 This draft introduces a different mode for the mobility usage in IP networks. This mode does not modify the Mobile IP protocol specifications [2] but makes their use more dynamic according to the movements of the mobile node as far as its communications are = concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kassi-mobileip-dmi-00.txt 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-kassi-mobileip-dmi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-kassi-mobileip-dmi-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. ------_=_NextPart_000_01C0A54C.385361A0 Content-Type: message/rfc822 To: Subject: Date: Fri, 23 Feb 2001 13:55:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A54C.385361A0" ------_=_NextPart_002_01C0A54C.385361A0 Content-Type: text/plain ------_=_NextPart_002_01C0A54C.385361A0 Content-Type: application/octet-stream; name="ATT82310" Content-Disposition: attachment; filename="ATT82310" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222132817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kassi-mobileip-dmi-00.txt ------_=_NextPart_002_01C0A54C.385361A0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-kassi-mobileip-dmi-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A54C.385361A0-- ------_=_NextPart_000_01C0A54C.385361A0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 18:27:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27099 for ; Wed, 7 Mar 2001 18:27:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11903; Wed, 7 Mar 2001 15:26:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17555; Wed, 7 Mar 2001 15:26:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27NPEA03246 for mobile-ip-dist; Wed, 7 Mar 2001 15:25:14 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NP2103209 for ; Wed, 7 Mar 2001 15:25:03 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08533 for ; Wed, 7 Mar 2001 18:24:58 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09372 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 18:25:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f259IA117772 for ; Mon, 5 Mar 2001 01:18:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16765 for ; Mon, 5 Mar 2001 01:18:10 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25245 for ; Mon, 5 Mar 2001 01:18:09 -0800 (PST) Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id KAA08324 for ; Mon, 5 Mar 2001 10:18:08 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id KAA28460 for ; Mon, 5 Mar 2001 10:18:08 +0100 (MET) Message-ID: <3AA359D0.2B223E56@inrialpes.fr> Date: Mon, 05 Mar 2001 10:18:08 +0100 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: hmip and mobile routers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Sorry if you received this email twice or more, but it didn't get through the list, to my knowledge. This is a last attempt, now that the mobile-ip seems to (re)work] Hi, > Section 6 describes a mechanism of how mobile > routers might be supported by HMIP. However, I > think there is a fundamental category error being > made here. Namely, it is expected that behind the > mobile router are, in fact, mobile nodes. I agree with this and this was already pointed out on this list between 48 and 49th IETF. > reason why this expectation should be made: there > is no reason why a non-mobile widget, say a PC, > should not be able to be attached to a mobile > router on a moving train. As currently defined, > mobile IP is only a requirement if the device > (router, host) is itself mobile. I do not see why > we should expand that requirement to anything > which is *behind* something that is mobile. In > fact there could be a huge downsides to doing so, > not to mention a whole lot of uncharted territory. This question is addressed in my draft "Mobile Networks Support in Mobile" IPv6 (http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt). In this draft, the mobility of the network is completely transparent to all nodes located in the mobile network. Following your instance, the train is a mobile network and the gateway between the train and the Internet is a mobile router. The Mobile Router obtains a new care-of address at each new point of attachment to the Internet. There are basically 2 kinds of nodes in this mobile network: permanently fixed ones (TV screens, sensors, on-board computers, seats, ...) and mobile ones. Mobile ones may be composed of those belonging to the train (the ticket-collector ?), and some entering and leaving the train (Passengers, PDAs, Mobile Phones). In this proposal, Passengers get a care-of address when they enter the train (obvious), but they don't need to acquire a new care-of address every time the train is reachable from a new care-of address. IP mobility of the network is therefore hidden to them. I do see a benefit for Passengers to operate HMIP. In this case, the MAP would be located in the Mobile Router. On the other hand, it also seems obvious to me that fixed nodes should not operate HMIP. > Also: what happens if there is more than one > router in between MR and the stationary host > in MR's subnet? What happens if there's more > than one MR? What delineates "my" MR versus > somebody else's MR? See my draft as it does address Mobile Networks of arbitrary size (one or more subnets) > It's possible I'm misreading that section, but if > I am it's probably because the section doesn't say > what needs to happen when the mobile router itself > moves. I agree with Mickael that the HMIP draft does not elaborate much about this special case, but I must also advocate that it is not the object of the HMIP draft to discuss about it. As I see it, the HMIP draft only outline one instance where HMIP could be used: mobile nodes visiting a mobile network and I agree with this. For the more general case peculiar to mobile networks, I think that the debate turning around HMIP should now be left out of this thread. > However, even if nothing catastrophic > happens, my original issue still stands: > non-mobile hosts shouldn't be forced to become > mobile aware by virtue of a mobile router some > arbitrary number hops away. As said before, this question is covered by my proposal in draft-ernst-mobileip-v6-network-01.txt. The mobility of the network is transparent to all the nodes located in the mobile network. The Mobile Router is the only one that do manage mobility. The Mobile Router sends Binding Updates containing the prefix of the Mobile Network in addtion to a care-of address. See the draft for details. May I have your comments on my draft ? Thanks, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 18:30:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27214 for ; Wed, 7 Mar 2001 18:30:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14886; Wed, 7 Mar 2001 15:30:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18552; Wed, 7 Mar 2001 15:30:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27NSOU03413 for mobile-ip-dist; Wed, 7 Mar 2001 15:28:24 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NSI103399 for ; Wed, 7 Mar 2001 15:28:18 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09366 for ; Wed, 7 Mar 2001 18:28:18 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09435 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 18:28:21 -0500 (EST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f259rQ117952; Mon, 5 Mar 2001 01:53:27 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14129; Mon, 5 Mar 2001 10:53:17 +0100 (MET) Date: Mon, 5 Mar 2001 10:52:04 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: New idea for Router Sol/Adv and Mobility - NO new types To: "T.J. Kniveton" Cc: Erik Nordmark , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >> 1. The TTL of RS is < 255, which tells the HA it is from off-link. > > > > Or a spoofed RS. When a router receives a spoofed RS it would presumbly > > log an event and/or increase a counter. > > With your overloading proposal it can't tell the difference > > between a spoofed one and a mobile node using an RA. > > Enlighten me, how exactly does creating a new message type solve this > problem? It seems to me that it just shifts it to a different ICMP #. It doesn't make the spooing issue go away (I didn't claim it did) but allows the current rules for the current ICMP types to stay unchanged including any logging of ttl < 255 packets. The new message types need to have rules that deal with spoofing one way or another. But this might e.g. be to mandate some IP level security mechanism for all messages having the new types. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 18:33:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27389 for ; Wed, 7 Mar 2001 18:33:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17626; Wed, 7 Mar 2001 15:33:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19343; Wed, 7 Mar 2001 15:33:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27NVMU03548 for mobile-ip-dist; Wed, 7 Mar 2001 15:31:22 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NVD103528 for ; Wed, 7 Mar 2001 15:31:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09825 for ; Wed, 7 Mar 2001 18:31:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09497 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 18:31:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25Ggo119622 for ; Mon, 5 Mar 2001 08:42:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01598 for ; Mon, 5 Mar 2001 08:42:50 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29648 for ; Mon, 5 Mar 2001 09:42:49 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05489; Mon, 5 Mar 2001 08:42:49 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY13301; Mon, 5 Mar 2001 08:42:44 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04730; Mon, 5 Mar 2001 08:42:44 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15011.49667.842242.544452@thomasm-u1.cisco.com> Date: Mon, 5 Mar 2001 08:42:43 -0800 (PST) To: Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Latency if QoS programming In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hemant, I'd have a lot more sympathy for this argument if what you'd proposed is, essentially, RESV with router alert. As it stands, your proposal does not address: - multicast - flow merging - topology changes and localized healing - cryptographic identity - hopwise integrity - policy based admission control - flow aggregation - admission based diffserv - tunneling - mpls-te - the mapping to various L2's and probably a half a dozen other things I can't remember off the top of my head. In other words, in order to replace RSVP you are going to have to reinvent RSVP. I frankly find no motivation to do so, and in fact given recent developments I think that RSVP may be salvageable close to as-is and perform better than your proposal. Mike Hemant.Chaskar@nokia.com writes: > Some packets may overtake the packet carrying QoS information packet. But > let us look at the following math. Assume that T is forwarding delay (not > counting processing time required) for a hop. Let P be the processing time > of PATH or RESV or QoS Object hop-by-hop option at a network node. > > Assume 3 hops in the end-to-end path that are concerned with programming QoS > forwarding treatment. Let us look at the packet stream from CN to MN and let > us count the number of packets at each of these nodes that would get default > forwarding treatment due to lack of QoS forwarding information. Let us take > the time difference between the potential arrival of first packet at a > network node and the time QoS forwarding treatment is programmed at that > node as an indication of number of packets that would get default forwarding > treatment at that node. > > Let us indicate the node closest to CN by Node 1. I.e. I am assuming the > following scenario CN--->Node 1---->Node 2---->Node 3--->MN. I am also > assuming that PATH packet/QoS Object hop-by-hop option packet and first data > packet arrive at Node 1 one after another. > > > RSVP QoS object hop-by-hop option > > Node 1 3T+3P (for PATH) + 3T+3P (RESV) P > > Node 2 3T+3P (for PATH) + 2T+2P (RESV) T+2P > > Node 3 3T+3P (for PATH) + T+P (RESV) 2T+3P > > It can be seen that the latencies in second column (and hence number of > packets getting default treatment) are much smaller that those the first > one. > > Hemant Chaskar > Nokia > > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 05. March 2001 10:13 > To: Hemant.Chaskar@nokia.com > Cc: mat@cisco.com; hchaskar@hotmail.com; mobile-ip@sunroof.eng.sun.com; > seamoby@diameter.org; mobile-ip@marvin.corpeast.baynetworks.com > Subject: RE: [seamoby] QoS and Mobile IP > > > Hemant.Chaskar@nokia.com writes: > > > => The solution of enclosing QoS Object in hop-by-hop > > > extension header, preferably with binding messages, performs > > > fast reservation on forward path. > > > > No it doesn't. If it needs to go clear back to the > > correspondent node to change filter specs, you're > > already too slow in the degeneate case. > > > > -----> No, you don't get the point still. You have to > > -----> realize that packet carrying QoS object PRECEDES any > > -----> data packets using new CoA. Please read the illustration that > > -----> I gave in previous email again. Hence, QoS forwarding will > > -----> be in place when these new CoA packets hit the intermediate > > -----> routers. RSVP takes one round trip time for that. > > What makes you think that other packets will not > overtake the qos establishment packet? FIB based > forwarding is a whole lot faster than installing > a reservation. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 18:47:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27647 for ; Wed, 7 Mar 2001 18:47:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16193; Wed, 7 Mar 2001 15:46:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28087; Wed, 7 Mar 2001 15:46:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27Nirt03756 for mobile-ip-dist; Wed, 7 Mar 2001 15:44:53 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27Nim103749 for ; Wed, 7 Mar 2001 15:44:49 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22894 for ; Wed, 7 Mar 2001 18:44:48 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09571; Wed, 7 Mar 2001 18:34:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25HmQ119952 for ; Mon, 5 Mar 2001 09:48:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05752 for ; Mon, 5 Mar 2001 09:48:25 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17458 for ; Mon, 5 Mar 2001 09:48:23 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA01627; Mon, 5 Mar 2001 09:48:20 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY14577; Mon, 5 Mar 2001 09:48:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04739; Mon, 5 Mar 2001 09:48:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15011.53599.842031.961887@thomasm-u1.cisco.com> Date: Mon, 5 Mar 2001 09:48:15 -0800 (PST) To: Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Latency in QoS programming In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit *** Mail could not be accepted*** at onion.east.sun.com due to lack of disk space for temp file. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:01:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27955 for ; Wed, 7 Mar 2001 19:01:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21756; Wed, 7 Mar 2001 16:01:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01637; Wed, 7 Mar 2001 16:01:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27NxIr03931 for mobile-ip-dist; Wed, 7 Mar 2001 15:59:18 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NxC103921 for ; Wed, 7 Mar 2001 15:59:12 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12935 for ; Wed, 7 Mar 2001 18:59:12 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA10052 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 18:59:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25IY3120161 for ; Mon, 5 Mar 2001 10:34:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06909 for ; Mon, 5 Mar 2001 10:34:02 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA16432 for ; Mon, 5 Mar 2001 10:34:01 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Mar 5 13:33:23 EST 2001 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id NAA02806 for ; Mon, 5 Mar 2001 13:33:27 -0500 (EST) From: "Sandy Thuel" To: Subject: [mobile-ip] I-D on dynamic home addressing... Date: Mon, 5 Mar 2001 13:31:08 -0500 Message-ID: <002001c0a5a2$72295410$72f0b487@dnrc.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit For some unknown reason, the official announcement of the following draft never made it to the mailing list, although it is in the I-D repository. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic Home Addressing in Mobile IP using Transient Tunnels Author(s) : S. Thuel, L. Salgarelli, R. Ramjee, T. La Porta Filename : draft-thuel-mobileip-tt-01.txt Pages : 25 Date : 27-Feb-01 A mechanism is described to enable mobile nodes to be dynamically configured by DHCP servers in their home networks even when they are located in a foreign network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thuel-mobileip-tt-01.txt 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-thuel-mobileip-tt-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 From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:02:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27996 for ; Wed, 7 Mar 2001 19:02:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13173; Wed, 7 Mar 2001 16:01:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25861; Wed, 7 Mar 2001 16:01:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f27Nxuv03958 for mobile-ip-dist; Wed, 7 Mar 2001 15:59:56 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27Nxm103946 for ; Wed, 7 Mar 2001 15:59:49 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12983 for ; Wed, 7 Mar 2001 18:59:48 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09992; Wed, 7 Mar 2001 18:56:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25Hot119970 for ; Mon, 5 Mar 2001 09:50:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06627 for ; Mon, 5 Mar 2001 09:50:55 -0800 (PST) From: Hemant.Chaskar@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19965 for ; Mon, 5 Mar 2001 09:50:54 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f25Horg13201 for ; Mon, 5 Mar 2001 11:50:53 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 5 Mar 2001 11:50:50 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Mon, 5 Mar 2001 11:50:50 -0600 Message-ID: To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: Latency in QoS programming Date: Mon, 5 Mar 2001 11:50:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: *** Mail could not be accepted*** at onion.east.sun.com due to lack of disk space for temp file. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:05:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28078 for ; Wed, 7 Mar 2001 19:05:16 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23239; Wed, 7 Mar 2001 16:04:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07445; Wed, 7 Mar 2001 16:04:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2802os04092 for mobile-ip-dist; Wed, 7 Mar 2001 16:02:50 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2802h104077 for ; Wed, 7 Mar 2001 16:02:44 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13333 for ; Wed, 7 Mar 2001 19:02:44 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10125 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:02:47 -0500 (EST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NBc103068 for ; Wed, 7 Mar 2001 15:11:38 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f27NBcv391200 for ; Wed, 7 Mar 2001 15:11:38 -0800 (PST) Message-Id: <200103072311.f27NBcv391200@jurassic.eng.sun.com> Date: Wed, 7 Mar 2001 18:11:42 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] More list woes fixed. To: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, As you may have noticed, mobile-ip was throttled again due to another mail loop, this time during a cross-post to seamoby (I should have told Pat about the servers I removed from our list). To avoid more woes this close to the meeting, the throttling was me taking over moderation of mobile-ip, which I'm going to continue to do so until we're safely enough out of the potential email-looping woods; this close to the WG meeting that isn't likely to happen until after Minneapolis. I'm going through the backlog of about 35 or so more posts awaiting approval since early Monday. Some of them may be dups, which I'm trying to avoid. If you post, and don't see your email for a while, the reason may be because I haven't gotten to approving it yet (say until the next morning)... Cheers, Steve (owner-mobile-ip) From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:29:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28464 for ; Wed, 7 Mar 2001 19:29:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01280; Wed, 7 Mar 2001 16:29:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12452; Wed, 7 Mar 2001 16:29:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280RMG04428 for mobile-ip-dist; Wed, 7 Mar 2001 16:27:22 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280RH104421 for ; Wed, 7 Mar 2001 16:27:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15722 for ; Wed, 7 Mar 2001 19:27:17 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10609 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:27:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f25M19120976 for ; Mon, 5 Mar 2001 14:01:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26944 for ; Mon, 5 Mar 2001 14:01:08 -0800 (PST) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17016 for ; Mon, 5 Mar 2001 14:01:06 -0800 (PST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id RAA21199; Mon, 5 Mar 2001 17:01:05 -0500 (EST) From: "Andrew T. Campbell" To: Cc: "Andrew Campbell \(E-mail\)" Subject: [mobile-ip] SIGCOMM CCR Special Issue on Wireless Extensions to the Internet Date: Mon, 5 Mar 2001 17:00:05 -0800 Message-ID: <004701c0a5d8$c888c760$3d443b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Call for Papers ACM SIGCOMM Computer Communication Review http://www.acm.org/sigcomm/ccr/ Special Issue on Wireless Extensions to the Internet http://comet.columbia.edu/~campbell/ccr.htm Over the last several years there has been considerable interest in wireless extensions to the Internet from Industry and academia. The October 2001 issue of Computer Communication Review will be a special issue on wireless extensions to the Internet. The goal of the special issue is to present recent developments in wireless IP networks. We are soliciting full research papers, survey articles and work-in-progress on the following broad set of wireless IP topics: o Extensions to Mobile IP o Micro-Mobility Protocols o Wireless IP QOS o IP-based 3G Networks o Wireless LANs, PANs, MANETs, and Sensor Networks o TCP Performance over Wireless Networks o New Mobile and Wireless Applications o Mobile IP Telephony o Service-Enabled Wireless IP Gateways The submission details are as follows: Papers due: May 15, 2001. Authors notified: August 15, 2001. Camera ready due: September 15, 2001. Publication date: October 2001. All papers should be submitted electronically in PDF or Postscript form to the first guest editor listed below: Andrew T. Campbell Department of Electrical Engineering 1312 Seeley W. Mudd Bldg. Columbia University New York, NY 10027-6699 Email: campbell@comet.columbia.edu http://comet.columbia.edu/~campbell/ Mischa Schwartz Department of Electrical Engineering 1312 Seeley W. Mudd Bldg. Columbia University New York, NY 10027-6699 Email: schwartz@comet.columbia.edu http://www.ee.columbia.edu/people/schwartz.php3 From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:32:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28580 for ; Wed, 7 Mar 2001 19:32:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02294; Wed, 7 Mar 2001 16:32:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13097; Wed, 7 Mar 2001 16:32:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280UZJ04594 for mobile-ip-dist; Wed, 7 Mar 2001 16:30:35 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280UO104580 for ; Wed, 7 Mar 2001 16:30:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27846 for ; Wed, 7 Mar 2001 19:30:24 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10672 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:30:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f261di122010; Mon, 5 Mar 2001 17:39:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02686; Mon, 5 Mar 2001 17:39:44 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar3-182-130.dsl.gtei.net [4.33.182.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24775; Mon, 5 Mar 2001 17:39:42 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 05 Mar 2001 17:40:17 -0800 Received: from eagleswings [4.33.178.101] by smtp.tndh.net [4.33.182.130] (SLmail 3.2.3113) with SMTP id 8CBA9259A7E84DD597C9818DC4757E3F for plus 5 more; Mon, 05 Mar 2001 17:40:17 -0800 From: "Tony Hain" To: "Erik Nordmark" , "T.J. Kniveton" Cc: "Mattias Pettersson" , "Powell, Ken" , , Subject: [mobile-ip] RE: New idea for Router Sol/Adv and Mobility - NO new types Date: Mon, 5 Mar 2001 17:40:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: 3592BB7F-87704BCF-B1D3840E-30FB1A79 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On one hand I agree with Erik that new types are better than overloading the semantics unnecessarily. The basic problem I am having with this thread is understanding the problem it is trying to solve. Since the HA is required to be in all possible routing paths to my home subnet (else some parts of the world will never contact the node when it is mobile), it has to be a function of the last hop router. The premise of this proposal was that the MN would need to ask the HA for a prefix so it could configure its home address. Since it knows (presumably via configuration) the address of the HA, (and given the HA has to be in the routing path) it already has a useable prefix. I have always assumed that the MN is configured with its home prefix, then it would use the all-routers anycast address to find the HA. In this case the proposed messages are unnecessary. Clearly I need a picture to understand why the MN would know its HA, but not its home prefix. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Erik Nordmark Sent: Monday, March 05, 2001 1:52 AM To: T.J. Kniveton Cc: Erik Nordmark; Mattias Pettersson; Powell, Ken; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types > >> 1. The TTL of RS is < 255, which tells the HA it is from off-link. > > > > Or a spoofed RS. When a router receives a spoofed RS it would presumbly > > log an event and/or increase a counter. > > With your overloading proposal it can't tell the difference > > between a spoofed one and a mobile node using an RA. > > Enlighten me, how exactly does creating a new message type solve this > problem? It seems to me that it just shifts it to a different ICMP #. It doesn't make the spooing issue go away (I didn't claim it did) but allows the current rules for the current ICMP types to stay unchanged including any logging of ttl < 255 packets. The new message types need to have rules that deal with spoofing one way or another. But this might e.g. be to mandate some IP level security mechanism for all messages having the new types. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:38:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28667 for ; Wed, 7 Mar 2001 19:38:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12608; Wed, 7 Mar 2001 16:37:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13946; Wed, 7 Mar 2001 16:37:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280ZAE04767 for mobile-ip-dist; Wed, 7 Mar 2001 16:35:10 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280Z0104752 for ; Wed, 7 Mar 2001 16:35:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28389 for ; Wed, 7 Mar 2001 19:35:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10799 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:35:06 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2677U123812 for ; Mon, 5 Mar 2001 23:07:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07295 for ; Mon, 5 Mar 2001 23:07:31 -0800 (PST) Received: from hyse.grm.hia.no (hyse.grm.hia.no [128.39.202.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04370 for ; Mon, 5 Mar 2001 23:07:30 -0800 (PST) Received: from hyse.grm.hia.no ([128.39.202.21]) by hyse.grm.hia.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1PT5RY3Q; Tue, 6 Mar 2001 08:11:12 +0100 Received: from malle.siving.hia.no ([128.39.202.26]) by hyse.grm.hia.no (NAVIEG 2.1 bld 63) with SMTP id M2001030608111005338 for ; Tue, 06 Mar 2001 08:11:10 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Fast Handovers in MIPv6 - flags X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 6 Mar 2001 08:07:24 +0100 Message-ID: <64AD1AC95D52D311AEB700500483F00004400803@malle.siving.hia.no> Thread-Topic: Fast Handovers in MIPv6 - flags Thread-Index: AcClwfZGeyn3+jbtQViaUtwElGZ3vQ== From: =?iso-8859-1?Q?J=F8rn_Hunskaar?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2677V123813 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Fast Handovers for MIPv6 (draft-ietf-mobileip-fast-mipv6-00.txt) suggests that the Binding Update Option should be changed by adding two more flags, B and U, to the flag bits. The intention is to indicate that the mobile node would like the (old) access router to do bicasting and buffering. The draft also specifies that the access router MAY honor these requests or reject them silently. When a BU is sent to the oldAR, the traffic will be redirected to the MN by the way of the newAR. Since a fast handover procedure has been initiated (either through a RtSolPr or PrRtAdv message), the MN would like the handover to be fast and with a small packet loss. Consequently, both the B and U bit will probably be set by the MN to improve the handover quality. In other words, the MN will set the bits to make the handover as fast as possible. If these requests are silently ignored by the oldAR (when the MN is a part of a fast handover procedure), this is most likely due to link-layer conditions or because of insufficient resources. Why use these bits in the Binding Update Option when they probably will be set all the time anyway? Maybe supporting bicasting and buffering should be made mandatory in the oldAR when using fast handovers? Regards, Jorn From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:41:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28762 for ; Wed, 7 Mar 2001 19:41:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16731; Wed, 7 Mar 2001 16:41:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10143; Wed, 7 Mar 2001 16:41:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280dID04913 for mobile-ip-dist; Wed, 7 Mar 2001 16:39:18 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280dD104906 for ; Wed, 7 Mar 2001 16:39:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17138 for ; Wed, 7 Mar 2001 19:39:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10883 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:39:18 -0500 (EST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f268IJ124005; Tue, 6 Mar 2001 00:18:20 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA00163; Tue, 6 Mar 2001 09:18:12 +0100 (MET) Date: Tue, 6 Mar 2001 09:16:57 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] RE: New idea for Router Sol/Adv and Mobility - NO new types To: alh-ietf@tndh.net Cc: Erik Nordmark , "T.J. Kniveton" , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Clearly I need a > picture to understand why the MN would know its HA, but not its home prefix. While the MN must know at least one home prefix it might not know all of them in particular it might not know about any new prefixes that have been introduced while the MN was away from home. So it needs to be able to get the complete list including the current lifetimes for the prefixes. Of course, if all the home prefixes that the MN knows expire due to renumbering then the MN is in deep trouble. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:44:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28825 for ; Wed, 7 Mar 2001 19:44:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19874; Wed, 7 Mar 2001 16:44:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15529; Wed, 7 Mar 2001 16:43:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280fvJ05048 for mobile-ip-dist; Wed, 7 Mar 2001 16:41:57 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280fo105034 for ; Wed, 7 Mar 2001 16:41:51 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17327 for ; Wed, 7 Mar 2001 19:41:50 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA10937 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:41:55 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f269nK124363; Tue, 6 Mar 2001 01:49:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25747; Tue, 6 Mar 2001 01:49:07 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25045; Tue, 6 Mar 2001 01:49:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f269mjd38107; Tue, 6 Mar 2001 10:48:55 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA13602; Tue, 6 Mar 2001 10:48:45 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f269mhA55544; Tue, 6 Mar 2001 10:48:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103060948.f269mhA55544@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: alh-ietf@tndh.net cc: "Erik Nordmark" , "T.J. Kniveton" , "Mattias Pettersson" , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: New idea for Router Sol/Adv and Mobility - NO new types In-reply-to: Your message of Mon, 05 Mar 2001 17:40:16 PST. Date: Tue, 06 Mar 2001 10:48:43 +0100 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => this thread was completely messed by the mobile-ip mailing list bug: I believe a summary is needed in order to understand ideas and their chain. On one hand I agree with Erik that new types are better than overloading the semantics unnecessarily. The basic problem I am having with this thread is understanding the problem it is trying to solve. => look at my intro (:-). Since the HA is required to be in all possible routing paths to my home subnet (else some parts of the world will never contact the node when it is mobile), it has to be a function of the last hop router. => not exactly. The Home Agent (HA) must be attached to the home link. If the home link doesn't physically exist then (and only then) your statement applies. The premise of this proposal was that the MN would need to ask the HA for a prefix so it could configure its home address. => the issue is home link renumbering, in particular when the Mobile Node (MN) is down for a very long period. This is a real problem but there are far more important problems, for instance the abyssal performance of secure mobile IPv6 when a MN is booted in visit (of course having to learn the HA address and the home address will not improve this). This thread assumes that: - the home link is often renumbered - DNS is not available in the visit network (if it is available then you need only to configure a name as proposed by Compaq folks) - home AAA is not available (if it is available then HA and home address allocation may/should be done by AAA) - statefull autoconfig will never be available! Since it knows (presumably via configuration) the address of the HA, (and given the HA has to be in the routing path) it already has a useable prefix. I have always assumed that the MN is configured with its home prefix, then it would use the all-routers anycast address to find the HA. In this case the proposed messages are unnecessary. Clearly I need a picture to understand why the MN would know its HA, but not its home prefix. => there is a dedicated anycast address for HAs (because if HAs are routers, not all routers are HAs). I agree this topic is a secondary one and we should throw it into the for further studies stuff. Of course, I'll strongly object if this is slowing down the mobile IPv6 draft (BTW, is there an I-D 14?). Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:47:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28866 for ; Wed, 7 Mar 2001 19:47:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23467; Wed, 7 Mar 2001 16:47:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11211; Wed, 7 Mar 2001 16:47:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280jbK05217 for mobile-ip-dist; Wed, 7 Mar 2001 16:45:37 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280jV105206 for ; Wed, 7 Mar 2001 16:45:32 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17706 for ; Wed, 7 Mar 2001 19:45:31 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11064 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:45:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Beh124844 for ; Tue, 6 Mar 2001 03:40:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26891 for ; Tue, 6 Mar 2001 03:40:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07513 for ; Tue, 6 Mar 2001 03:40:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07232; Tue, 6 Mar 2001 06:40:41 -0500 (EST) Message-Id: <200103061140.GAA07232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-04.txt Date: Tue, 06 Mar 2001 06:40:40 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-04.txt Pages : 12 Date : 05-Mar-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering a care-of address to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to distribute such security information to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-04.txt 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-mobileip-aaa-key-04.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-mobileip-aaa-key-04.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: <20010305124550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305124550.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:50:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28928 for ; Wed, 7 Mar 2001 19:50:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26371; Wed, 7 Mar 2001 16:49:58 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11722; Wed, 7 Mar 2001 16:49:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280mAo05303 for mobile-ip-dist; Wed, 7 Mar 2001 16:48:10 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280m4105293 for ; Wed, 7 Mar 2001 16:48:05 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17969 for ; Wed, 7 Mar 2001 19:48:04 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11119 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:48:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Bel124852 for ; Tue, 6 Mar 2001 03:40:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26916 for ; Tue, 6 Mar 2001 03:40:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00077 for ; Tue, 6 Mar 2001 03:40:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07244; Tue, 6 Mar 2001 06:40:46 -0500 (EST) Message-Id: <200103061140.GAA07244@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-02.txt Date: Tue, 06 Mar 2001 06:40:45 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Hierarchical MIPv6 mobility management Author(s) : H. Soliman, C. Castelluccia, K. Malki, L. Bellier Filename : draft-ietf-mobileip-hmipv6-02.txt Pages : 26 Date : 05-Mar-01 This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-02.txt 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-mobileip-hmipv6-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-mobileip-hmipv6-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: <20010305124600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-hmipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-hmipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305124600.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:53:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28964 for ; Wed, 7 Mar 2001 19:53:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29422; Wed, 7 Mar 2001 16:52:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06154; Wed, 7 Mar 2001 16:52:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280ojl05434 for mobile-ip-dist; Wed, 7 Mar 2001 16:50:45 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280oc105420 for ; Wed, 7 Mar 2001 16:50:38 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18215 for ; Wed, 7 Mar 2001 19:50:38 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11172 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:50:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26Bet124860 for ; Tue, 6 Mar 2001 03:40:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29272 for ; Tue, 6 Mar 2001 03:40:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07594 for ; Tue, 6 Mar 2001 03:40:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07264; Tue, 6 Mar 2001 06:40:50 -0500 (EST) Message-Id: <200103061140.GAA07264@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc2002-bis-04.txt Date: Tue, 06 Mar 2001 06:40:50 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-04.txt Pages : 99 Date : 05-Mar-01 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-04.txt 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-mobileip-rfc2002-bis-04.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-mobileip-rfc2002-bis-04.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: <20010305124704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305124704.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:55:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28994 for ; Wed, 7 Mar 2001 19:55:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09932; Wed, 7 Mar 2001 16:54:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12603; Wed, 7 Mar 2001 16:54:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280r5L05558 for mobile-ip-dist; Wed, 7 Mar 2001 16:53:05 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280r0105548 for ; Wed, 7 Mar 2001 16:53:00 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29964 for ; Wed, 7 Mar 2001 19:52:59 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11225 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:53:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26GEN125873 for ; Tue, 6 Mar 2001 08:14:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01700 for ; Tue, 6 Mar 2001 08:14:23 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07448 for ; Tue, 6 Mar 2001 09:14:21 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f26GEJC11200 for ; Tue, 6 Mar 2001 17:14:19 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 06 17:15:53 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Mar 2001 17:10:27 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBDE@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] updated drafts Date: Tue, 6 Mar 2001 17:14:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, Last Friday, I submitted two drafts: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-02.txt and another updated draft on the use of AAA for Key distribution: draft-soliman-mobileip-routeopt-mipv6-01.txt The latter was presented in San Diego. Changes in HMIPv6 : - Re-ordering of the different chapters - Additional text in for Basic and Extended mode for further clarification. - Added a new chapter on load balancing in HMIPv6 The draft allows for per-connection, per-flow or per-packet load balancing. We look forward to receiving your comments on this chapter. - Added additional text and a flag in the MAP option for better support of Mobile Networks. - Additional clarification in the MAP selection chapter. The HMIPv6 draft is currently on the MIP WG web page. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 19:57:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29037 for ; Wed, 7 Mar 2001 19:57:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10973; Wed, 7 Mar 2001 16:57:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13257; Wed, 7 Mar 2001 16:57:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f280tfb05707 for mobile-ip-dist; Wed, 7 Mar 2001 16:55:41 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280tX105695 for ; Wed, 7 Mar 2001 16:55:34 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18686 for ; Wed, 7 Mar 2001 19:55:33 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11277 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 19:55:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f26KMS127167; Tue, 6 Mar 2001 12:22:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06615; Tue, 6 Mar 2001 12:22:27 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03768; Tue, 6 Mar 2001 12:22:26 -0800 (PST) Received: from Kniveton.com (nokia-3.Connectathon.ORG [130.128.65.3]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f26KKnb43793; Tue, 6 Mar 2001 12:20:49 -0800 (PST) Message-ID: <3AA5464C.C65029C1@Kniveton.com> Date: Tue, 06 Mar 2001 12:19:24 -0800 From: root Organization: NOKIA Research X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-1-mip i686) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: alh-ietf@tndh.net, Erik Nordmark , Mattias Pettersson , "Powell, Ken" , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: New idea for Router Sol/Adv and Mobility - NO new types References: <200103060948.f269mhA55544@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > => this thread was completely messed by the mobile-ip mailing list bug: > I believe a summary is needed in order to understand ideas and > their chain. You might be able to find the thread on the IPng group since I crossposted there. My message which describes the problem is "New idea for Router Sol/Adv and Mobility," which should fill you in. If you can't find that, let me know and I will forward some of the messages to you. > On one hand I agree with Erik that new types are better than overloading the > semantics unnecessarily. The basic problem I am having with this thread is > understanding the problem it is trying to solve. > > => look at my intro (:-). > > Since the HA is required to be in all possible routing paths to my > home subnet (else some parts of the world will never contact the node > when it is mobile), it has to be a function of the last hop router. > > => not exactly. The Home Agent (HA) must be attached to the home link. > If the home link doesn't physically exist then (and only then) your > statement applies. > > The premise of this proposal was that the MN would need to ask the > HA for a prefix so it could configure its home address. Although you might be able to configure *an* home address using the router's prefix, you are supposed to be able to configure *all* home addresses while away from home. The value of this flexibility is debatable, but it certainly seems like a good thing to be able to configure at least more than one address. > > > => the issue is home link renumbering, in particular when the Mobile > Node (MN) is down for a very long period. This is a real problem > but there are far more important problems, for instance the abyssal > performance of secure mobile IPv6 when a MN is booted in visit > (of course having to learn the HA address and the home address will > not improve this). There is a couple of issues. The home link being renumbered while the MN is off, is a subject that I have filed into "for future study" under the rubrick "Mobile Node Bootstrap Problem." However, this thread addresses a more specific problem, which is that Tunneled Router Advertisements, as currently defined in the draft, a. Will *not *work when a MN does not yet have its Home Address b. Add an IPv6-in-IPv6 encapsulation header which is unnecessary There may be more reasons, but these two, especially (a), are probably sufficient to merit solving this problem now (IMHO). > > This thread assumes that: > - the home link is often renumbered > - DNS is not available in the visit network (if it is available > then you need only to configure a name as proposed by Compaq folks) > - home AAA is not available (if it is available then HA and home address > allocation may/should be done by AAA) > - statefull autoconfig will never be available! Sorry, I may have mixed the discussion of these two issues -- mobile bootstrap (for which you did a good job of describing the assumptions), and fleshing out the Tunneled Router Adv/Sol as my original message in this thread describes. It is also noteworthy that the latter does not solve the former, though they are connected; future work is necessary to come up with a general, palatable solution to bootstrapping. > > Since it knows (presumably via configuration) the address of the > HA, (and given the HA has to be in the routing path) it already has a > useable prefix. I have always assumed that the MN is configured with its > home prefix, then it would use the all-routers anycast address to find the > HA. In this case the proposed messages are unnecessary. Clearly I need a > picture to understand why the MN would know its HA, but not its home prefix. > > => there is a dedicated anycast address for HAs (because if HAs are routers, > not all routers are HAs). > I agree this topic is a secondary one and we should throw it into the > for further studies stuff. Of course, I'll strongly object if this is > slowing down the mobile IPv6 draft (BTW, is there an I-D 14?). > > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 20:09:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29189 for ; Wed, 7 Mar 2001 20:09:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAB14553; Wed, 7 Mar 2001 17:08:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21170; Wed, 7 Mar 2001 17:08:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2816tm06012 for mobile-ip-dist; Wed, 7 Mar 2001 17:06:55 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2816o106005 for ; Wed, 7 Mar 2001 17:06:50 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19851 for ; Wed, 7 Mar 2001 20:06:50 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA11498 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 20:06:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f27NpC103882 for ; Wed, 7 Mar 2001 15:51:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04427 for ; Wed, 7 Mar 2001 15:51:13 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26524 for ; Wed, 7 Mar 2001 15:51:12 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f27NpBd02025 for ; Thu, 8 Mar 2001 00:51:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 08 00:51:10 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 00:52:46 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBFD@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: hmip and mobile routers Date: Thu, 8 Mar 2001 00:51:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I don't know if this mail will make it, but I'll try. I'm not sure who sent the original mail because I only received Thierry's response. > > Section 6 describes a mechanism of how mobile > > routers might be supported by HMIP. However, I > > think there is a fundamental category error being > > made here. Namely, it is expected that behind the > > mobile router are, in fact, mobile nodes. > => There is no error in that. If they are not mobile nodes then HMIPv6 does not solve that problem. Clearly there are two cases to consider, a) the nodes behind a router have (H)MIPv6 implementation b) They don't HMIPv6 addresses a and not b. Thierry's draft addresses b and not a. In case "a" if the MNs use HMIPv6 they will receive route optimised traffic. In the other case they won't Both solutions an definitely coexist. The MR can always update its HA with the entire mobile network's prefix. Also the MN's attached to it can update the CNs/other MAP about their COA. > > reason why this expectation should be made: there > > is no reason why a non-mobile widget, say a PC, > > should not be able to be attached to a mobile > > router on a moving train. > => Yes that's possible, we don't address this case. > As currently defined, > > mobile IP is only a requirement if the device > > (router, host) is itself mobile. I do not see why > > we should expand that requirement to anything > > which is *behind* something that is mobile. In > > fact there could be a huge downsides to doing so, > > not to mention a whole lot of uncharted territory. > => What is the down side ? This is an unfinished statement. > > Also: what happens if there is more than one > > router in between MR and the stationary host > > in MR's subnet? > => The MAP option is propagated as usual. > What happens if there's more > > than one MR? > => What happens if there is more than one AR ? > What delineates "my" MR versus > > somebody else's MR? > => What delineates my AR vs someone else's AR ? Not a MIP issue. > > It's possible I'm misreading that section, but if > > I am it's probably because the section doesn't say > > what needs to happen when the mobile router itself > > moves. > => The section says that the MAP (MR) sends a MAP option to the "mobile network" with its on link CoA (LCoA) as the MAP address. Does it need more explanation ? We can add more. > > However, even if nothing catastrophic > > happens, my original issue still stands: > > > > non-mobile hosts shouldn't be forced to become > > mobile aware by virtue of a mobile router some > > arbitrary number hops away. > => Does the draft say that ? Please let us know where it does so we can remove that assumption. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 20:11:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29273 for ; Wed, 7 Mar 2001 20:11:50 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15625; Wed, 7 Mar 2001 17:11:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21858; Wed, 7 Mar 2001 17:11:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2819eG06072 for mobile-ip-dist; Wed, 7 Mar 2001 17:09:40 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2819Z106065 for ; Wed, 7 Mar 2001 17:09:35 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20039 for ; Wed, 7 Mar 2001 20:09:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA11562 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 20:09:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2801q104012 for ; Wed, 7 Mar 2001 16:01:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25871 for ; Wed, 7 Mar 2001 16:01:51 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20059 for ; Wed, 7 Mar 2001 16:01:50 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2801fC14424 for ; Thu, 8 Mar 2001 01:01:41 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 08 01:01:40 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 00:57:48 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBFF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: hmip and mobile routers Date: Thu, 8 Mar 2001 01:01:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Thierry, I think we agree that the two drafts are solving two different scenarios for the same problem. > This question is addressed in my draft "Mobile Networks Support in > Mobile" IPv6 > (http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt). > > In this draft, the mobility of the network is completely transparent to > all nodes located in the mobile network. Following your instance, > the train is a mobile network and the gateway between the train and the > Internet is a mobile router. The Mobile Router obtains a new care-of > address at each new point of attachment to the Internet. There are > basically 2 kinds of nodes in this mobile network: permanently fixed > ones (TV screens, sensors, on-board computers, seats, ...) and mobile > ones. Mobile ones may be composed of those belonging to the train > (the ticket-collector ?), and some entering and leaving the train > (Passengers, PDAs, Mobile Phones). > > In this proposal, Passengers get a care-of address when they enter the > train (obvious), but they don't need to acquire a new care-of address > every time the train is reachable from a new care-of address. IP > mobility of the network is therefore hidden to them. > > I do see a benefit for Passengers to operate HMIP. In this case, the > MAP would be located in the Mobile Router. > => The benefit is receiving route optimised packets. Having said that, not every device on earth will have a MIP implementation so as I said earlier, this is valid fo devices that are fixed. However for MNs other optimisations in HMIPv6 are proposed. > I agree with Mickael that the HMIP draft does not elaborate much about > this special case, but I must also advocate that it is not the object of > the HMIP draft to discuss about it. As I see it, the HMIP draft only > outline one instance where HMIP could be used: mobile nodes visiting a > mobile network and I agree with this. > => We do support both for "HMIP MNs or routers". Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 20:19:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29329 for ; Wed, 7 Mar 2001 20:19:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17848; Wed, 7 Mar 2001 17:19:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12105; Wed, 7 Mar 2001 17:19:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f281H8Q06289 for mobile-ip-dist; Wed, 7 Mar 2001 17:17:08 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f281Gw106276 for ; Wed, 7 Mar 2001 17:16:58 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20767 for ; Wed, 7 Mar 2001 20:16:57 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA11707 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 20:17:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f280q1105487 for ; Wed, 7 Mar 2001 16:52:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16497 for ; Wed, 7 Mar 2001 16:52:01 -0800 (PST) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28934 for ; Wed, 7 Mar 2001 16:52:00 -0800 (PST) Received: from ABC (abc.ctr.columbia.edu [128.59.66.159]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id TAA20567 for ; Wed, 7 Mar 2001 19:51:59 -0500 (EST) From: "Xiaowei Zhang" To: Subject: [mobile-ip] P-MIP ns source code Date: Wed, 7 Mar 2001 19:52:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit We have recently released the ns source code for P-MIP at: http://comet.columbia.edu/pmip/ P-MIP supports (simple) paging extensions for Mobile IP. There is also a technical report on the performance and analysis of P-MIP based on the ns code. "P-MIP: Paging Extensions for Mobile IP ," Xiaowei Zhang, Javier G. Castellanos, and Andrew T. Campbell, technical report, Aug. 2000. You can find the paper and ID on the P-MIP web page. Xiaowei Zhang http://comet.columbia.edu/~xzhang From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 20:46:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29601 for ; Wed, 7 Mar 2001 20:45:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06367; Wed, 7 Mar 2001 17:45:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27243; Wed, 7 Mar 2001 17:45:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f281ggE06490 for mobile-ip-dist; Wed, 7 Mar 2001 17:42:42 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f281ga106480 for ; Wed, 7 Mar 2001 17:42:36 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22815 for ; Wed, 7 Mar 2001 20:42:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA12209 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 20:42:40 -0500 (EST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f281Yo106434 for ; Wed, 7 Mar 2001 17:34:50 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f281Ylv426920 for ; Wed, 7 Mar 2001 17:34:48 -0800 (PST) Message-Id: <200103080134.f281Ylv426920@jurassic.eng.sun.com> Date: Wed, 7 Mar 2001 20:34:52 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] Backlog posted. To: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, I've managed to get through the backlog, and everything I've seen has been posted, and is on its way to a mail server near you. If you didn't see something you posted between Sunday and today at 2000EST/1700PST, then you're going to have to repost it. Again, so the list remains 'up', it's going to be hand-throttled (read: moderated), so you wont see your post until after I do! Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 7 20:50:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29695 for ; Wed, 7 Mar 2001 20:50:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26297; Wed, 7 Mar 2001 17:50:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26219; Wed, 7 Mar 2001 17:50:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f281lSj06626 for mobile-ip-dist; Wed, 7 Mar 2001 17:47:29 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f281l9106599 for ; Wed, 7 Mar 2001 17:47:10 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04835 for ; Wed, 7 Mar 2001 20:47:08 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA12301 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Mar 2001 20:47:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f281f7106464 for ; Wed, 7 Mar 2001 17:41:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26688 for ; Wed, 7 Mar 2001 17:41:07 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02451 for ; Wed, 7 Mar 2001 17:41:07 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA12676 for ; Wed, 7 Mar 2001 17:41:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACC09441; Wed, 7 Mar 2001 17:41:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA11022; Wed, 7 Mar 2001 17:41:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15014.58162.109450.233716@thomasm-u1.cisco.com> Date: Wed, 7 Mar 2001 17:41:06 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: hmip and mobile routers In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBBFD@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBBFD@esealnt448.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > I don't know if this mail will make it, but I'll try. > > I'm not sure who sent the original mail because I > only received Thierry's response. C'est moi. > > > Section 6 describes a mechanism of how mobile > > > routers might be supported by HMIP. However, I > > > think there is a fundamental category error being > > > made here. Namely, it is expected that behind the > > > mobile router are, in fact, mobile nodes. > > > => There is no error in that. If they are not mobile > nodes then HMIPv6 does not solve that problem. > Clearly there are two cases to consider, > > a) the nodes behind a router have (H)MIPv6 implementation > b) They don't Yes, but they could just as easily be mobile nodes behind mobile routers where the mobile router functions as a home agent for those mobile nodes, ad infinitum. I don't think that HMIP brings much special to that situation: any place that you could put MIP, you can also put HMIP, but that should go without saying. In other words, this doesn't look any different that multiple layers of hierarchy. Case (b) is what I would consider to be the "mobile router" problem. > HMIPv6 addresses a and not b. Thierry's draft > addresses b and not a. Thierry's draft addresses one aspect of (b), but probably not the whole story. It may have gotten lost in the email meltdown, but I wrote a long post about some of the detrimental aspects of the home address destination option, one of which is (b). I'll probably repost it. > > As currently defined, > > > mobile IP is only a requirement if the device > > > (router, host) is itself mobile. I do not see why > > > we should expand that requirement to anything > > > which is *behind* something that is mobile. In > > > fact there could be a huge downsides to doing so, > > > not to mention a whole lot of uncharted territory. > > > => What is the down side ? This is an unfinished > statement. Did you read the planet-earth-behind-a-mobile- router question? I thought it was part of this post, but maybe it got clipped by the time you saw it. > > > Also: what happens if there is more than one > > > router in between MR and the stationary host > > > in MR's subnet? > > > => The MAP option is propagated as usual. > > > What happens if there's more > > > than one MR? > > > => What happens if there is more than one AR ? Well, that's easy. I forward packets to the first one, and I immediately lose track of what happens from there on out. In the layered ([H]MIP) case, it would seem that each mobile might need to deal with binding updates to the HA for each time a mobile router moves too. If this isn't what you mean, it's probably because the draft is unclear, and in either case it would be good to clean in up to be explicit with the interactions. > => The section says that the MAP (MR) sends a MAP > option to the "mobile network" with its on link > CoA (LCoA) as the MAP address. > Does it need more explanation ? We can add > more. What is the mobile network? What happens if the mobile network in turn contains a mobile router? Is it a flood fill? What do the mobile nodes need to do when a mobile router of a mobile router moves? > > > non-mobile hosts shouldn't be forced to become > > > mobile aware by virtue of a mobile router some > > > arbitrary number hops away. > > > => Does the draft say that ? Please let us know > where it does so we can remove that assumption. The draft doesn't make a differentiation between (a) and (b). I'm not convinced that (b) is very well understood, however, but that's probably not HMIP's fault (other than claiming to support mobile routers and accidentally stepping on a large land mine). Mike From ronyoung@nortelnetworks.com Wed Mar 7 20:55:26 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29784 for ; Wed, 7 Mar 2001 20:55:26 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Wed, 7 Mar 2001 19:42:41 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Wed, 7 Mar 2001 19:46:35 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id UAA22439 for ; Wed, 7 Mar 2001 20:33:40 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Wed, 7 Mar 2001 20:37:40 -0500 Received: from Fusberta.Elet.PoliMi.IT (fusberta.elet.polimi.it [131.175.21.8]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Wed, 07 Mar 2001 20:33:26 -0500 Received: from host localhost and sender wmi2001@localhost; by mail relay Fusberta.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier CAA24007; on date and time Thu, 8 Mar 2001 02:31:57 +0100 (MET). Date: Thu, 8 Mar 2001 02:31:57 +0100 (MET) From: Wireless Mobile Internet 2001 To: Wireless Mobile Internet 2001 Subject: Wireless Mobile Internet Workshop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: Fusberta.Elet.PoliMi.IT X-SMTP-MAIL-FROM: wmi2001@fusberta.elet.polimi.it X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: fusberta.elet.polimi.it [131.175.21.8] X-Orig: X-Orig: X-Orig: [Sorry if this is a duplicate email] CALL FOR PAPER: WIRELESS MOBILE INTERNET ======================================== The first ACM Wireless Mobile Internet Workshop will take place in conjunction with the International Conference on Mobile Computing and Networking, Mobicom 2001, to be held in Rome, Italy, on July 16-21, 2001. This is an excellent opportunity to participate in two events covering a wide range of research in mobile computing and Internet related technologies. The workshop will be one-day long. It is a single track event and will have presentation of selected and invited papers as well as a panel discussion. Important dates: ---------------- - April 1, 2001: Electronic Paper Submission Deadline - May 30, 2001: Acceptance/Rejection Notification - July 21, 2001: Workshop day Conference site and email ------------------------- http://cerbero.elet.polimi.it/wmi2001 wmi2001@fusberta.elet.polimi.it Submission Instructions: ------------------------ http://cerbero.elet.polimi.it/wmi2001/subm.html Journal publication: -------------------- Selected workshop papers will be considered for publication on a Special Issue of the Journal "Wireless Communications and Mobile Computing", Wiley Publ. Workshop general objectives --------------------------- This workshop will explore the emerging area of Wireless Mobile Internet. The tremendous success of Internet related technologies coupled with higher wireless access speeds promised by new and emerging technologies and standards such as GPRS, EDGE and UMTS brings about opportunities to support new applications and services. The emergence of highly miniaturized, compact, and sophisticated Personal Digital Assistance (PDA) devices brought about by advances in display technologies, circuit design, and embedded software technologies together with promises of wireless access to the Internet brings about new frontiers in usage and applications which represent what has come to be known as pervasive computing. The workshop focuses on major aspects of this revolution, with focus on problems related to IP-based mobile Internet and problems related to the wireless access to the Internet. On the networking front, the emergence of mobility has introduced new challenging problems such as QOS, control, management and routing. The emergence of new wireless access technologies, ranging from Bluetooth to UMTS and satellite systems confronts us on how to smoothly merge these diverse technologies. Together, they offer new capabilities to applications such as mobile commerce, information retrieval and such. This workshop will be the first open forum to address these problems. Leaders and thinkers of the field from academia, industry and research laboratories will assemble to share their views on technical problems and pave the road for the visions of tomorrow. Detailed workshop topics ------------------------ Authors are invited to submit original papers describing current research and visions of the future. Papers should address issues related to wireless internet protocols, services and platforms, as well as issues regarding transmission, access, and mobility technologies specifically designed to support Internet traffic and applications. A list of detailed topics includes, but is not limited to: - Access protocols and modulation schemes - Network architectures for wireless Internet access - mobility management mechanisms - Handover and admission control - Traffic models for wireless internet applications - QoS support in wireless access networks. - Performance enhancements of Internet protocols over wireless links - Power efficiency - Mobile services, applications, middleware - Security and billing - Internet Appliances Organizing Committee: - Giuseppe Bianchi, University of Palermo, Italy, bianchi@elet.polimi.it - Parviz Kermani, IBM T.J. Watson Res. Center, NY, USA, parviz@us.ibm.com - Silvano Pupolin, University of Padova, Italy, pupolin@fiore.dei.unipd.it Technical Program Committee: - Andrea Baiocchi, University La Sapienza, Rome, Italy (baiocchi@infocom.uniroma1.it) - Pravin Bhagwat, ATT Research, USA (pravinb@research.att.com) - Giuseppe Bianchi, University of Palermo, Italy (bianchi@elet.polimi.it) - Chatschik Bisdikian, IBM T.J. Watson Research Center, NY, USA (bisdik@us.ibm.com) - Shyam S. Chakraborty, Helsinky University of Technologies, Finland (Shyam.Chakraborty@hut.fi) - Francesca Cuomo, University La Sapienza, Rome, Italy (franci@infocom.uniroma1.it) - Gabor Fodor, Ericsson Telecommunications, Sweden (Fodor@era-t.ericsson.se) - Zygmunt Haas, Cornell University, USA (zjh1@cornell.edu) - Sung-Ju Lee, Hewlett-Packard Labs, USA (sjlee@hpl.hp.com) - Nitin Vaidya, Texam A&M University, USA (vaidya@cs.tamu.edu) - Lorenzo Vangelista, Telital, Italy (lorenzo.vangelista@telital.it) From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 15:31:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12031 for ; Thu, 8 Mar 2001 15:31:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28653; Thu, 8 Mar 2001 12:30:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09597; Thu, 8 Mar 2001 12:30:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28KSi310336 for mobile-ip-dist; Thu, 8 Mar 2001 12:28:44 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28KSc110325 for ; Thu, 8 Mar 2001 12:28:38 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09533 for ; Thu, 8 Mar 2001 15:28:37 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA04109 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 15:28:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f289AX108031 for ; Thu, 8 Mar 2001 01:10:33 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15964 for ; Thu, 8 Mar 2001 01:10:33 -0800 (PST) Received: from mailbreak.com ([216.207.225.170]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19575 for ; Thu, 8 Mar 2001 01:10:32 -0800 (PST) Received: from eshim by mailbreak.com with SMTP (MDaemon.v3.5.2.R) for ; Thu, 08 Mar 2001 03:55:20 -0500 Message-ID: <016001c0a7af$39ee5550$6501a8c0@nyc.solidstreaming.net> From: "Eunsoo Shim" To: Cc: "Richard D. Gitlin" , "Eunsoo Shim" Subject: [mobile-ip] New I-D, Reliable and Scalable Mobile IP Regional Registration Date: Thu, 8 Mar 2001 04:07:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Return-Path: eunsoo@ctr.columbia.edu X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, We submitted a new I-D. Title : Reliable and Scalable Mobile IP Regional Registration Author(s) : Eunsoo Shim, Richard D. Gitlin Filename : draft-shim-reliable-reg-reg-00.txt Pages : 12 Date : 08-Mar-01 It is available also at the following URL: http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-reliable-reg-reg-00.t xt http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-reliable-reg-reg-00.p df Fllowing is the abstract: We propose a mechanism that allows local registration of a mobile node for a handoff within the same visited domain in a reliable and scalable way. This mechanism is an extension of the base Mobile IP and the Mobile IP Regional Registration protocols. The key ideas include allowing registration via a group of care of addresses for a mobile node, where there is a primary care of address to which the home agent forwards the packets for the mobile node. Each care of address corresponds to a gateway foreign agent, which share a trust relationship. Peer gateway foreign agents and the foreign agents monitor failure of a gateway foreign agent. When the gateway foreign agent corresponding to the primary care of address fails, one of the peer gateway foreign agent corresponding to a secondary care of address takes over the role of the failed gateway foreign agent and initiates update of the registration status automatically. When all gateway foreign agents fail, the foreign agents disable regional registration automatically. Thank you. Eunsoo From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:35:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14056 for ; Thu, 8 Mar 2001 16:35:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24397; Thu, 8 Mar 2001 13:34:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25788; Thu, 8 Mar 2001 13:34:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28LXFY10687 for mobile-ip-dist; Thu, 8 Mar 2001 13:33:15 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LXA110678 for ; Thu, 8 Mar 2001 13:33:11 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21668 for ; Thu, 8 Mar 2001 16:33:09 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05357 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:33:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f289vl108213 for ; Thu, 8 Mar 2001 01:57:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26259 for ; Thu, 8 Mar 2001 01:57:47 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00389 for ; Thu, 8 Mar 2001 01:57:45 -0800 (PST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 0283C931 for ; Thu, 8 Mar 2001 10:55:54 +0100 (CET) Received: from 6wind.com (intranet [10.0.0.113]) by intranet.6wind.com (Postfix) with ESMTP id 66DC6B470 for ; Thu, 8 Mar 2001 10:57:48 +0100 (CET) Message-ID: <3AA7579C.C34D9D31@6wind.com> Date: Thu, 08 Mar 2001 10:57:48 +0100 From: Alain RITOUX Organization: 6WIND X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-6.1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobileIPv6 and IKE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi everybody. I'm interested in the combinasion of mobileipv6 and its mandatory IPsec, and I was wondering about the IKE usage. Between ther MN and its HA, the BU need to be authenticated, hence an SA must exist, but the HA can't speak with the MN, until the Co@ is known, hence the BU accepted. So how can IKE work ? - Is there a solution for this chicken-an-egg pb ? - If yes, is it standard ? Moreover, while reading a few drafts/RFC (mobility support in IPv6, destination option header clarification, IIPv6 ...) I'm getting a little bit cionfused about the IPv6 header extension order, or about where MUST/SHOULD/LMAY? be Dest options wrt various Destination Option Headers. Is there something stable ? mandatory ? btw I'm interested in any good material/references about those subjects. If you feel, this subject should rather be discussed on other lists (IPsec ? IPng ? ....), just let me know. Best regards. Alain. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:38:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14174 for ; Thu, 8 Mar 2001 16:38:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04893; Thu, 8 Mar 2001 13:37:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26420; Thu, 8 Mar 2001 13:37:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28LaMc10752 for mobile-ip-dist; Thu, 8 Mar 2001 13:36:22 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LaH110743 for ; Thu, 8 Mar 2001 13:36:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22097 for ; Thu, 8 Mar 2001 16:36:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05421 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:36:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28A7J108246 for ; Thu, 8 Mar 2001 02:07:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21553 for ; Thu, 8 Mar 2001 02:07:19 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04276 for ; Thu, 8 Mar 2001 02:07:17 -0800 (PST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id B57968ED for ; Thu, 8 Mar 2001 11:05:27 +0100 (CET) Received: from 6wind.com (unknown [10.16.0.123]) by intranet.6wind.com (Postfix) with ESMTP id 8A3C8B470 for ; Thu, 8 Mar 2001 11:07:21 +0100 (CET) Message-ID: <3AA75A1A.BFB71AA@6wind.com> Date: Thu, 08 Mar 2001 11:08:26 +0100 From: Alain Ritoux X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobileIPv6 and IKE. References: <20010306082558.2870.qmail@web1604.mail.yahoo.com> <3AA4A210.1C3CC982@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi everybody, (the first sending seemed to get a nasty end : my excuses if you get this msg twice). I'm interested in securing the MobileIPv6 exchanges, with the mandatory IPsec, and hence with IKE. The BU sent by the MN to its HA must ne authenticated, henc need an SA, but the HA can't speak to the MN untill the BU is accepted. How can IKE take place in such conditions ? Is there a solution to this chicken-and-egg pb ? If yes, is it a standard ? going to be one ? Moreover while reading variuos RFC and drafts (mobility support for IPv6, Destination option header clarification, IPv6 soecs ..) I'm getting a little bit confused about the IPv6 extension headers order, or the real place some destination option may/should/must? take place wrt various destination options headers? Is there also something stbale ? standard ? for this. btw I'm interested in any good material/references about those subjects. If you feel, some subject should be discussed elswhere (IPsec? IPng ? ...), let me knwon. Best regards. Alain. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:40:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14248 for ; Thu, 8 Mar 2001 16:40:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27001; Thu, 8 Mar 2001 13:40:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01969; Thu, 8 Mar 2001 13:40:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28Lch310827 for mobile-ip-dist; Thu, 8 Mar 2001 13:38:43 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28Lcc110820 for ; Thu, 8 Mar 2001 13:38:38 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22562 for ; Thu, 8 Mar 2001 16:38:37 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05476 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:38:42 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28B3k108440 for ; Thu, 8 Mar 2001 03:03:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01339 for ; Thu, 8 Mar 2001 03:03:46 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28807 for ; Thu, 8 Mar 2001 03:03:45 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f28B3hd23964 for ; Thu, 8 Mar 2001 12:03:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 08 12:03:24 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 12:05:00 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC02@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: hmip and mobile routers Date: Thu, 8 Mar 2001 12:01:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > Section 6 describes a mechanism of how mobile > > > > routers might be supported by HMIP. However, I > > > > think there is a fundamental category error being > > > > made here. Namely, it is expected that behind the > > > > mobile router are, in fact, mobile nodes. > > > > > => There is no error in that. If they are not mobile > > nodes then HMIPv6 does not solve that problem. > > Clearly there are two cases to consider, > > > > a) the nodes behind a router have (H)MIPv6 implementation > > b) They don't > > Yes, but they could just as easily be mobile nodes > behind mobile routers where the mobile router functions > as a home agent for those mobile nodes, ad infinitum. > I don't think that HMIP brings much special to that > situation: > => It brings the MAP entity which can offer you a COA. > any place that you could put MIP, you > can also put HMIP, but that should go without saying. > => This is a bit difficult to follow. But yes wherever you have MIP you MAY also have HMIP. Should we stop saying that ? :) > In other words, this doesn't look any different > that multiple layers of hierarchy > => That's the way it is for the MR case. > Case (b) is what I would consider to be the "mobile > router" problem. > => One basic aim is to be reached via your HA and another more ambitious one is to not have triangular routing. Two different issues and we address one of them. > > > As currently defined, > > > > mobile IP is only a requirement if the device > > > > (router, host) is itself mobile. I do not see why > > > > we should expand that requirement to anything > > > > which is *behind* something that is mobile. In > > > > fact there could be a huge downsides to doing so, > > > > not to mention a whole lot of uncharted territory. > > > > > => What is the down side ? This is an unfinished > > statement. > > Did you read the planet-earth-behind-a-mobile- > router question? > => No and even if I read these words they still need to be decrypted and put into MIP context. > > > > Also: what happens if there is more than one > > > > router in between MR and the stationary host > > > > in MR's subnet? > > > > > => The MAP option is propagated as usual. > > > > > What happens if there's more > > > > than one MR? > > > > > => What happens if there is more than one AR ? > > Well, that's easy. I forward packets to the first one, > and I immediately lose track of what happens from there on out. > In the layered ([H]MIP) case, it would seem that each mobile > might need to deal with binding updates to the > HA for each time a mobile router moves too. > => MIP requires that you update the HA when your CoA changes. This is not an HMIP problem. HMIP provides the CoA that can be used for route optimised packets. If the MN doesn't want to use it, it doesn't have to and no updates to the HA are required when the MR moves. > If this isn't what you mean, it's probably > because the draft is unclear, and in either > case it would be good to clean in up to be > explicit with the interactions. > => we can make it more detailed, but you should read the latest verson first to see if it still needs cleaning up. If so we're happy to clean up a bit more. > > => The section says that the MAP (MR) sends a MAP > > option to the "mobile network" with its on link > > CoA (LCoA) as the MAP address. > > Does it need more explanation ? We can add > > more. > > What is the mobile network? What happens if > the mobile network in turn contains a mobile > router? > => A MR is a router obviously. It sends RAs that include the MAP option. Have you read the dynamic MAP discovery section ? It's explained there. > Is it a flood fill? > => Please have a look at the section I mentioned above. Maybe the Extended mode doesn't repeat the MAP discovery part, but it's there. > What do the mobile > nodes need to do when a mobile router of a > mobile router moves? > => Get a new CoA, send BUs. Standard MIPv6 > > > > non-mobile hosts shouldn't be forced to become > > > > mobile aware by virtue of a mobile router some > > > > arbitrary number hops away. > > > > > => Does the draft say that ? Please let us know > > where it does so we can remove that assumption. > > The draft doesn't make a differentiation > between (a) and (b). > => Ok we can add something to show we only support (a). Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:44:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14310 for ; Thu, 8 Mar 2001 16:44:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10454; Thu, 8 Mar 2001 13:43:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07971; Thu, 8 Mar 2001 13:43:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28Lf6h10933 for mobile-ip-dist; Thu, 8 Mar 2001 13:41:06 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28Lex110918 for ; Thu, 8 Mar 2001 13:40:59 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01811 for ; Thu, 8 Mar 2001 16:40:57 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05529 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:41:02 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28BtE108579 for ; Thu, 8 Mar 2001 03:55:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04894 for ; Thu, 8 Mar 2001 03:55:14 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08953 for ; Thu, 8 Mar 2001 04:55:13 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22054; Thu, 8 Mar 2001 06:55:12 -0500 (EST) Message-Id: <200103081155.GAA22054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-reg-tunnel-04.txt Date: Thu, 08 Mar 2001 06:55:11 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Regional Registration Author(s) : E. Gustafsson, J. Montenegro, C. Perkins Filename : draft-ietf-mobileip-reg-tunnel-04.txt Pages : 35 Date : 07-Mar-01 Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a new kind of 'regional' registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-04.txt 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-mobileip-reg-tunnel-04.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-mobileip-reg-tunnel-04.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: <20010307141825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-tunnel-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141825.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:52:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14502 for ; Thu, 8 Mar 2001 16:52:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17889; Thu, 8 Mar 2001 13:52:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29480; Thu, 8 Mar 2001 13:52:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28LoZ211119 for mobile-ip-dist; Thu, 8 Mar 2001 13:50:35 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LoU111110 for ; Thu, 8 Mar 2001 13:50:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24738 for ; Thu, 8 Mar 2001 16:50:29 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05717 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:50:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28G9Z109320 for ; Thu, 8 Mar 2001 08:09:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05694 for ; Thu, 8 Mar 2001 08:09:36 -0800 (PST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15433 for ; Thu, 8 Mar 2001 08:09:33 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA11042 for ; Thu, 8 Mar 2001 10:09:12 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f28G7pr01711 for ; Thu, 8 Mar 2001 10:07:51 -0600 (CST) Message-ID: <3AA7AF19.5E1F5BFE@usa.alcatel.com> Date: Thu, 08 Mar 2001 10:11:05 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Backlog posted. References: <200103080134.f281Ylv426920@jurassic.eng.sun.com> Content-Type: multipart/mixed; boundary="------------D7DA8D35629269CE02649AFA" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------D7DA8D35629269CE02649AFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, This is what Pat does for Seamoby list, I think. So east coast people wont get their postings in the morning until the afternoon. This is only one problem with manually controlled distribution. Regards, Steven Glass - Solaris Software wrote: > > Again, so the list remains 'up', it's going to be hand-throttled (read: > moderated), so you wont see your post until after I do! > > Cheers, > Steve --behcet --------------D7DA8D35629269CE02649AFA Content-Type: text/x-vcard; charset=us-ascii; name="behcet.sarikaya.vcf" Content-Description: Card for Behcet Sarikaya Content-Disposition: attachment; filename="behcet.sarikaya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sarikaya;Behcet tel;fax:972-9965714 tel;work:972-9965075 x-mozilla-html:FALSE org:Alcatel Corporate Research Center;Network Architecture version:2.1 email;internet:Behcet.Sarikaya@usa.alcatel.com adr;quoted-printable:;;1201 E. Campbell Rd, CTO2=0D=0A;Richardson;Texas;75081-1936;USA x-mozilla-cpt:;-1616 fn:Behcet Sarikaya end:vcard --------------D7DA8D35629269CE02649AFA-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 16:56:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14621 for ; Thu, 8 Mar 2001 16:56:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03984; Thu, 8 Mar 2001 13:55:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11460; Thu, 8 Mar 2001 13:55:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28LrCF11178 for mobile-ip-dist; Thu, 8 Mar 2001 13:53:12 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28Lr6111167 for ; Thu, 8 Mar 2001 13:53:06 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03775 for ; Thu, 8 Mar 2001 16:53:02 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05770 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:53:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28GKZ109356 for ; Thu, 8 Mar 2001 08:20:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14673 for ; Thu, 8 Mar 2001 08:20:34 -0800 (PST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08910 for ; Thu, 8 Mar 2001 08:20:34 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA13857 for ; Thu, 8 Mar 2001 10:20:32 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f28GK7r09000 for ; Thu, 8 Mar 2001 10:20:07 -0600 (CST) Message-ID: <3AA7B1F8.B79A0291@usa.alcatel.com> Date: Thu, 08 Mar 2001 10:23:20 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: hmip and mobile routers References: <034BEFD03799D411A59F00508BDF7546013DBBFF@esealnt448.al.sw.ericsson.se> Content-Type: multipart/mixed; boundary="------------D0EBFD4779783477CBA36570" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------D0EBFD4779783477CBA36570 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hesham and Michael, My suggestion is to drop the part on mobile routers in hmipv6. This may clear the way for a separate RFC on mobile routers, probably based on Thierry's I-D. I think that the extended mode of hmipv6 could still stand. --behcet --------------D0EBFD4779783477CBA36570 Content-Type: text/x-vcard; charset=us-ascii; name="behcet.sarikaya.vcf" Content-Description: Card for Behcet Sarikaya Content-Disposition: attachment; filename="behcet.sarikaya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sarikaya;Behcet tel;fax:972-9965714 tel;work:972-9965075 x-mozilla-html:FALSE org:Alcatel Corporate Research Center;Network Architecture version:2.1 email;internet:Behcet.Sarikaya@usa.alcatel.com adr;quoted-printable:;;1201 E. Campbell Rd, CTO2=0D=0A;Richardson;Texas;75081-1936;USA x-mozilla-cpt:;-1616 fn:Behcet Sarikaya end:vcard --------------D0EBFD4779783477CBA36570-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:01:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14712 for ; Thu, 8 Mar 2001 17:01:20 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06409; Thu, 8 Mar 2001 14:01:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07118; Thu, 8 Mar 2001 14:00:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28LxST11330 for mobile-ip-dist; Thu, 8 Mar 2001 13:59:28 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LxN111323 for ; Thu, 8 Mar 2001 13:59:23 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26174 for ; Thu, 8 Mar 2001 16:59:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA05894 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 16:59:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28GWG109402 for ; Thu, 8 Mar 2001 08:32:16 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13500 for ; Thu, 8 Mar 2001 08:32:17 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA08178 for ; Thu, 8 Mar 2001 08:32:16 -0800 (PST) Message-Id: <200103081632.IAA08178@heliopolis.Eng.Sun.COM> Date: Thu, 8 Mar 2001 08:32:16 -0800 (PST) From: James Kempf Subject: Re: [mobile-ip] More list woes fixed. To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 16yE4wo6p/jZiheA92jO6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Steve, Pat put an IP level filter on the domain in Korea that was looping. They can't get any packets in or out, but thems the breaks if they choose to behave in such a bad way. jak >Date: Wed, 7 Mar 2001 18:11:42 -0500 (EST) >From: Steven Glass - Solaris Software >Subject: [mobile-ip] More list woes fixed. >To: mobile-ip@sunroof.eng.sun.com >Mime-Version: 1.0 >List-Archive: >List-Owner: >List-Subscribe: >List-Unsubscribe: > > Folks, > > As you may have noticed, mobile-ip was throttled again due to another mail >loop, this time during a cross-post to seamoby (I should have told Pat about the >servers I removed from our list). To avoid more woes this close to the meeting, >the throttling was me taking over moderation of mobile-ip, which I'm going to >continue to do so until we're safely enough out of the potential email-looping >woods; this close to the WG meeting that isn't likely to happen until after >Minneapolis. > > I'm going through the backlog of about 35 or so more posts awaiting approval >since early Monday. Some of them may be dups, which I'm trying to avoid. If >you post, and don't see your email for a while, the reason may be because I >haven't gotten to approving it yet (say until the next morning)... > > Cheers, > Steve > (owner-mobile-ip) From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:04:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14839 for ; Thu, 8 Mar 2001 17:04:40 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29102; Thu, 8 Mar 2001 14:04:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14203; Thu, 8 Mar 2001 14:04:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28M1vQ11387 for mobile-ip-dist; Thu, 8 Mar 2001 14:01:57 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28M1q111380 for ; Thu, 8 Mar 2001 14:01:52 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05292 for ; Thu, 8 Mar 2001 17:01:51 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA05948 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:01:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28GjZ109496 for ; Thu, 8 Mar 2001 08:45:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12253 for ; Thu, 8 Mar 2001 08:45:35 -0800 (PST) From: Phil_Neumiller@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23381 for ; Thu, 8 Mar 2001 09:45:34 -0700 (MST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f28Gi7012496 for ; Thu, 8 Mar 2001 08:44:07 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f28GjUI00115 for ; Thu, 8 Mar 2001 08:45:30 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A09.005C337A ; Thu, 8 Mar 2001 08:47:04 -0800 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A09.005C30CA.00@hqoutbound.ops.3com.com> Date: Thu, 8 Mar 2001 10:44:26 -0600 Subject: [mobile-ip] AAA/QOS in MIP and SeaMoby Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I know this message will be perceived by some as flame bait. I don't want it to be. Please don't flame me. I have a very basic question about the MIP and SeaMoby charters. Why do things that are clearly operational and that are client server in nature get included into a routing or transport WG such as MIP or SeaMoby? Why can't AAA server specific stuff be done somewhere else like say a AAA group? Tying AAA specifically to a particular macromobility implementation seems like a very bad design approach to me. It seems like it is being done to placate particular vendors' interests to me. The QoS argument holds a bit more water than AAA. Mixing stuff into the MIP group seems to defocus the routing aspects and muddy up the AAA and QoS aspects a bit. Ultimately, it seems MIP should be absorbed into IP anyway and that should be the ultimate design goal i.e. making MIP go away, so hanging ornaments on it is just going to prolong our agony in making it go away. In general I don't think the router fabric for the global Internet should be tied so much to the penchants of 3G vendors or operators. Thanks, Phil Neumiller From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:11:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15002 for ; Thu, 8 Mar 2001 17:11:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05117; Thu, 8 Mar 2001 14:11:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04800; Thu, 8 Mar 2001 14:11:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28M9Yl11589 for mobile-ip-dist; Thu, 8 Mar 2001 14:09:34 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28M9T111582 for ; Thu, 8 Mar 2001 14:09:29 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28575 for ; Thu, 8 Mar 2001 17:09:28 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06127 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:09:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28Hde109663 for ; Thu, 8 Mar 2001 09:39:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06065 for ; Thu, 8 Mar 2001 09:39:40 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12661 for ; Thu, 8 Mar 2001 09:39:39 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 8 Mar 2001 11:33:05 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 11:38:05 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301706829@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Latency if QoS programming Date: Thu, 8 Mar 2001 11:38:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7F6.855D1FC0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A7F6.855D1FC0 Content-Type: text/plain; charset="iso-8859-1" I agree with Michael and we should make no mistake that if all of the issues(requirements/assumptions) are the same, it will be a re-invention of the wheel. Are people working with different requirements. An AS might be in order before people spend their time on PDUs. I believe this relates to the 3GPP question of: I want a fairly inexpensive mobile to be able to communicate with QoS to a host behind a T1 of a small corporate network. Bandwidth over the T1 is signaled using RSVP. The mobile is using some "access specific" mechanisms. Diff-serv is in the middle. How will it work unless it is mandated that the network can signal the mobile in an access specific way or the mobile itself is mandated to interwork RSVP and the access specific protocol? respectfully to you all, Glenn -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, March 05, 2001 10:43 AM To: Hemant.Chaskar Cc: mat@cisco.com; mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Latency if QoS programming Hemant, I'd have a lot more sympathy for this argument if what you'd proposed is, essentially, RESV with router alert. As it stands, your proposal does not address: - multicast - flow merging - topology changes and localized healing - cryptographic identity - hopwise integrity - policy based admission control - flow aggregation - admission based diffserv - tunneling - mpls-te - the mapping to various L2's and probably a half a dozen other things I can't remember off the top of my head. In other words, in order to replace RSVP you are going to have to reinvent RSVP. I frankly find no motivation to do so, and in fact given recent developments I think that RSVP may be salvageable close to as-is and perform better than your proposal. Mike Hemant.Chaskar@nokia.com writes: > Some packets may overtake the packet carrying QoS information packet. But > let us look at the following math. Assume that T is forwarding delay (not > counting processing time required) for a hop. Let P be the processing time > of PATH or RESV or QoS Object hop-by-hop option at a network node. > > Assume 3 hops in the end-to-end path that are concerned with programming QoS > forwarding treatment. Let us look at the packet stream from CN to MN and let > us count the number of packets at each of these nodes that would get default > forwarding treatment due to lack of QoS forwarding information. Let us take > the time difference between the potential arrival of first packet at a > network node and the time QoS forwarding treatment is programmed at that > node as an indication of number of packets that would get default forwarding > treatment at that node. > > Let us indicate the node closest to CN by Node 1. I.e. I am assuming the > following scenario CN--->Node 1---->Node 2---->Node 3--->MN. I am also > assuming that PATH packet/QoS Object hop-by-hop option packet and first data > packet arrive at Node 1 one after another. > > > RSVP QoS object hop-by-hop option > > Node 1 3T+3P (for PATH) + 3T+3P (RESV) P > > Node 2 3T+3P (for PATH) + 2T+2P (RESV) T+2P > > Node 3 3T+3P (for PATH) + T+P (RESV) 2T+3P > > It can be seen that the latencies in second column (and hence number of > packets getting default treatment) are much smaller that those the first > one. > > Hemant Chaskar > Nokia > > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 05. March 2001 10:13 > To: Hemant.Chaskar@nokia.com > Cc: mat@cisco.com; hchaskar@hotmail.com; mobile-ip@sunroof.eng.sun.com; > seamoby@diameter.org; mobile-ip@marvin.corpeast.baynetworks.com > Subject: RE: [seamoby] QoS and Mobile IP > > > Hemant.Chaskar@nokia.com writes: > > > => The solution of enclosing QoS Object in hop-by-hop > > > extension header, preferably with binding messages, performs > > > fast reservation on forward path. > > > > No it doesn't. If it needs to go clear back to the > > correspondent node to change filter specs, you're > > already too slow in the degeneate case. > > > > -----> No, you don't get the point still. You have to > > -----> realize that packet carrying QoS object PRECEDES any > > -----> data packets using new CoA. Please read the illustration that > > -----> I gave in previous email again. Hence, QoS forwarding will > > -----> be in place when these new CoA packets hit the intermediate > > -----> routers. RSVP takes one round trip time for that. > > What makes you think that other packets will not > overtake the qos establishment packet? FIB based > forwarding is a whole lot faster than installing > a reservation. > > Mike ------_=_NextPart_001_01C0A7F6.855D1FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Latency if QoS programming

I agree with Michael and we should make no mistake = that if all of the issues(requirements/assumptions) are the same, it = will be a re-invention of the wheel.

Are people working with different requirements. An AS = might be in order before people spend their time on PDUs.

I believe this relates to the 3GPP question = of:

I want a fairly inexpensive mobile to be able to = communicate with QoS to a host behind a T1 of a small corporate = network. Bandwidth over the T1 is signaled using RSVP. The mobile is = using some "access specific" mechanisms. Diff-serv is in the = middle.  How will it work unless it is mandated that the network = can signal the mobile in an access specific way or the mobile itself is = mandated to interwork RSVP and the access specific protocol?

respectfully to you all,

Glenn


-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Monday, March 05, 2001 10:43 AM
To: Hemant.Chaskar
Cc: mat@cisco.com; = mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Latency if QoS = programming


Hemant,

I'd have a lot more sympathy for this argument = if
what you'd proposed is, essentially, RESV = with
router alert. As it stands, your proposal = does
not address:

- multicast
- flow merging
- topology changes and localized healing
- cryptographic identity
- hopwise integrity
- policy based admission control
- flow aggregation
- admission based diffserv
- tunneling
- mpls-te
- the mapping to various L2's

and probably a half a dozen other things
I can't remember off the top of my head.

In other words, in order to replace RSVP you = are
going to have to reinvent RSVP. I frankly find = no
motivation to do so, and in fact given recent
developments I think that RSVP may be = salvageable
close to as-is and perform better than your
proposal.

        =         Mike

Hemant.Chaskar@nokia.com writes:
 > Some packets may overtake the packet = carrying QoS information packet. But
 > let us look at the following math. Assume = that T is forwarding delay (not
 > counting processing time required) for a = hop. Let P be the processing time
 > of PATH or RESV or QoS Object hop-by-hop = option at a network node.
 >
 > Assume 3 hops in the end-to-end path that = are concerned with programming QoS
 > forwarding treatment. Let us look at the = packet stream from CN to MN and let
 > us count the number of packets at each of = these nodes that would get default
 > forwarding treatment due to lack of QoS = forwarding information. Let us take
 > the time difference between the potential = arrival of first packet at a
 > network node and the time QoS forwarding = treatment is programmed at that
 > node as an indication of number of = packets that would get default forwarding
 > treatment at that node.
 >
 > Let us indicate the node closest to CN by = Node 1. I.e. I am assuming the
 > following scenario CN--->Node = 1---->Node 2---->Node 3--->MN. I am also
 > assuming that PATH packet/QoS Object = hop-by-hop option packet and first data
 > packet arrive at Node 1 one after = another.
 >
 >
 >         = ;       = RSVP           &n= bsp;           &n= bsp;   QoS object hop-by-hop option
 >
 > Node 1    3T+3P (for PATH) = + 3T+3P = (RESV)           = P
 >
 > Node 2    3T+3P (for PATH) = + 2T+2P = (RESV)           = T+2P
 >
 > Node 3    3T+3P (for PATH) = + T+P  = (RESV)           = 2T+3P
 >
 > It can be seen that the latencies in = second column (and hence number of
 > packets getting default treatment) are = much smaller that those the first
 > one.
 >
 > Hemant Chaskar
 > Nokia
 >
 > -----Original Message-----
 > From: ext Michael Thomas [mailto:mat@cisco.com]
 > Sent: 05. March 2001 10:13
 > To: Hemant.Chaskar@nokia.com
 > Cc: mat@cisco.com; hchaskar@hotmail.com; = mobile-ip@sunroof.eng.sun.com;
 > seamoby@diameter.org; = mobile-ip@marvin.corpeast.baynetworks.com
 > Subject: RE: [seamoby] QoS and Mobile = IP
 >
 >
 > Hemant.Chaskar@nokia.com writes:
 >  >  > =3D> The = solution of enclosing QoS Object in hop-by-hop
 >  >  > extension header, = preferably with binding messages, performs
 >  >  > fast reservation on = forward path.
 >  >
 >  >    No it = doesn't. If it needs to go clear back to the
 >  >    = correspondent node to change filter specs, you're
 >  >    already too = slow in the degeneate case.
 >  >
 >  > -----> No, you don't get = the point still. You have to
 >  > -----> realize that packet = carrying QoS object PRECEDES any
 >  > -----> data packets using = new CoA. Please read the illustration that
 >  > -----> I gave in previous = email again. Hence, QoS forwarding will
 >  > -----> be in place when = these new CoA packets hit the intermediate
 >  > -----> routers. RSVP takes = one round trip time for that.
 >
 >   What makes you think that = other packets will not
 >   overtake the qos = establishment packet? FIB based
 >   forwarding is a whole lot = faster than installing
 >   a reservation.
 >
 >      Mike

------_=_NextPart_001_01C0A7F6.855D1FC0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:14:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15062 for ; Thu, 8 Mar 2001 17:14:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12328; Thu, 8 Mar 2001 14:14:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10130; Thu, 8 Mar 2001 14:13:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MCAn11665 for mobile-ip-dist; Thu, 8 Mar 2001 14:12:10 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MC3111651 for ; Thu, 8 Mar 2001 14:12:04 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29048 for ; Thu, 8 Mar 2001 17:12:04 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06181 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:12:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LMc110626 for ; Thu, 8 Mar 2001 13:22:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01599 for ; Thu, 8 Mar 2001 13:22:37 -0800 (PST) Received: from mailbreak.com ([216.207.225.170]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25721 for ; Thu, 8 Mar 2001 14:22:32 -0700 (MST) Received: from eshim by mailbreak.com with SMTP (MDaemon.v3.5.2.R) for ; Thu, 08 Mar 2001 16:21:38 -0500 Message-ID: <027901c0a816$2bb3bb80$96958e3f@nyc.solidstreaming.net> From: "Eunsoo Shim" To: Subject: [mobile-ip] New I-D, Reliable and Scalable Mobile IP Regional Registration Date: Thu, 8 Mar 2001 16:24:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Return-Path: eunsoo@ctr.columbia.edu X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, We submitted a new I-D. Title : Reliable and Scalable Mobile IP Regional Registration Author(s) : Eunsoo Shim, Richard D. Gitlin Filename : draft-shim-reliable-reg-reg-00.txt Pages : 12 Date : 08-Mar-01 It is available also at the following URL: http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-reliable-reg-reg-00.t xt http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-reliable-reg-reg-00.p df Fllowing is the abstract: We propose a mechanism that allows local registration of a mobile node for a handoff within the same visited domain in a reliable and scalable way. This mechanism is an extension of the base Mobile IP and the Mobile IP Regional Registration protocols. The key ideas include allowing registration via a group of care of addresses for a mobile node, where there is a primary care of address to which the home agent forwards the packets for the mobile node. Each care of address corresponds to a gateway foreign agent, which share a trust relationship. Peer gateway foreign agents and the foreign agents monitor failure of a gateway foreign agent. When the gateway foreign agent corresponding to the primary care of address fails, one of the peer gateway foreign agent corresponding to a secondary care of address takes over the role of the failed gateway foreign agent and initiates update of the registration status automatically. When all gateway foreign agents fail, the foreign agents disable regional registration automatically. Thank you. Eunsoo From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:16:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15114 for ; Thu, 8 Mar 2001 17:16:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10050; Thu, 8 Mar 2001 14:16:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10707; Thu, 8 Mar 2001 14:16:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MEe311787 for mobile-ip-dist; Thu, 8 Mar 2001 14:14:40 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MEZ111780 for ; Thu, 8 Mar 2001 14:14:35 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29489 for ; Thu, 8 Mar 2001 17:14:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06234 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:14:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LOx110644 for ; Thu, 8 Mar 2001 13:24:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02269 for ; Thu, 8 Mar 2001 13:24:59 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23291 for ; Thu, 8 Mar 2001 13:24:58 -0800 (PST) Received: by fridge.docomo-usa.com (Postfix, from userid 119) id 2848E97404; Thu, 8 Mar 2001 13:30:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fridge.docomo-usa.com (Postfix) with ESMTP id 2742897801 for ; Thu, 8 Mar 2001 13:30:04 -0800 (PST) Date: Thu, 8 Mar 2001 13:30:04 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: IETF Mobile-IP Working Group Subject: [mobile-ip] New I-D in L3 trigger based MIPv4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: We have submitted a new I-D on L3 triggered MIPv4 predictive handoff. We'd like to have discussion in the WG regarding the document. Your comments and critiques are appreciated. You may view the I-D at http://search.ietf.org/internet-drafts/draft-gwon-mobileip-l3mp-mipv4-00.txt Thanks, ---------------------------------------------- Youngjune Gwon gyj@dcl.docomo-usa.com Research Engineer Mobile Internet Laboratory DoCoMo Communications Laboratories USA, Inc. And, the Truth will set you free. - John 8:32 ---------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:21:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15234 for ; Thu, 8 Mar 2001 17:21:06 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15304; Thu, 8 Mar 2001 14:20:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16395; Thu, 8 Mar 2001 14:20:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MIVF11928 for mobile-ip-dist; Thu, 8 Mar 2001 14:18:31 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MIP111921 for ; Thu, 8 Mar 2001 14:18:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00159 for ; Thu, 8 Mar 2001 17:18:26 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06323 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:18:31 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LdI110865 for ; Thu, 8 Mar 2001 13:39:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05377 for ; Thu, 8 Mar 2001 13:39:12 -0800 (PST) Received: from hotmail.com (f32.law7.hotmail.com [216.33.237.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03151 for ; Thu, 8 Mar 2001 14:39:07 -0700 (MST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Mar 2001 13:39:06 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 08 Mar 2001 21:39:06 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] 01 version of MIPv6 QoS draft submitted Date: Thu, 08 Mar 2001 21:39:06 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_84_630b_712e" Message-ID: X-OriginalArrivalTime: 08 Mar 2001 21:39:06.0996 (UTC) FILETIME=[33E8F340:01C0A818] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_84_630b_712e Content-Type: text/plain; format=flowed Hi, We submitted the 01 version of the following I-D. It already appears in the I-D directory at www.ietf.org. It is also included below for the quick retrieval. Title: A Framework for QoS Support in Mobile IPv6 Authors: Hemant Chaskar and Rajeev Koodli draft-chaskar-mobileip-qos-01.txt (00 version was presented in the San Diego meeting) Addition to 00 version mainly happens to be the performance comparison between the approach to QoS signaling proposed in the draft with RSVP. Some of this discussion has already appeared on the Mobile IP mailing list (all of which was copied to the SeaMoby mailing list when the former was broken). Thanks. Hemant _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com ------=_NextPart_000_84_630b_712e Content-Type: text/plain; name="draft-chaskar-mobileip-qos-01.txt"; format=flowed Content-Disposition: attachment; filename="draft-chaskar-mobileip-qos-01.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id OAA15304 Content-Transfer-Encoding: quoted-printable IETF Mobile IP Working Group Hemant Chaskar INTERNET-DRAFT Rajeev Koodli Expires: September 2001 Nokia Research Center March 2001 A Framework for QoS Support in Mobile IPv6 draft-chaskar-mobileip-qos-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) The Internet Society (2001). All rights reserved. Abstract This draft describes a solution to perform QoS signaling along the new network path, when mobile node using Mobile IPv6 acquires a new care-of address. The solution is based on the definition of new option called QoS OBJECT OPTION. This option is included in the hop-by-hop extension header of certain packets, preferably the ones carrying binding messages, propagating between mobile node and correspondent node or between mobile node and regional mobility agent(s). Such an approach takes advantage of mobility signaling inherent in Mobile IPv6 to program QoS forwarding treatment as well, along the new network path. It naturally blends in with micro-mobility techniques. Further, compared to using RSVP, our solution has much smaller latency until QoS forwarding treatment is programmed over the new network path after handover. Chaskar, Koodli [Page i] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 Contents Status of This Memo i Abstract i 1.0 Introduction 1 1.1 Problem statement 1.2 Solution overview 2.0 Terminology and Abbreviations 2 3.0 Composition of QoS OBJECT OPTION 3 4.0 Inclusion of QoS OBJECT OPTION in hop-by-hop extension header 4 4.1 Basic Mobile IPv6 4.2 Micro-mobility scenarios 5.0 Performance Considerations (Comparison with RSVP) 6 6.0 Processing of QoS OBJECT OPTION at Intermediate Networks 7 6.1 IntServ domain 6.2 MPLS domain 6.3 DiffServ domain 7.0 Security considerations (TBD) 9 8.0 Acknowledgment 9 9.0 References 10 10.0 Addresses 11 Chaskar, Koodli [Page ii] INTERNET-DRAFT QoS Support in Mobile IPv6 March,2001 1.0 Introduction While Mobile IP [1] ensures correct and efficient routing of mobile node's (MN) packets as the MN changes its point of attachment with the Internet, the issue of Quality of Service (QoS) for MN's packet streams is not addressed yet. This document describes the problem statement, outlines a solution and provides comparison with existing (mobility-unaware) approaches such as RSVP [2] to QoS signaling. 1.1 Problem statement As an MN moves from one access router (AR) to another, the paths traversed by MN's packet streams with its correspondent nodes (CNs), may change. This is always true for the path in the access network to which MN is attached. In addition, handover between ARs in different access networks may cause the path traversed by MN's packet streams in the core network to change as well. If the MN's packet streams are QoS-sensitive, a mechanism is needed to signal desired QoS forwarding treatment along the new paths in the network. It is important to note that while the routing aspect of mobility has been addressed in Mobile IPv6, the problem of maintaining desired QoS forwarding treatment in the light of mobility has not been addressed. Subsequent to handover, the new end-to-end path between CN(s) and MN may span a number of networks (access and core) employing a variety of QoS schemes, notably IntServ [3] in access and MPLS [4] and DiffServ [5] in core. There may as well be best effort networks in the end-to-end path. Thus, as a basic requirement, mobility-aware QoS signaling mechanism must be capable of providing QoS forwarding information for MN's packet streams to relevant routers in different networks in the end-to-end path. The QoS signaling mechanism must have fast response time so that the latency between the time packets using the new care-of address (CoA) are released into the network and the time QoS forwarding information is signaled along the new path should be minimized. In other words, the mechanism must be able to make use of intrinsic handover signaling to minimize "QoS alignment" latency for MN's packet streams. Furthermore, any mobility-aware QoS signaling mechanism should be able to exploit micro-mobility [6,7] and fast handover [8] solutions in order to localize the extent of signaling to affected branches of the network only. Finally, such a mechanism should impose minimal requirements on the end terminals with limited processing power, memory and battery resources. 1.2 Solution overview Our solution is based on the use of new option called QoS OBJECT OPTION. It may contain a number of QoS OBJECTs, each of which corresponds to one unidirectional QoS-sensitive packet stream of Chaskar, Koodli [Page 1] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 MN. The basic idea is to include QoS OBJECT OPTION in IPv6 hop-by-hop extension header along with packets propagating in the same direction as the QoS-sensitive packet streams of MN. Since binding update (BU) is sent as soon as the data transmission from the new CoA is ready to begin, the QoS OBJECT OPTION sent along with it in hop-by-hop extension header, promptly triggers the necessary actions to set up QoS forwarding treatment along the new path. Same is true regarding binding acknowledgment (BA) when the packet streams in the direction from CN(s) to MN are considered. With basic Mobile IPv6, the binding messages travel end-to-end. Thus, the QoS object processing also spans end-to-end network path. With micro-mobility solutions, these messages travel only as far as the nearest mobility agent that needs to update its route table entry. Note that the QoS OBJECT OPTION also needs to travel only as far as the nearest node requiring an update to its route entry. Thus, by combining the transmission of QoS OBJECT OPTION with binding messages, a natural optimization is achieved with micro-mobility solutions. However, note that QoS object option may be included in hop-by-hop extension header of any other packet propagating in the same direction as QoS-sensitive packet stream. The actions taken by intermediate routers upon examining the QoS OBJECT OPTION in hop-by-hop extension header depend on the QoS scheme employed by their network domains. Generally, in access networks, QoS OBJECTs in QoS OBJECT OPTION will be used by all routers to program QoS forwarding treatment for MN's packets. In the core network, typically edge routers process the QoS OBJECT OPTION, while internal routers ignore it. Note that our approach does not relay on round-trip signaling such as PATH/RESV of RSVP, but rather performs programing of QoS forwarding treatment along the new network path in one pass. Also, this is done ahead of the time the packets using new CoA arrive at intermediate routers along the new end-to-end path. This minimizes the number of packets that would get default forwarding treatment at intermediate nodes due to lack of QoS forwarding information in those nodes after handover. 2.0 Terminology and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. MN: Mobile node CN: Correspondent node QoS: Quality of service CoA: Care-of-address HoA: Home address AR: Access router Chaskar, Koodli [Page 2] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 BU/BA: Binding update/Binding acknowledgment ER: Edge router of network domain IR: Interior router of network domain MPLS: Multi-protocol label switching FEC: Forwarding equivalence class DiffServ: Differentiated services IntServ: Integrated services Uplink/Downlink direction: From MN/Towards MN 3.0 Composition of QoS OBJECT OPTION The QoS signaling solution described here uses a new IPv6 extension header option called QoS OBJECT OPTION. The composition of QoS OBJECT OPTION is shown in Figure 1. It contains zero or more QoS OBJECTs in TLV format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |0|0|1| Opt Type| Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Reserved | One or more QoS OBJECTs in TLV format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Composition of QoS OBJECT OPTION The composition of a QoS OBJECT is shown in Figure 2. A QoS OBJECT is an extension of RSVP QoS and FILTER_SPEC objects. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Reserved | Object Length |QoS Requirement| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Max Delay (16-bit integer) ms |Delay Jitter (16-bit integer)ms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Average Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | | | | | Values of Packet Classification Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Composition of a QoS OBJECT Chaskar, Koodli [Page 3] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 o QoS Requirement: This field describes the QoS requirement of the MN's packet stream in terms of traffic class. An example is the QoS specification in terms of delay sensitivity, such as interactive-delay sensitive, non-interactive delay sensitive or delay insensitive, as in UMTS QoS specification [9]. Another example is specification in terms of DiffServ PHB classes such as EF or AF. Yet another alternative is QoS specification in terms of IntServ classes such as guaranteed service or controlled load service. Some examples are, 00000xxx: DiffServ EF PHB 00001xxx: DiffServ AF PHB 00010xxx: IntServ guaranteed service 00011xxx: IntServ controlled load service 00100xxx: UMTS traffic class o Delay specification: The fields "Max Delay" and "Delay Jitter" specify the end-to-end values of respective quantities in milliseconds that the packet stream can tolerate. o Traffic Volume: The fields Average Data Rate, Burstiness, Peak Data Rate, Minimum Policed Unit and Maximum Packet Size describe the volume and nature of traffic that the corresponding packet stream is expected to generate. o Packet Classification Parameters: This field provides values for parameters in packet headers that can be used for packet classification. In particular, it specifies a subset of TCP/UDP port numbers, IPv6 flow label and SPI corresponding to particular packet stream. Typically, source and destination IP addresses to be used for packet classification can be inferred from header of packet carrying QoS OBJECT OPTION. 4.0 Inclusion of QoS OBJECT OPTION in hop-by-hop extension header The basic idea here is to include QoS OBJECT OPTION containing QoS OBJECTs corresponding to MN's packet stream(s), in the hop-by-hop extension header along with the packet that propagates in the same direction as the corresponding packet stream(s). QoS OBJECTs in this option can then inform the routers at the intermediate network domains about the QoS forwarding requirement of the relevant packet streams. Routers make use of this information, in a manner that is consistent with the QoS scheme employed by their network domains (see Section 6), to immediately program proper QoS forwarding treatment for those packet stream(s). Chaskar, Koodli [Page 4] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 4.1 Basic Mobile IPv6 In basic Mobile IPv6, MN sends BU to CN as soon as it is ready to use new CoA. QoS OBJECT OPTION containing QoS OBJECT(s) corresponding to uplink packet stream(s) SHOULD be included in hop-by-hop extension header with this BU. QoS OBJECT OPTION promptly triggers necessary processing at the intermediate routers so as to offer proper QoS forwarding treatment to MN's uplink packet streams along the new end-to-end path. By the same reasoning, QoS OBJECT OPTION containing QoS OBJECT(s) corresponding to downlink packet stream(s), SHOULD be included in hop-by-hop extension header along with BA that is sent from CN to MN. Note however that QoS OBJECT OPTION can be included in the hop-by-hop extension header of any packet that propagates in the same direction as the corresponding packet stream(s). 4.2 Micro-mobility scenarios Micro-mobility solutions introduce local mobility agents, such as a Gateway Mobility Agent (GMA) in Regional Registration or Mobility Anchor Point (MAP) in Hierarchical Mobile IPv6 approach for proxying a regional CoA. Regional CoA remains constant while the MN moves inside the visited domain. This approach alleviates the need for sending BUs to all the CNs for every handover. This conserves wireless bandwidth as well as reduces the signaling load caused by binding messages outside the visited domain. It decreases the latency associated with binding messages as they are sent only up to the local mobility agent. The proposed solution readily makes use of micro-mobility mechanisms, facilitating QoS modification along only those segments of end-to-end forwarding path that are affected by the MN=92s movement. The QoS OBJECT OPTION would be carried in the BU to the regional mobility agent, and the routers in the path traversed by BU process this hop-by-hop option, making modifications to their QoS forwarding engines as necessary. The BA from the regional mobility agent would trigger similar adjustments for QoS forwarding treatment for packets destined to the MN. We observe some significant performance benefits in combining QoS signaling with micro-mobility. First, the QoS signal itself would travel only as far as what is deemed necessary by the particular micro-mobility mechanism. This reduces the round-trip signaling latency. Incidentally, we note that with Regional Registrations for Mobile IPv6, this distance is up to the cross-over router, where as with HMIPv6, it is the number of hops up to MAP. Second, QoS object option with micro-mobility greatly enhances existing state re-usage. That is, the existing Chaskar, Koodli [Page 5] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 QoS state beyond the GMA or the MAP need not be modified at all when the mobile node=92s movement is limited to the visited domain (implying that the Regional CoA does not change). Regional Registrations further extends this state re-use to the nodes within the visited domain itself. For example, when the mobility limits route changes to a node below the GMA in hierarchy, such as a cross-over router, the existing state above the cross-over state can be re-used, since those nodes do not perceive a change in the source address in the packets. 5.0 Performance Considerations (Comparison with RSVP) In this section, we compare the performance of QoS signaling approach proposed in this document to that of using RSVP for QoS signaling upon handover. The performance metric used is the latency between the time nodes (MN or CN) are ready to use new CoA and the time QoS forwarding requirement is signaled over the new forwarding path. We observe that RSVP introduces latency of about one round-trip time (between the MN and the CN) from the time packets using new CoA are released into the network until the time QoS forwarding treatment is programmed over the new path. Note that one end-to-end round-trip may involve, in the worst case, four traversals of wireless links. The worst case happens when both MN and CN are attached via low bandwidth wireless links. In that case, the packets released into the network during this time period would get default forwarding treatment at intermediate network domains. On the contrary, in our approach, programming of QoS forwarding treatment along the new end-to-end path is immediate. This is shown by the following illustration. Suppose MN is currently at CoA1. Consider data traffic from the CN towards the MN (downlink direction). The following events occur: o MN moves to CoA2 and sends BU from CoA2 to CN. BU reaches CN. CN sends BA to MN at CoA2. RSVP | HOP-by-HOP QoS OBJECT OPTION CN initiates RSVP signaling | QoS OBJECT OPTION for downlink to program QoS forwarding | packet stream(s) is included in treatment for downlink traffic | HOP-by-HOP OPTIONS EXTENSION over the new network path. For | HEADER along with the BA. this, CN sends RSVP PATH to MN | at CoA2. | o CN may start sending MN's packets to CoA2. These packets contain CoA2 as destination address. Chaskar, Koodli [Page 6] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 RSVP | HOP-by-HOP QoS OBJECT OPTION Note that QoS forwarding | QoS OBJECT OPTION precedes these treatment for these packets is | these packets and programs QoS not yet programmed along the | forwarding treatment along the new network path. This is | new network path. The processing certainly true for the segment | time of QoS OBJECT OPTION along of end-to-end path that was | the new network path would not present in the old | determine how quickly proper QoS end-to-end path. Even over |forwarding treatment is offered. that segment of the end-to-end |In RSVP, this latency is at least path which remains unchanged |one round-trip time plus the after handover, these packets |processing time of PATH and RESV would get default forwarding |messages along the new end-to-end treatment. This is because, |network path. RSVP session is primarily | identified by destination | address which now has changed | from CoA1 to CoA2. | ----[One way end-to-end delay ellapses, then]---- o BA reaches MN at CoA2. RSVP PATH reaches MN at CoA2. | MN sends RSVP RESV to CN. | ----[One way end-to-end delay ellapses, then]---- RSVP | o RSVP RESV reaches CN. | | It is at this time that the | proper QoS forwarding | treatment is programmed at the| intermediate nodes for packets| destined to CoA2. | It is worth noting that the above drawback of RSVP's OPWA (One Pass with Advertisement) method is also observed in [10].It is shown in [10] that under certain assumptions, the severity of this drawback can be reduced. However, validity of those assumptions is not obvious. 6.0 Processing of QoS OBJECT OPTION at Intermediate Networks When QoS OBJECT OPTION is included in the HOP-by-HOP OPTIONS EXTENSION HEADER in IPv6 packet, intermediate routers MUST examine this option. The purpose of this is to obtain information about QoS forwarding requirement about MN's packet streams. Chaskar, Koodli [Page 7] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 Typically, there are multiple and possibly heterogeneous (in terms of QoS mechanism employed) network domains in the end-to-end path. Here, a network domain is defined as a collection of network nodes (routers) that implements a particular QoS mechanism independently and under the same control framework. There are edge routers (ER) at the edge of these domains and internal routers (IR) inside the domains. Each of these domains may be a best-effort domain or may employ QoS mechanisms such as MPLS, DiffServ or IntServ. Typically, access networks would employ flow-based QoS mechanisms such as IntServ, while core network will use aggregate-based schemes such as MPLS and DiffServ. Note that QoS OBJECT contains enough information so that any of these QoS schemes can extract the information relevant to them from the QoS OBJECT. The actual mapping between QoS object parameters to the parameters used by different QoS schemes is implementation specific, and thus beyond the scope of this document. In the following, we outline the semantics of processing QoS OBJECT OPTION at ERs and IRs of these network domains. 6.1 IntServ domain In IntServ domain, there are two ways to process the QoS OBJECT OPTION. According to one method which fully complies with One Pass with Advertisement (OPWA) model of RSVP, ingress ER examines the QoS OBJECT OPTION in hop-by-hop extension header to determine QoS forwarding requirement of MN's packet streams. It also determines the egress ER of that network domain where MN's packets will be forwarded. Ingress ER sends RSVP PATH message to egress ER. Ingress ER MAY include (a version of) QoS OBJECT OPTION in _destination_ extension header of the packet carrying RSVP PATH message. This will provide egress ER with the information necessary to determine the actual resources that are required to be reserved. Egress ER sends RSVP RESV to ingress ER. Once ingress ER receives RESV from egress ER, it forwards the packet containing QoS OBJECT OPTION through the network domain. IRs in the network domain simply ignore the QoS OBJECT OPTION. The above method has the following drawback that is intrinsic to OPWA model of resource reservation of RSVP, when it is used in mobile environment. It takes one round trip time in the network domain before QoS forwarding treatment is programmed at the routers in the network domain. In other words, MN's packets that arrive at the ingress ER get default forwarding treatment until the time RESV reaches ingress ER. This drawback is eliminated if the following method of resource reservation is used instead. Ingress ER of IntServ network domain examines the QoS OBJECT OPTION and immediately performs reservation of resources such as buffer, bandwidth, priority etc. at that router. Ingress ER then Chaskar, Koodli [Page 8] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 forwards the packet containing QoS OBJECT OPTION to next IR in the network domain. IR examines the QoS OBJECT OPTION and immediately performs resource reservation at that router. IR then forwards the packet to next IR in the network domain. This continues until the packet reaches egress ER which performs resource reservation at that router, and forwards the packet to next network domain. 6.2 MPLS domain Ingress ER at MPLS domain (often called edge label switching router (edge LSR)) determines the forwarding equivalence class (FEC) to which the packets of MN's packet stream(s) should belong to in that domain. This decision is based on the destination IP address of the packet and QoS forwarding requirement of packet stream(s). FEC translates to label switching path (LSP) over which the packets should be forwarded through that domain. Ingress ER may also use traffic volume parameters in QoS OBJECT(s) to perform admission control over those LSPs. Ingress ER creates FEC mapping context that would map subsequent packets of MN's packet stream(s) onto appropriate LSPs. Packet classification parameters in the QoS OBJECT(s) are used to set up FEC mapping context. Ingress ER then forwards the packet containing QoS OBJECT OPTION through the network domain using label based forwarding paradigm. As a result of this, IRs do not even see the IP header, and hence, do not process any hop-by-hop options. 6.3 DiffServ domain Ingress ER at DiffServ domain uses QoS OBJECT(s) in QoS OBJECT OPTION to program packet classification context for the packets of MN's packet stream(s). This context would assign appropriate differentiated services code point (DSCP) to subsequent packets of these packet stream(s). ER may also perform admission control to ensure that service level agreement (SLA) is not violated by the volume of traffic generated by these packet stream(s). IRs in DiffServ domain simply ignore the QoS OBJECT OPTION. 7.0 Security considerations To be discussed. 8.0 Acknowledgment Thanks are due to Charlie Perkins (Nokia) for his useful comments during the revision of this document. Chaskar, Koodli [Page 9] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 9.0. References [1] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-ipv6-12.txt. April 2000. [2] R. Braden and L. Zhang. Resource ReSerVation Protocol (RSVP): Version 1 Functional Specification. Request for Comments (Standards track) 2205. September 1997. [3] R. Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: An Overview. Request for Comments (Informational) 1633. June 1994. [4] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture. Internet Draft, Internet Engineering Task Force. draft-ietf-mpls-arch-06.txt. July 2000. [5] S. Blake et. al. An Architecture for Differentiated Services. Request for Comments (Informational) 2475. December 1998. [6] J. Malinen and C. Perkins. Mobile IPv6 Regional Registrations. Internet Draft, Internet Engineering Task Force. draft-malinen-mobileip-regreg6-00.txt. July 2000. [7] H. Soliman et. al. Hierarchical MIPv6 mobility management. Internet Draft, Internet Engineering Task Force. draft-soliman-mobileip-hmipv6-01.txt. September 2000. [8] C. Perkins et. al. Fast Handovers for Mobile IPv6. Internet Draft, Internet Engineering Task Force. draft-perkins-mobileip-handover-00.txt. November 2000. [9] 3GPP Technical Specification 23.107, Version 3.2.0: QoS Concept and Architecture, March 2000. [10] Michael Thomas. Analysis of Mobile IP and RSVP Interactions. Internet Draft, Internet Engineering Task Force. draft-thomas-seamoby-rsvp-analysis-00.txt. February 2001. Chaskar, Koodli [Page 10] INTERNET-DRAFT QoS Support in Mobile IPv6 March, 2001 10.0 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can be directed to the authors: Hemant Chaskar Communication Systems Laboratory Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781-993-3785 EMail: hemant.chaskar@nokia.com Rajeev Koodli Communication Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043, USA Phone: +1 650-625-2359 EMail: rajeev.koodli@nokia.com Chaskar, Koodli [Page 11] ------=_NextPart_000_84_630b_712e-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:24:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15311 for ; Thu, 8 Mar 2001 17:24:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16927; Thu, 8 Mar 2001 14:23:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17352; Thu, 8 Mar 2001 14:23:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MLj612028 for mobile-ip-dist; Thu, 8 Mar 2001 14:21:45 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MLf112020 for ; Thu, 8 Mar 2001 14:21:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00610 for ; Thu, 8 Mar 2001 17:21:41 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06385 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:21:45 -0500 (EST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28Lnq111098 for ; Thu, 8 Mar 2001 13:49:52 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f28Lnmv621357; Thu, 8 Mar 2001 13:49:48 -0800 (PST) Message-Id: <200103082149.f28Lnmv621357@jurassic.eng.sun.com> Date: Thu, 8 Mar 2001 16:49:52 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] Re: BOUNCE mobile-ip@sunroof.eng.sun.com: Approval required: To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >Steve, >This is what Pat does for Seamoby list, I think. >So east coast people wont get their postings in the morning until the >afternoon. >This is only one problem with manually controlled distribution. >--behcet, I know this delays the information, particularly since I have a lot of things outside of work going on during the day, but it's the only way to make sure we're not going to loose again due to a loop; I'm going to get better at being more timely with the approvals. Pat and I got nearly 2000 emails from the last loop in the span of an hour; that also slows down the servers and the information to the list, never mind what the duplicates on the list do to communication. The looping servers were caching the email for almost 3 days then reposting to the list (!), so I'll need to moderate at least that long, guaranteeing I'll intercept any echoes. Pat and I suspect they may be doing this malliciously, but I'm not going to wonder, I'm just going to stop them. I don't want to do this any longer than I have to, but for now it's necessary. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:32:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15618 for ; Thu, 8 Mar 2001 17:32:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20739; Thu, 8 Mar 2001 14:32:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21424; Thu, 8 Mar 2001 14:31:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MTZ712197 for mobile-ip-dist; Thu, 8 Mar 2001 14:29:35 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MTU112190 for ; Thu, 8 Mar 2001 14:29:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01877 for ; Thu, 8 Mar 2001 17:29:31 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06548 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:29:35 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28M8w111569 for ; Thu, 8 Mar 2001 14:08:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08950 for ; Thu, 8 Mar 2001 14:08:58 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12862 for ; Thu, 8 Mar 2001 14:08:57 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f28M8tC19833 for ; Thu, 8 Mar 2001 23:08:56 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 08 23:08:54 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 23:05:01 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: hmip and mobile routers Date: Thu, 8 Mar 2001 23:08:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Behcet, I mustn't be explaining this very well. I fully supprt Thierry's draft and think it is needed. HMIPv6 does NOT address the scenario mentioned in Thierry's draft. I hope it becomes a WG draft and get standardised soon. On the other hand I also fully support the Extended mode in HMIPv6 and think it's needed (obviously mobile networks in not the only reason for having it). As far as Mobile etworks are concerned, Thierry's draft does NOT address that scenario. Finally both Thierry's draft and HMIPv6 can co-exist as they don't interfere with each other. I hope I've done a better job in explaining myself. Cheers, Hesham > -----Original Message----- > From: Behcet Sarikaya [SMTP:behcet.sarikaya@usa.alcatel.com] > Sent: Friday, 9 March 2001 3:23 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: hmip and mobile routers > > Hesham and Michael, > My suggestion is to drop the part on mobile routers in > hmipv6. This may clear the way for a separate RFC on mobile routers, probably based > on Thierry's I-D. I think that the extended mode of hmipv6 could still stand. > > --behcet << File: Card for Behcet Sarikaya >> From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:33:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15651 for ; Thu, 8 Mar 2001 17:33:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19048; Thu, 8 Mar 2001 14:30:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13842; Thu, 8 Mar 2001 14:28:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MR2V12154 for mobile-ip-dist; Thu, 8 Mar 2001 14:27:02 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MQv112146 for ; Thu, 8 Mar 2001 14:26:58 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09202 for ; Thu, 8 Mar 2001 17:26:58 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06495 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:27:03 -0500 (EST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28LwU111300 for ; Thu, 8 Mar 2001 13:58:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f28LwSv623060; Thu, 8 Mar 2001 13:58:28 -0800 (PST) Message-Id: <200103082158.f28LwSv623060@jurassic.eng.sun.com> Date: Thu, 8 Mar 2001 16:58:33 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] Re: BOUNCE mobile-ip@sunroof.eng.sun.com: Approval required: To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >Steve, > >Pat put an IP level filter on the domain in Korea that was looping. >They can't get any packets in or out, but thems the breaks if they >choose to behave in such a bad way. > > jak > Unfortunately, where sunroof.eng sits in the topology here we can't do anything at the IP level. I'm looking into other solutions, and I probably overreacted a bit about the length of time I'm going to have to do this (though I was taking the view that I should plan for more issues). Hand-throttling is not a good solution, but it's working until there's a more automated safe-guard in place. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 17:37:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15789 for ; Thu, 8 Mar 2001 17:37:12 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00081; Thu, 8 Mar 2001 14:36:58 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12131; Thu, 8 Mar 2001 14:36:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f28MZDU12291 for mobile-ip-dist; Thu, 8 Mar 2001 14:35:13 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MZ8112284 for ; Thu, 8 Mar 2001 14:35:09 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02740 for ; Thu, 8 Mar 2001 17:35:09 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06663 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 17:35:14 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MHB111855 for ; Thu, 8 Mar 2001 14:17:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10854 for ; Thu, 8 Mar 2001 14:17:12 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10502 for ; Thu, 8 Mar 2001 14:17:07 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f28MH5C21174 for ; Thu, 8 Mar 2001 23:17:05 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 08 23:17:05 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 23:17:05 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] AAA/QOS in MIP and SeaMoby Date: Thu, 8 Mar 2001 23:17:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Why can't AAA server specific stuff be done somewhere else like say > a AAA group? Tying AAA specifically to a particular macromobility > implementation seems like a very bad design approach to me. > It seems like it is being done to placate particular vendors' interests > to me. > => I can't agree with you more. There is absolutely no need for handling access control/AAA functions in this WG. Any node trying to access the Internet should be authorised to do so, regardless of whether it uses MIP or not. In fact I'm strongly against doing this access authentication and authorisation functions in the MIP WG. I do however think that the MIP WG MUST place the appropriate requirements on these functions and that was done. Raj is running a BOF (BURP) in Minneapolis that looks at the interface between a host and the network for AAA purposes. I think this is VERY important and that's where the work should be done. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 19:05:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18100 for ; Thu, 8 Mar 2001 19:05:26 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11527; Thu, 8 Mar 2001 16:05:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05002; Thu, 8 Mar 2001 16:05:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2903Yv12874 for mobile-ip-dist; Thu, 8 Mar 2001 16:03:34 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2903S112865 for ; Thu, 8 Mar 2001 16:03:29 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14025 for ; Thu, 8 Mar 2001 19:03:29 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA08399 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 19:03:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MHh111889 for ; Thu, 8 Mar 2001 14:17:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06227 for ; Thu, 8 Mar 2001 14:17:44 -0800 (PST) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16987 for ; Thu, 8 Mar 2001 14:17:44 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id WAA06995 for ; Thu, 8 Mar 2001 22:17:43 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 08 Mar 2001 22:12:26 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 14:12:25 -0800 Message-ID: From: "Davis, Ed" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MobileIPv6 mandatory IPSec Date: Thu, 8 Mar 2001 14:12:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I was unaware that Mobile IPv6 had close on IPSec being mandatory. This is a huge (40% overhead) for wireless traffic, not to mention the retries for dropped packets, etc. What is the justification for making IPSec mandatory? Thanks, Ed Davis (ed.davis@intel.com) Director of Technology Office: 503-456-0048 Cell: 503-807-4678 Pager: 1-800-eye-t0-eye Admin: Kitty LeGault 503-456-0074 -----Original Message----- From: Alain RITOUX [mailto:alain.ritoux@6wind.com] Sent: Thursday, March 08, 2001 1:58 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobileIPv6 and IKE Hi everybody. I'm interested in the combinasion of mobileipv6 and its mandatory IPsec, and I was wondering about the IKE usage. Between ther MN and its HA, the BU need to be authenticated, hence an SA must exist, but the HA can't speak with the MN, until the Co@ is known, hence the BU accepted. So how can IKE work ? - Is there a solution for this chicken-an-egg pb ? - If yes, is it standard ? Moreover, while reading a few drafts/RFC (mobility support in IPv6, destination option header clarification, IIPv6 ...) I'm getting a little bit cionfused about the IPv6 header extension order, or about where MUST/SHOULD/LMAY? be Dest options wrt various Destination Option Headers. Is there something stable ? mandatory ? btw I'm interested in any good material/references about those subjects. If you feel, this subject should rather be discussed on other lists (IPsec ? IPng ? ....), just let me know. Best regards. Alain. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 19:07:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18177 for ; Thu, 8 Mar 2001 19:07:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27780; Thu, 8 Mar 2001 16:07:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05635; Thu, 8 Mar 2001 16:07:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2905tD12927 for mobile-ip-dist; Thu, 8 Mar 2001 16:05:55 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2905o112919 for ; Thu, 8 Mar 2001 16:05:50 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14313 for ; Thu, 8 Mar 2001 19:05:50 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA08444 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 19:05:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MJB111950 for ; Thu, 8 Mar 2001 14:19:11 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18069 for ; Thu, 8 Mar 2001 14:18:42 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA04143 for ; Thu, 8 Mar 2001 14:18:36 -0800 (PST) From: Patrice Calhoun Message-Id: <200103082218.OAA04143@nasnfs.Eng.Sun.COM> Date: Thu, 8 Mar 2001 14:17:56 -0800 To: Subject: Re: [mobile-ip] AAA/QOS in MIP and SeaMoby X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit >Why can't AAA server specific stuff be done somewhere else like say >a AAA group? As far as I can tell, it is. The only thing that really happened in this WG was to collect requirements. I think this WG was the right place to do this. > Tying AAA specifically to a particular macromobility >implementation seems like a very bad design approach to me. >It seems like it is being done to placate particular vendors' interests >to me. Again, when the AAA WG was rechartered, they looked at what the market was looking for. At that time, Mobile IP had requirements for AAA, as did NASREQ. That was the reason why the AAA WG concentrated on those two specific areas. There are now other areas that have interest in AAA (e.g. SIP, DHCP, IPv6), and this is NOT occuring in the AAA WG, but in the respective WG (as far as I can tell). If another mobility solution gets created, and needs AAA, that WG would be responsible for handling that task. PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 19:11:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18267 for ; Thu, 8 Mar 2001 19:11:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16450; Thu, 8 Mar 2001 16:11:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15245; Thu, 8 Mar 2001 16:11:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f2908xq13021 for mobile-ip-dist; Thu, 8 Mar 2001 16:08:59 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2908q113009 for ; Thu, 8 Mar 2001 16:08:52 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22111 for ; Thu, 8 Mar 2001 19:08:52 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA08511 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 19:08:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28MPq112130 for ; Thu, 8 Mar 2001 14:25:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17906 for ; Thu, 8 Mar 2001 14:25:53 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12668 for ; Thu, 8 Mar 2001 14:25:51 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f28MPnC21914 for ; Thu, 8 Mar 2001 23:25:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 08 23:25:55 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 23:21:55 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC0F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] 01 version of MIPv6 QoS draft submitted Date: Thu, 8 Mar 2001 23:25:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I couldn't access the I-D to see the changes, but I have one question. Is there a reason for not using the router alert mechanisms to handle the QoS objects on a per hop basis ? Cheers, Hesham > -----Original Message----- > From: Hemant Chaskar [SMTP:hchaskar@hotmail.com] > Sent: Friday, 9 March 2001 8:38 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] 01 version of MIPv6 QoS draft submitted > > Hi, > > We submitted the 01 version of the following I-D. It already appears in the > I-D directory at www.ietf.org. It is also included below for the quick > retrieval. > > Title: A Framework for QoS Support in Mobile IPv6 > Authors: Hemant Chaskar and Rajeev Koodli > draft-chaskar-mobileip-qos-01.txt > (00 version was presented in the San Diego meeting) > > Addition to 00 version mainly happens to be the performance comparison > between the approach to QoS signaling proposed in the draft with RSVP. Some > of this discussion has already appeared on the Mobile IP mailing list (all > of which was copied to the SeaMoby mailing list when the former was broken). > > Thanks. > > Hemant > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com << File: draft-chaskar-mobileip-qos-01.txt >> From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 19:15:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18338 for ; Thu, 8 Mar 2001 19:15:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18850; Thu, 8 Mar 2001 16:14:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13250; Thu, 8 Mar 2001 16:14:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f290CwY13133 for mobile-ip-dist; Thu, 8 Mar 2001 16:12:58 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f290Cp113119 for ; Thu, 8 Mar 2001 16:12:52 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22499 for ; Thu, 8 Mar 2001 19:12:52 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA08593 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 19:12:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f28NvM112834 for ; Thu, 8 Mar 2001 15:57:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09798 for ; Thu, 8 Mar 2001 15:57:23 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28897 for ; Thu, 8 Mar 2001 15:57:23 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id PAA20801 for ; Thu, 8 Mar 2001 15:56:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACC28606; Thu, 8 Mar 2001 15:57:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00772; Thu, 8 Mar 2001 15:57:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15016.7265.29547.166722@thomasm-u1.cisco.com> Date: Thu, 8 Mar 2001 15:57:21 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] AAA/QOS in MIP and SeaMoby In-Reply-To: <88256A09.005C30CA.00@hqoutbound.ops.3com.com> References: <88256A09.005C30CA.00@hqoutbound.ops.3com.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, Even though I've been one of the prime agitators for paying attention to QoS and network/QoS admission control, I do not think that SEAMOBY or MIP should not be a vast catch basin for every problem remotely related to mobility. In particular, I have a lot of trepidation in MIP about the assumption that AAA ought to be the ultimate answer (or even first choice) for key distribution problems when things are mobile. This is a case where the problem should have been defined, but probably tossed over the wall to CAT or IPsec or even AAA to see how they could (if at all) meet the requirements for MIP. What I do think is useful for SEAMOBY and MIP is to: 1) Investigate what the actual problems are related to enabling AAA and QoS 2) Deal with the problems that are clearly within the purview of MIP or SEAMOBY 3) Make our case to the relevant working groups if extensions/fixes are needed to play well with mobility 4) Start new working groups if the problems are outside of anybody's scope but are still important. We need to start somewhere with (1), and I believe that MIP and SEAMOBY have it in their charters to figure out what it means. But that doesn't necessarily mean that once you figure out what it means that you have to claim ownership of it. Modularity is our friend, hopefully. Mike Phil_Neumiller@3com.com writes: > > > I know this message will be perceived by some as flame bait. I don't > want it to be. Please don't flame me. I have a very basic question > about the MIP and SeaMoby charters. Why do things that are clearly > operational and that are client server in nature get included into a > routing or transport WG such as MIP or SeaMoby? > > Why can't AAA server specific stuff be done somewhere else like say > a AAA group? Tying AAA specifically to a particular macromobility > implementation seems like a very bad design approach to me. > It seems like it is being done to placate particular vendors' interests > to me. > > The QoS argument holds a bit more water than AAA. Mixing stuff into > the MIP group seems to defocus the routing aspects and muddy up the > AAA and QoS aspects a bit. Ultimately, it seems MIP should be > absorbed into IP anyway and that should be the ultimate design goal > i.e. making MIP go away, so hanging ornaments on it is just going > to prolong our agony in making it go away. > > In general I don't think the router fabric for the global Internet should be > tied so much to the penchants of 3G vendors or operators. > > Thanks, > > Phil Neumiller > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 8 19:19:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18415 for ; Thu, 8 Mar 2001 19:19:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02111; Thu, 8 Mar 2001 16:18:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09875; Thu, 8 Mar 2001 16:18:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f290GY613254 for mobile-ip-dist; Thu, 8 Mar 2001 16:16:34 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f290GT113246 for ; Thu, 8 Mar 2001 16:16:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15373 for ; Thu, 8 Mar 2001 19:16:29 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA08676 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Mar 2001 19:16:33 -0500 (EST) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2904n112887 for ; Thu, 8 Mar 2001 16:04:49 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2903cM14358; Thu, 8 Mar 2001 16:03:38 -0800 (PST) Date: Thu, 8 Mar 2001 16:03:38 -0800 (PST) From: Mohan Parthasarathy Message-Id: <200103090003.f2903cM14358@locked.eng.sun.com> To: mobile-ip@sunroof.eng.sun.com, alain.ritoux@6wind.com Subject: Re: [mobile-ip] MobileIPv6 and IKE X-Sun-Charset: US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I'm interested in the combinasion of mobileipv6 and its mandatory IPsec, > and I was wondering about the IKE usage. > Between ther MN and its HA, the BU need to be authenticated, hence an SA > must exist, but the HA can't speak with the MN, until the Co@ is known, > hence the BU accepted. So how can IKE work ? Read section 10.2 of the draft. You are supposed to use the CoA as the source address without the home address option. > - Is there a solution for this chicken-an-egg pb ? > - If yes, is it standard ? > Moreover, while reading a few drafts/RFC (mobility support in IPv6, > destination option header clarification, IIPv6 ...) I'm getting a little > bit cionfused about the IPv6 header extension order, or about where > MUST/SHOULD/LMAY? be Dest options wrt various Destination Option > Headers. Is there something stable ? mandatory ? > btw I'm interested in any good material/references about those subjects. > Latest draft talks clearly about this i think. Home address option comes before the IPsec header and Binding update comes after the IPsec header. Home address option comes after the destination option that goes with the routing header. This is a new position that is not discussed in RFC 2460. This was extensively discussed sometime ago. So, please check the archives. -mohan > If you feel, this subject should rather be discussed on other lists > (IPsec ? IPng ? ....), just let me know. > > Best regards. > Alain. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 11:16:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19991 for ; Fri, 9 Mar 2001 11:16:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14261; Fri, 9 Mar 2001 08:14:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04170; Fri, 9 Mar 2001 08:14:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29GCs215939 for mobile-ip-dist; Fri, 9 Mar 2001 08:12:54 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29GCn115932 for ; Fri, 9 Mar 2001 08:12:49 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18014 for ; Fri, 9 Mar 2001 11:12:49 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA27041 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 11:12:54 -0500 (EST) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f291SV113645 for ; Thu, 8 Mar 2001 17:28:31 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f291RJB14536; Thu, 8 Mar 2001 17:27:19 -0800 (PST) Date: Thu, 8 Mar 2001 17:27:19 -0800 (PST) From: Mohan Parthasarathy Message-Id: <200103090127.f291RJB14536@locked.eng.sun.com> To: mobile-ip@sunroof.eng.sun.com, ed.davis@intel.com Subject: Re: [mobile-ip] MobileIPv6 mandatory IPSec X-Sun-Charset: US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I was unaware that Mobile IPv6 had close on IPSec being > mandatory. This is a huge (40% overhead) for wireless > traffic, not to mention the retries for dropped packets, > etc. What is the justification for making IPSec mandatory? > IPsec is mandatory only for Binding Updates/Requests and Acks. Not for the actual traffic. -mohan > Thanks, > > Ed Davis (ed.davis@intel.com) > Director of Technology > Office: 503-456-0048 > Cell: 503-807-4678 > Pager: 1-800-eye-t0-eye > Admin: Kitty LeGault 503-456-0074 > > > > -----Original Message----- > From: Alain RITOUX [mailto:alain.ritoux@6wind.com] > Sent: Thursday, March 08, 2001 1:58 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] MobileIPv6 and IKE > > > Hi everybody. > > I'm interested in the combinasion of mobileipv6 and its mandatory IPsec, > and I was wondering about the IKE usage. > Between ther MN and its HA, the BU need to be authenticated, hence an SA > must exist, but the HA can't speak with the MN, until the Co@ is known, > hence the BU accepted. So how can IKE work ? > - Is there a solution for this chicken-an-egg pb ? > - If yes, is it standard ? > Moreover, while reading a few drafts/RFC (mobility support in IPv6, > destination option header clarification, IIPv6 ...) I'm getting a little > bit cionfused about the IPv6 header extension order, or about where > MUST/SHOULD/LMAY? be Dest options wrt various Destination Option > Headers. Is there something stable ? mandatory ? > btw I'm interested in any good material/references about those subjects. > > If you feel, this subject should rather be discussed on other lists > (IPsec ? IPng ? ....), just let me know. > > Best regards. > Alain. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 11:40:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21427 for ; Fri, 9 Mar 2001 11:40:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26266; Fri, 9 Mar 2001 08:38:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09420; Fri, 9 Mar 2001 08:38:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29GaMo15998 for mobile-ip-dist; Fri, 9 Mar 2001 08:36:22 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29GaH115991 for ; Fri, 9 Mar 2001 08:36:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09238 for ; Fri, 9 Mar 2001 11:36:16 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA27502 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 11:36:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f296B3114385 for ; Thu, 8 Mar 2001 22:11:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28628 for ; Thu, 8 Mar 2001 22:11:03 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA07437 for ; Thu, 8 Mar 2001 22:11:02 -0800 (PST) Received: from Takevaio2 (dhcp41.docomo-usa.com [172.21.96.41]) by fridge.docomo-usa.com (Postfix) with SMTP id C7C0A97403 for ; Thu, 8 Mar 2001 22:16:08 -0800 (PST) Message-ID: <021301c0a85f$c2955560$296015ac@Takevaio2> From: "Atsushi Takeshita" To: References: Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 Date: Thu, 8 Mar 2001 22:11:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. While some low latency handoff methods assume the use of "L2 trigger", this I-D shows that the trigger can be L3-based. Please give us comments and critiques. Regard, Atsushi Takeshita ----- Original Message ----- From: "Youngjune Lee Gwon" To: "IETF Mobile-IP Working Group" Sent: Thursday, March 08, 2001 1:30 PM Subject: [mobile-ip] New I-D in L3 trigger based MIPv4 > We have submitted a new I-D on L3 triggered MIPv4 predictive > handoff. We'd like to have discussion in the WG regarding the > document. Your comments and critiques are appreciated. > > You may view the I-D at > > http://search.ietf.org/internet-drafts/draft-gwon-mobileip-l3mp-mipv4-00.txt > > Thanks, > > ---------------------------------------------- > Youngjune Gwon gyj@dcl.docomo-usa.com > Research Engineer > Mobile Internet Laboratory > DoCoMo Communications Laboratories USA, Inc. > > And, the Truth will set you free. - John 8:32 > ---------------------------------------------- > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 11:45:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21658 for ; Fri, 9 Mar 2001 11:45:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28077; Fri, 9 Mar 2001 08:43:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04289; Fri, 9 Mar 2001 08:43:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29GgJC16099 for mobile-ip-dist; Fri, 9 Mar 2001 08:42:19 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29GgE116092 for ; Fri, 9 Mar 2001 08:42:14 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23963 for ; Fri, 9 Mar 2001 11:42:14 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA27629 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 11:42:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2984b114665 for ; Fri, 9 Mar 2001 00:04:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09575 for ; Fri, 9 Mar 2001 00:04:38 -0800 (PST) Received: from smail-7.hanmail.net ([211.62.252.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21640 for ; Fri, 9 Mar 2001 01:04:37 -0700 (MST) Received: from www27.hanmail.net ([211.32.117.207]) by smail-7.hanmail.net (8.10.0/8.9.1) with ESMTP id f297xsi02679; Fri, 9 Mar 2001 16:59:54 +0900 Received: (from hanadmin@localhost) by www27.hanmail.net (8.10.0/8.9.1) id f297wqF17051; Fri, 9 Mar 2001 16:58:52 +0900 (KST) X-Originating-IP: [129.254.164.13] From: "ÀÌ°æÁø" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] security & smooth handoff X-Mailer: Daum Web Mailer 1.0 Date: Fri, 09 Mar 2001 16:58:52 KST Message-Id: <20010309165852.HM.Q0000000002QOOf@www27.hanmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to base64 by mercury.Sun.COM id IAA28077 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA21658 Dear all Main issues in MobileIPv6 are about security & smooth handoff. Those are main subjects for discussion in MobileIP WG meeting at IETF 50 Which should be solved more urgently in MobileIPv6? Tell me your opinion,please. ================================================== ¿ì¸® ÀÎÅͳÝ, Daum Æò»ý ¾²´Â ¹«·á E-mail ÁÖ¼Ò ÇѸÞÀÏ³Ý Áö±¸ÃÌ ÇÑ±Û °Ë»ö¼­ºñ½º Daum FIREBALL http://www.daum.net From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 11:48:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21889 for ; Fri, 9 Mar 2001 11:48:30 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29606; Fri, 9 Mar 2001 08:46:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16159; Fri, 9 Mar 2001 08:46:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29GiR416143 for mobile-ip-dist; Fri, 9 Mar 2001 08:44:27 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29GiM116134 for ; Fri, 9 Mar 2001 08:44:22 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24422 for ; Fri, 9 Mar 2001 11:44:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA27674 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 11:44:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2987L114683 for ; Fri, 9 Mar 2001 00:07:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09819 for ; Fri, 9 Mar 2001 00:07:22 -0800 (PST) Received: from mx03.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07046 for ; Fri, 9 Mar 2001 00:07:09 -0800 (PST) Received: by mx03.melco.co.jp (mx03) id RAA14884; Fri, 9 Mar 2001 17:07:05 +0900 (JST) Received: by mr01.melco.co.jp (mr01) id RAA13631; Fri, 9 Mar 2001 17:05:35 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id RAA29925; Fri, 9 Mar 2001 17:05:33 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id RAA04085; Fri, 9 Mar 2001 17:05:33 +0900 (JST) Message-ID: <02bc01c0a86f$d85c0780$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: Cc: "Ishibashi" Subject: [mobile-ip] Fast Handoffs (IPv4 & IPv6) Date: Fri, 9 Mar 2001 17:06:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all. I was looking into Mobile IP (rfc2002, Fast Handoffs drafts, etc) for one of our projects. Here, I am confusing. The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip- lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff. In this draft, the Registration procedure will be done pro-actively. On the other hand, the fast handoff for Mobile IPv6 draft proposes another mechanism.In this draft, the proposal associated with the Registration procedure is not described. I want to know why there is a difference between the fast handoff for Mobile IPv4 and Mobile IPv6. Sorry if this is a duplicate question. And I have another confusion. When I apply to the fast handoff for Mobile IPv4 (pro-active handoff) without the bi-casting, the loss of packets during the transition between networks will be eliminated. So, I am considering that a Home Agent should manage the handoff mechanism according to each microflow in order to simultaneously support both the real-time service and the non-real-time service. Clarifications are welcome. Thanks, Regards, Koichi Ishibashi From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 12:03:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22796 for ; Fri, 9 Mar 2001 12:03:54 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07445; Fri, 9 Mar 2001 09:02:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14002; Fri, 9 Mar 2001 09:02:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29H0Ij16334 for mobile-ip-dist; Fri, 9 Mar 2001 09:00:18 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29H0E116327 for ; Fri, 9 Mar 2001 09:00:14 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13834 for ; Fri, 9 Mar 2001 12:00:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA27987 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 12:00:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f299Gj114998 for ; Fri, 9 Mar 2001 01:16:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19846 for ; Fri, 9 Mar 2001 01:16:45 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28748 for ; Fri, 9 Mar 2001 01:16:43 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f299Ggd14223 for ; Fri, 9 Mar 2001 10:16:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA01768 for ; Fri, 9 Mar 2001 10:16:42 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f299GfA78954 for ; Fri, 9 Mar 2001 10:16:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103090916.f299GfA78954@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MobileIPv6 and IKE. In-reply-to: Your message of Thu, 08 Mar 2001 11:08:26 +0100. <3AA75A1A.BFB71AA@6wind.com> Date: Fri, 09 Mar 2001 10:16:41 +0100 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I'm interested in securing the MobileIPv6 exchanges, with the mandatory IPsec, and hence with IKE. The BU sent by the MN to its HA must ne authenticated, henc need an SA, but the HA can't speak to the MN untill the BU is accepted. How can IKE take place in such conditions ? Is there a solution to this chicken-and-egg pb ? If yes, is it a standard ? going to be one ? => I assume you have already read Mohan Parthasarathy's answer (and of course the end of the section 10.2 of the I-D 13). I believe we should add some conditions to the mandatory usage of the care-of address because if this is needed for the mobile node first home registration this can be expensive (and is no more needed) in other cases (the price is the authorization problem). Moreover while reading variuos RFC and drafts (mobility support for IPv6, Destination option header clarification, IPv6 soecs ..) I'm getting a little bit confused about the IPv6 extension headers order, or the real place some destination option may/should/must? take place wrt various destination options headers? Is there also something stbale ? standard ? for this. btw I'm interested in any good material/references about those subjects. => home address and tunnel encapsulation limit options should be in a destination option header just after the routing header (if any) and just before the fragmentation header (if any). Binding update, acknowledge and request options must be after IPsec headers (if any but AH is mandatory for the first two options) and before the upper layer header. There is no other defined useful destination option. If you feel, some subject should be discussed elswhere (IPsec? IPng ? ...), let me knwon. => IPng WG. You should look at IPng WG minutes of the last meeting but from here playground.sun.com/www.connectathon.org seems down... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 12:11:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23237 for ; Fri, 9 Mar 2001 12:11:36 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21992; Fri, 9 Mar 2001 09:07:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15050; Fri, 9 Mar 2001 09:07:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29H5rl16409 for mobile-ip-dist; Fri, 9 Mar 2001 09:05:53 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29H5i116402 for ; Fri, 9 Mar 2001 09:05:44 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14862 for ; Fri, 9 Mar 2001 12:05:44 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA28095 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 12:05:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f299Lr115023 for ; Fri, 9 Mar 2001 01:21:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19376 for ; Fri, 9 Mar 2001 01:21:53 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29015 for ; Fri, 9 Mar 2001 01:21:52 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f299Lod11243 for ; Fri, 9 Mar 2001 10:21:51 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA01847 for ; Fri, 9 Mar 2001 10:21:50 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f299LoA78976 for ; Fri, 9 Mar 2001 10:21:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200103090921.f299LoA78976@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MobileIPv6 mandatory IPSec In-reply-to: Your message of Thu, 08 Mar 2001 14:12:22 PST. Date: Fri, 09 Mar 2001 10:21:49 +0100 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I was unaware that Mobile IPv6 had close on IPSec being mandatory. This is a huge (40% overhead) for wireless traffic, not to mention the retries for dropped packets, etc. => Mobile IPv6 made IPsec mandatory only for critical parts of the signaling, not for all packets as your mail seems to suggest. What is the justification for making IPSec mandatory? => security is mandatory (do you need arguments about that?) for signaling, IPsec provides suitable security and IPsec is implemented by all conformant IPv6 implementations so why know simply use it? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 12:16:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23651 for ; Fri, 9 Mar 2001 12:16:17 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13272; Fri, 9 Mar 2001 09:14:40 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16332; Fri, 9 Mar 2001 09:14:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29HCbh16530 for mobile-ip-dist; Fri, 9 Mar 2001 09:12:37 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29HCV116519 for ; Fri, 9 Mar 2001 09:12:31 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16239 for ; Fri, 9 Mar 2001 12:12:31 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA28286 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 12:12:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Gjg116182 for ; Fri, 9 Mar 2001 08:45:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16011 for ; Fri, 9 Mar 2001 08:45:42 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA08211 for ; Fri, 9 Mar 2001 08:45:40 -0800 (PST) Date: Fri, 9 Mar 2001 08:41:11 -0800 (PST) From: Pat Calhoun Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <021301c0a85f$c2955560$296015ac@Takevaio2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > While some low latency handoff methods assume the use of "L2 trigger", > this I-D shows that the trigger can be L3-based. well, this isn't exactly something that we didn't know about. CDMA2000 does in fact use Layer 3 messages to "extend" the L2 signals to the foreign agents. This is necessary because the L2 termination point and the FA are not colocated. I believe that we've also discussed doing something similar for non colocated 802.11 APs and Foreign Agents. > Please give us comments and critiques. I think it would actually make alot of sense to define a standard L3 signalling method to do this, but wonder whether this really belongs in *this* WG, as opposed to, say, Seamoby. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 12:26:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24326 for ; Fri, 9 Mar 2001 12:26:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05577; Fri, 9 Mar 2001 09:24:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20633; Fri, 9 Mar 2001 09:23:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29HMHc16637 for mobile-ip-dist; Fri, 9 Mar 2001 09:22:17 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29HMD116630 for ; Fri, 9 Mar 2001 09:22:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17714 for ; Fri, 9 Mar 2001 12:22:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA28512 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 12:22:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29HKW116618 for ; Fri, 9 Mar 2001 09:20:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19859 for ; Fri, 9 Mar 2001 09:20:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02645 for ; Fri, 9 Mar 2001 09:20:30 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f29HKTC06458 for ; Fri, 9 Mar 2001 18:20:29 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 09 18:20:33 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 18:16:34 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 Date: Fri, 9 Mar 2001 18:20:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Please give us comments and critiques. > > I think it would actually make alot of sense to define a standard L3 > signalling method to do this, but wonder whether this really belongs in *this* > WG, as opposed to, say, Seamoby. > => There is one already, it is called the router/agent advertisement. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 13:16:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27592 for ; Fri, 9 Mar 2001 13:16:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10861; Fri, 9 Mar 2001 10:14:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03124; Fri, 9 Mar 2001 10:14:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29ICfN16862 for mobile-ip-dist; Fri, 9 Mar 2001 10:12:41 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29ICb116855 for ; Fri, 9 Mar 2001 10:12:37 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10237 for ; Fri, 9 Mar 2001 13:12:36 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA29493 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 13:12:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29HPP116686 for ; Fri, 9 Mar 2001 09:25:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24001 for ; Fri, 9 Mar 2001 09:25:26 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14989 for ; Fri, 9 Mar 2001 09:25:25 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29865 for ; Fri, 9 Mar 2001 09:25:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACC39305; Fri, 9 Mar 2001 09:25:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22037; Fri, 9 Mar 2001 09:25:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15017.4611.979081.267794@thomasm-u1.cisco.com> Date: Fri, 9 Mar 2001 09:25:23 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 In-Reply-To: References: <021301c0a85f$c2955560$296015ac@Takevaio2> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pat Calhoun writes: > > While some low latency handoff methods assume the use of "L2 trigger", > > this I-D shows that the trigger can be L3-based. > > well, this isn't exactly something that we didn't know about. CDMA2000 does in > fact use Layer 3 messages to "extend" the L2 signals to the foreign agents. > This is necessary because the L2 termination point and the FA are not > colocated. > > I believe that we've also discussed doing something similar for non colocated > 802.11 APs and Foreign Agents. > > > Please give us comments and critiques. > > I think it would actually make alot of sense to define a standard L3 > signalling method to do this, but wonder whether this really belongs in *this* > WG, as opposed to, say, Seamoby. I sort of wonder whether it belongs in IETF at all. Traditionally, if you want L3/router functionality at a particular place, you -- ta da -- put a router there. Defining L3 backhaul for each and every L2 along with all of their idiosynchracies seems like a pretty horrifying prospect. It's not like basic routing functionality is all that hard to come by these days. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 13:19:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27747 for ; Fri, 9 Mar 2001 13:19:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12979; Fri, 9 Mar 2001 10:18:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03887; Fri, 9 Mar 2001 10:17:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29IGPe16917 for mobile-ip-dist; Fri, 9 Mar 2001 10:16:25 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IGJ116906 for ; Fri, 9 Mar 2001 10:16:19 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10875 for ; Fri, 9 Mar 2001 13:16:19 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA29568 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 13:16:23 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29HkD116778 for ; Fri, 9 Mar 2001 09:46:13 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23572 for ; Fri, 9 Mar 2001 09:46:13 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA13665 for ; Fri, 9 Mar 2001 09:46:13 -0800 (PST) Message-Id: <200103091746.JAA13665@heliopolis.Eng.Sun.COM> Date: Fri, 9 Mar 2001 09:46:13 -0800 (PST) From: James Kempf Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4GVyhm4EwbiJVBjP2GqVtA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > >> > Please give us comments and critiques. >> >> I think it would actually make alot of sense to define a standard L3 >> signalling method to do this, but wonder whether this really belongs in *this* >> WG, as opposed to, say, Seamoby. >> > => There is one already, it is called the router/agent advertisement. > IMHO, router/agent adverts aren't handoff co-ordinating signalling, they are signalling to alert the mobile node that a new route option is available for routing their traffic. There is no specific handoff co-ordinating signalling in base MIPv4/v6. The low latency handoff drafts add such signalling. Furthermore, if you look at this draft, you will see that there is a proposal for an "L3 beacon". Now, as far as I can tell, RFC 2002 and the MIPv6 draft *already* make provision for an L3 beacon, which, as you point out, is a router/agent advert. The only real new contribution in this draft that I can detect is Section 6.1, which describes ways of doing movement prediction based on measurments at L3 as opposed to L2. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:05:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06811 for ; Fri, 9 Mar 2001 17:05:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11935; Fri, 9 Mar 2001 14:02:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17194; Fri, 9 Mar 2001 14:02:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29M16e17653 for mobile-ip-dist; Fri, 9 Mar 2001 14:01:06 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29M11117646 for ; Fri, 9 Mar 2001 14:01:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03766 for ; Fri, 9 Mar 2001 17:01:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA07577 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:01:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IJk116992 for ; Fri, 9 Mar 2001 10:19:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26034 for ; Fri, 9 Mar 2001 10:19:46 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13989 for ; Fri, 9 Mar 2001 10:19:44 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f29IJhC18633 for ; Fri, 9 Mar 2001 19:19:43 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 09 19:19:46 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 19:15:48 +0100 Message-ID: From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , "'Koichi Ishibashi'" Subject: RE: [mobile-ip] Fast Handoffs (IPv4 & IPv6) Date: Fri, 9 Mar 2001 19:19:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello > Here, I am confusing. > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip- > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff. Low latency Handoffs proposes two methods: - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff - Network Initiated, Mobile Terminated (NIMOT) Handoff This is the combination of two existing drafts. The first method comes from draft-elmalki-mobileip-fast-handoffs-03 and the second is from draft-calhoun-mobileip-proactive-fa-03. > In this draft, the Registration procedure will be done pro-actively. > On the other hand, the fast handoff for Mobile IPv6 draft proposes > another mechanism. The v4 and v6 drafts do not propose completely different mechanisms. You can run a similar handoff procedure in v4 and v6. However you may be pointing to a NIMOT-like approach in v6? > And I have another confusion. > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff) > without the bi-casting, the loss of packets during the transition > between networks will be eliminated. If you don't use bicasting (independently of the method supported) then achieving a loss-less v4 handoff depends on when the MN actually disconnects from the old FA and connects to the new one, if buffering is available etc. This needs more looking into and hopefully we'll get some discussion going at this IETF. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:17:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07315 for ; Fri, 9 Mar 2001 17:17:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16019; Fri, 9 Mar 2001 14:14:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29945; Fri, 9 Mar 2001 14:14:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MCEP17761 for mobile-ip-dist; Fri, 9 Mar 2001 14:12:14 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MCA117754 for ; Fri, 9 Mar 2001 14:12:10 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17672 for ; Fri, 9 Mar 2001 17:12:11 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA07803 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:12:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29IhZ117160 for ; Fri, 9 Mar 2001 10:43:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12840 for ; Fri, 9 Mar 2001 10:43:35 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26166 for ; Fri, 9 Mar 2001 10:43:34 -0800 (PST) Received: by fridge.docomo-usa.com (Postfix, from userid 119) id 5E37397401; Fri, 9 Mar 2001 10:48:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fridge.docomo-usa.com (Postfix) with ESMTP id 5D24997801 for ; Fri, 9 Mar 2001 10:48:42 -0800 (PST) Date: Fri, 9 Mar 2001 10:48:42 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 In-Reply-To: <200103091746.JAA13665@heliopolis.Eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I thought the router advt may be too heavy for this predictive L3 link evaluation capability discussd in the draft. Minimizing the L3 control signaling (if we can), seems quite significant in the operator's point of view. ---------------------------------------------- Youngjune Gwon gyj@dcl.docomo-usa.com Research Engineer Mobile Internet Laboratory DoCoMo Communications Laboratories USA, Inc. And, the Truth will set you free. - John 8:32 ---------------------------------------------- On Fri, 9 Mar 2001, James Kempf wrote: > Hesham, > > > > > >> > Please give us comments and critiques. > >> > >> I think it would actually make alot of sense to define a standard L3 > >> signalling method to do this, but wonder whether this really belongs in > *this* > >> WG, as opposed to, say, Seamoby. > >> > > => There is one already, it is called the router/agent advertisement. > > > > IMHO, router/agent adverts aren't handoff co-ordinating signalling, they > are signalling to alert the mobile node that a new route option is > available for routing their traffic. There is no specific handoff > co-ordinating signalling in base MIPv4/v6. The low latency handoff > drafts add such signalling. > > Furthermore, if you look at this draft, you will see that there is > a proposal for an "L3 beacon". Now, as far as I can tell, RFC 2002 > and the MIPv6 draft *already* make provision for an L3 beacon, which, > as you point out, is a router/agent advert. The only real new contribution > in this draft that I can detect is Section 6.1, which describes ways > of doing movement prediction based on measurments at L3 as opposed to L2. > > > jak > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:19:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07369 for ; Fri, 9 Mar 2001 17:19:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08529; Fri, 9 Mar 2001 14:18:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00878; Fri, 9 Mar 2001 14:17:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MG9N17828 for mobile-ip-dist; Fri, 9 Mar 2001 14:16:09 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MG4117821 for ; Fri, 9 Mar 2001 14:16:04 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18167 for ; Fri, 9 Mar 2001 17:16:05 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA07877 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:16:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Ixo117222 for ; Fri, 9 Mar 2001 10:59:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11812 for ; Fri, 9 Mar 2001 10:59:50 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04325 for ; Fri, 9 Mar 2001 10:59:48 -0800 (PST) Received: by fridge.docomo-usa.com (Postfix, from userid 119) id D710A97401; Fri, 9 Mar 2001 11:04:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fridge.docomo-usa.com (Postfix) with ESMTP id D604897801 for ; Fri, 9 Mar 2001 11:04:55 -0800 (PST) Date: Fri, 9 Mar 2001 11:04:55 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pat, I'm sure MDM is still a scope of MIP WG. I'm only trying to define a L3 based mechanism that can be used for predictive MIP handoff. I believe the MDM in RFC2002 is yet insufficient for this purpose. While defining a new L3 signaling format may be redundant, my view on the cost of using router advt for the mobility prediction (described in this draft) may be too high. Thanks, ---------------------------------------------- Youngjune Gwon gyj@dcl.docomo-usa.com Research Engineer Mobile Internet Laboratory DoCoMo Communications Laboratories USA, Inc. And, the Truth will set you free. - John 8:32 ---------------------------------------------- On Fri, 9 Mar 2001, Pat Calhoun wrote: > > While some low latency handoff methods assume the use of "L2 trigger", > > this I-D shows that the trigger can be L3-based. > > well, this isn't exactly something that we didn't know about. CDMA2000 does in > fact use Layer 3 messages to "extend" the L2 signals to the foreign agents. > This is necessary because the L2 termination point and the FA are not > colocated. > > I believe that we've also discussed doing something similar for non colocated > 802.11 APs and Foreign Agents. > > > Please give us comments and critiques. > > I think it would actually make alot of sense to define a standard L3 > signalling method to do this, but wonder whether this really belongs in *this* > WG, as opposed to, say, Seamoby. > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:28:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07874 for ; Fri, 9 Mar 2001 17:28:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15152; Fri, 9 Mar 2001 14:27:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23159; Fri, 9 Mar 2001 14:26:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MPIT17992 for mobile-ip-dist; Fri, 9 Mar 2001 14:25:18 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MPD117985 for ; Fri, 9 Mar 2001 14:25:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07117 for ; Fri, 9 Mar 2001 17:25:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08062 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:25:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29JDN117345 for ; Fri, 9 Mar 2001 11:13:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20440 for ; Fri, 9 Mar 2001 11:13:22 -0800 (PST) From: Phil_Neumiller@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02136 for ; Fri, 9 Mar 2001 12:13:21 -0700 (MST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29JBw009859 for ; Fri, 9 Mar 2001 11:11:58 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f29JDLI21920 for ; Fri, 9 Mar 2001 11:13:21 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A0A.0069BD38 ; Fri, 9 Mar 2001 11:14:55 -0800 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A0A.0069BAE8.00@hqoutbound.ops.3com.com> Date: Fri, 9 Mar 2001 13:12:18 -0600 Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Yes, I would tend to concur with Pat on this one. There is a LOT of prior history on this in the IETF. IAPP (inter access point protocol) was as submitted as a draft to the IETF a few yrs ago and largely ignored. IAPP has been implemented by a few 802.11 AP vendors. The IEEE 802.11 TG F is currently working on a rejuvination of IAPP and I am attempting to get some coordination between them and SeaMoby. I think that a more appropriate venue for this work would indeed be the SeaMoby context transfer and perhaps the micro-mobility design team. I will review the draft with great interest since some work I was involved with in the past incorporated such concepts. Thanks, Phil Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com cc: (Phil Neumiller/MW/US/3Com) Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 > While some low latency handoff methods assume the use of "L2 trigger", > this I-D shows that the trigger can be L3-based. well, this isn't exactly something that we didn't know about. CDMA2000 does in fact use Layer 3 messages to "extend" the L2 signals to the foreign agents. This is necessary because the L2 termination point and the FA are not colocated. I believe that we've also discussed doing something similar for non colocated 802.11 APs and Foreign Agents. > Please give us comments and critiques. I think it would actually make alot of sense to define a standard L3 signalling method to do this, but wonder whether this really belongs in *this* WG, as opposed to, say, Seamoby. PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:31:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08072 for ; Fri, 9 Mar 2001 17:31:57 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22319; Fri, 9 Mar 2001 14:30:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00720; Fri, 9 Mar 2001 14:30:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MSx318078 for mobile-ip-dist; Fri, 9 Mar 2001 14:28:59 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MSq118063 for ; Fri, 9 Mar 2001 14:28:53 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19948 for ; Fri, 9 Mar 2001 17:28:53 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08134 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:28:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29JjL117422 for ; Fri, 9 Mar 2001 11:45:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24648 for ; Fri, 9 Mar 2001 11:45:16 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26351 for ; Fri, 9 Mar 2001 11:45:15 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 9 Mar 2001 13:34:47 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 13:39:48 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E430176C465@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Date: Fri, 9 Mar 2001 13:39:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A8D0.ADCA15A0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0A8D0.ADCA15A0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8D0.ADCA15A0" ------_=_NextPart_001_01C0A8D0.ADCA15A0 Content-Type: text/plain; charset="iso-8859-1" Hello, I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in. Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain? Respectfully, I wish to be illuminated on this - one way or the other. Thanks, Glenn -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 09, 2001 6:35 AM To: IETF-Announce Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Regional Registrations Author(s) : J. Malinen, F. Le, C. Perkins Filename : draft-malinen-mobileip-regreg6-01.txt Pages : 28 Date : 08-Mar-01 This document describes Mobile IPv6 regional registration as an optional extension to Mobile IPv6. Regional registration introduces visited-domain mobility agent functionality for proxying a public care-of-address which remains the same while the mobile node moves in the visited domain. This reduces the binding update signaling latency for the mobile node and signaling load outside the visited domain. The protocol defines regional mobility capability negotiation, regional binding update signaling, and regional-aware data routing through a hierarchy of visited-domain mobility agents. The protocol allows for an arbitrary point in the visited-domain hierarchy to distribute the connection-state maintenance between several mobility agents. IPSec AH is used for securing the protocol as in basic Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt 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-malinen-mobileip-regreg6-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-malinen-mobileip-regreg6-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_001_01C0A8D0.ADCA15A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt

Hello,

I still do not understand why the ability to place = something at an arbitrary point justifies destroying the connectionless = nature of a IP or even IP mobility.

If arbitrary point is so important, why don't you = just tunnel to the arbitrary point based upon routing policy and leave = a natural aggregatable solution connectionless. People can always = tinker with their routes to make single points of failure if they wish = but why build it in.

Have people simply given up on keeping things = connectionless? Is there some sort of graph theory that somehow proves = that this is a connection oriented problem domain?

Respectfully, I wish to be illuminated on this - one = way or the other.

Thanks,

Glenn

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Friday, March 09, 2001 6:35 AM
To: IETF-Announce
Subject: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Mobile IPv6 Regional Registrations
        Author(s)       : J. Malinen, F. = Le, C. Perkins
        Filename        : = draft-malinen-mobileip-regreg6-01.txt
        Pages           : = 28
        Date    =         : 08-Mar-01
       =20
This document describes Mobile IPv6 regional = registration as an
optional extension to Mobile IPv6.  Regional = registration introduces
visited-domain mobility agent functionality for = proxying a public
care-of-address which remains the same while the = mobile node
moves in the visited domain.  This reduces the = binding update
signaling latency for the mobile node and signaling = load outside the
visited domain.  The protocol defines regional = mobility capability
negotiation, regional binding update signaling, and = regional-aware
data routing through a hierarchy of visited-domain = mobility agents.
The protocol allows for an arbitrary point in the = visited-domain
hierarchy to distribute the connection-state = maintenance between
several mobility agents.  IPSec AH is used for = securing the protocol
as in basic Mobile IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malinen-mobi= leip-regreg6-01.txt

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-malinen-mobileip-regreg6-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-malinen-mobileip-regreg6-01.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C0A8D0.ADCA15A0-- ------_=_NextPart_000_01C0A8D0.ADCA15A0 Content-Type: message/rfc822 To: Subject: Date: Fri, 9 Mar 2001 10:58:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A8D0.ADCA15A0" ------_=_NextPart_002_01C0A8D0.ADCA15A0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C0A8D0.ADCA15A0" ------_=_NextPart_003_01C0A8D0.ADCA15A0 Content-Type: text/plain ------_=_NextPart_003_01C0A8D0.ADCA15A0 Content-Type: text/html

  ------_=_NextPart_003_01C0A8D0.ADCA15A0-- ------_=_NextPart_002_01C0A8D0.ADCA15A0 Content-Type: application/octet-stream; name="ATT33012.txt" Content-Disposition: attachment; filename="ATT33012.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-malinen-mobileip-regreg6-01.txt ------_=_NextPart_002_01C0A8D0.ADCA15A0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-malinen-mobileip-regreg6-01"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A8D0.ADCA15A0-- ------_=_NextPart_000_01C0A8D0.ADCA15A0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:41:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08422 for ; Fri, 9 Mar 2001 17:41:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23448; Fri, 9 Mar 2001 14:39:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29407; Fri, 9 Mar 2001 14:39:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MbOJ18282 for mobile-ip-dist; Fri, 9 Mar 2001 14:37:24 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MbJ118275 for ; Fri, 9 Mar 2001 14:37:20 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08599 for ; Fri, 9 Mar 2001 17:37:20 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08417 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:37:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Jqb117434 for ; Fri, 9 Mar 2001 11:52:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23907 for ; Fri, 9 Mar 2001 11:52:37 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16725 for ; Fri, 9 Mar 2001 11:52:37 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 9 Mar 2001 13:49:39 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 13:49:38 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E430176C48D@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] security & smooth handoff Date: Fri, 9 Mar 2001 13:49:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8D2.106AFF20" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A8D2.106AFF20 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable IMHO - security -----Original Message----- From: =7F=7F=7F=7F=7F=7F [mailto:illiad77@hanmail.net] Sent: Friday, March 09, 2001 10:59 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] security & smooth handoff Dear all Main issues in MobileIPv6 are about security & smooth handoff. Those are main subjects for discussion in MobileIP WG meeting at IETF = 50=20 Which should be solved more urgently in MobileIPv6? Tell me your opinion,please. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =BF=EC=B8=AE =C0=CE=C5=CD=B3=DD, Daum =C6=F2=BB=FD =BE=B2=B4=C2 =B9=AB=B7=E1 E-mail =C1=D6=BC=D2 = =C7=D1=B8=DE=C0=CF=B3=DD =C1=F6=B1=B8=C3=CC =C7=D1=B1=DB =B0=CB=BB=F6=BC=AD=BA=F1=BD=BA Daum = FIREBALL http://www.daum.net ------_=_NextPart_001_01C0A8D2.106AFF20 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] security & smooth handoff

IMHO - security

-----Original Message-----
From: =7F=7F=7F=7F=7F=7F [mailto:illiad77@hanmail.net]
Sent: Friday, March 09, 2001 10:59 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] security & smooth = handoff


Dear all

Main issues in MobileIPv6 are about security & = smooth handoff.
Those are main subjects for discussion in MobileIP = WG meeting at IETF 50

Which should be solved more urgently in = MobileIPv6?
Tell me your opinion,please.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=BF=EC=B8=AE =C0=CE=C5=CD=B3=DD, Daum
=C6=F2=BB=FD =BE=B2=B4=C2 =B9=AB=B7=E1 E-mail = =C1=D6=BC=D2 =C7=D1=B8=DE=C0=CF=B3=DD
=C1=F6=B1=B8=C3=CC =C7=D1=B1=DB = =B0=CB=BB=F6=BC=AD=BA=F1=BD=BA Daum FIREBALL
http://www.daum.net

------_=_NextPart_001_01C0A8D2.106AFF20-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:47:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08661 for ; Fri, 9 Mar 2001 17:47:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28512; Fri, 9 Mar 2001 14:46:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07676; Fri, 9 Mar 2001 14:46:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MhpI18449 for mobile-ip-dist; Fri, 9 Mar 2001 14:43:51 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Mhl118442 for ; Fri, 9 Mar 2001 14:43:47 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09283 for ; Fri, 9 Mar 2001 17:43:47 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08548 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:43:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29KtQ117575 for ; Fri, 9 Mar 2001 12:55:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12912 for ; Fri, 9 Mar 2001 12:55:24 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14510 for ; Fri, 9 Mar 2001 12:55:23 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f29KtLd26523 for ; Fri, 9 Mar 2001 21:55:21 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 09 21:56:58 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 21:55:20 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 Date: Fri, 9 Mar 2001 21:55:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > >> I think it would actually make alot of sense to define a standard L3 > >> signalling method to do this, but wonder whether this really belongs in > *this* > >> WG, as opposed to, say, Seamoby. > >> > > => There is one already, it is called the router/agent advertisement. > > > > IMHO, router/agent adverts aren't handoff co-ordinating signalling, they > are signalling to alert the mobile node that a new route option is > available for routing their traffic. There is no specific handoff > co-ordinating signalling in base MIPv4/v6. > => Well they tell you that you've changed (or about to change if you use the low latency draft) subnet. That's what you need to initiate an IP layer handover. That's what you need for IP movement detection. > Furthermore, if you look at this draft, you will see that there is > a proposal for an "L3 beacon". Now, as far as I can tell, RFC 2002 > and the MIPv6 draft *already* make provision for an L3 beacon, which, > as you point out, is a router/agent advert. The only real new contribution > in this draft that I can detect is Section 6.1, which describes ways > of doing movement prediction based on measurments at L3 as opposed to L2. > => Exactly. Based on my quick read, it provides a way of sending such L3 indication (advertisement). Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:51:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08855 for ; Fri, 9 Mar 2001 17:51:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01265; Fri, 9 Mar 2001 14:50:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29882; Fri, 9 Mar 2001 14:50:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MnID18529 for mobile-ip-dist; Fri, 9 Mar 2001 14:49:18 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MnD118521 for ; Fri, 9 Mar 2001 14:49:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22190 for ; Fri, 9 Mar 2001 17:49:14 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08712 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:49:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MQX118003 for ; Fri, 9 Mar 2001 14:26:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26491 for ; Fri, 9 Mar 2001 14:26:34 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12315 for ; Fri, 9 Mar 2001 14:26:32 -0800 (PST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 9 Mar 2001 17:15:46 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 17:15:46 -0500 Message-ID: From: "Muhammad Jaseemuddin" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Fast Handovers in MIPv6 - flags Date: Fri, 9 Mar 2001 17:15:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8E6.7BF7B670" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A8E6.7BF7B670 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I have a slightly different question related to the B and U flag bits = in BU option. I will appreciate if the design team can provide a rationale = for that. See my question below. > -----Original Message----- > From: J=F8rn Hunskaar [SMTP:jorn.hunskaar@siving.hia.no] > Sent: Tuesday, March 06, 2001 2:07 AM > To: mobile-ip > Subject: [mobile-ip] Fast Handovers in MIPv6 - flags >=20 > Hi, >=20 > Fast Handovers for MIPv6 (draft-ietf-mobileip-fast-mipv6-00.txt) > suggests that the Binding Update Option should be changed by adding = two > more flags, B and U, to the flag bits. The intention is to indicate = that > the mobile node would like the (old) access router to do bicasting = and > buffering. The draft also specifies that the access router MAY honor > these requests or reject them silently. >=20 > When a BU is sent to the oldAR, the traffic will be redirected to the = MN > by the way of the newAR. Since a fast handover procedure has been > initiated (either through a RtSolPr or PrRtAdv message), the MN would > like the handover to be fast and with a small packet loss. = Consequently, > both the B and U bit will probably be set by the MN to improve the > handover quality. >=20 > In other words, the MN will set the bits to make the handover as fast = as > possible. If these requests are silently ignored by the oldAR (when = the > MN is a part of a fast handover procedure), this is most likely due = to > link-layer conditions or because of insufficient resources. >=20 > Why use these bits in the Binding Update Option when they probably = will > be set all the time anyway? Maybe supporting bicasting and buffering > should be made mandatory in the oldAR when using fast handovers? >=20 [MJ] It seems that bicasting and buffering are network engineering issues and mobiles need not dictate the network which approach(es) to = take. How would a mobile know that the network supports bicasting or = buffering? I don't recall that these capabilities are annouced in the RA.=20 > Regards, > Jorn ------_=_NextPart_001_01C0A8E6.7BF7B670 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Fast Handovers in MIPv6 - flags

I have a slightly = different question related to the B and U flag bits in BU option. I = will appreciate if the design team can provide a rationale for that. = See my question below.

    -----Original Message-----
    From:   J=F8rn Hunskaar = [SMTP:jorn.hunskaar@siving.hia.no]
    Sent:   Tuesday, March 06, 2001 2:07 AM
    To:     mobile-ip
    Subject:       = [mobile-ip] Fast Handovers in MIPv6 = - flags

    Hi,

    Fast Handovers for MIPv6 = (draft-ietf-mobileip-fast-mipv6-00.txt)
    suggests that the Binding Update = Option should be changed by adding two
    more flags, B and U, to the flag = bits. The intention is to indicate that
    the mobile node would like the (old) = access router to do bicasting and
    buffering. The draft also specifies = that the access router MAY honor
    these requests or reject them = silently.

    When a BU is sent to the oldAR, the = traffic will be redirected to the MN
    by the way of the newAR. Since a fast = handover procedure has been
    initiated (either through a RtSolPr = or PrRtAdv message), the MN would
    like the handover to be fast and with = a small packet loss. Consequently,
    both the B and U bit will probably be = set by the MN to improve the
    handover quality.

    In other words, the MN will set the = bits to make the handover as fast as
    possible. If these requests are = silently ignored by the oldAR (when the
    MN is a part of a fast handover = procedure), this is most likely due to
    link-layer conditions or because of = insufficient resources.

    Why use these bits in the Binding = Update Option when they probably will
    be set all the time anyway? Maybe = supporting bicasting and buffering
    should be made mandatory in the oldAR = when using fast handovers?

    [MJ]  It seems that bicasting and buffering are = network engineering issues and mobiles need not dictate the network = which approach(es) to take. How would  a mobile know that the = network supports bicasting or buffering? I don't recall that these = capabilities are annouced in the RA.

    Regards,
    Jorn

------_=_NextPart_001_01C0A8E6.7BF7B670-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 17:57:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09103 for ; Fri, 9 Mar 2001 17:57:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01466; Fri, 9 Mar 2001 14:56:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09813; Fri, 9 Mar 2001 14:56:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29MsEY18636 for mobile-ip-dist; Fri, 9 Mar 2001 14:54:14 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Ms9118629 for ; Fri, 9 Mar 2001 14:54:09 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10572 for ; Fri, 9 Mar 2001 17:54:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA08812 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 17:54:15 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29MVe118139 for ; Fri, 9 Mar 2001 14:31:40 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24267 for ; Fri, 9 Mar 2001 14:31:42 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA09619 for ; Fri, 9 Mar 2001 14:31:41 -0800 (PST) Message-Id: <200103092231.OAA09619@heliopolis.Eng.Sun.COM> Date: Fri, 9 Mar 2001 14:31:41 -0800 (PST) From: James Kempf Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8pUTr/8ebSbWoXD5pWiokA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Youngjune, >I thought the router advt may be too heavy for this predictive L3 link >evaluation capability discussd in the draft. Minimizing the L3 control >signaling (if we can), seems quite significant in the operator's >point of view. If you are proposing this as a replacement for the basic router/agent advert mechanism, then I think you need to give some justification why the basic router/agent advert mechanism is insufficient. Why is it too heavyweight? Maybe the solution is to reduce the overhead on the router/agent advert. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 18:15:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09687 for ; Fri, 9 Mar 2001 18:15:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07275; Fri, 9 Mar 2001 15:12:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14078; Fri, 9 Mar 2001 15:12:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29N9s018747 for mobile-ip-dist; Fri, 9 Mar 2001 15:09:54 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29N9n118740 for ; Fri, 9 Mar 2001 15:09:49 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12196 for ; Fri, 9 Mar 2001 18:09:49 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA09119 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 18:09:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29Mwa118710 for ; Fri, 9 Mar 2001 14:58:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08341 for ; Fri, 9 Mar 2001 14:58:36 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25555 for ; Fri, 9 Mar 2001 14:58:34 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f29MwXd14263 for ; Fri, 9 Mar 2001 23:58:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sat Mar 10 00:00:10 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 23:58:32 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Fast Handovers in MIPv6 - flags Date: Fri, 9 Mar 2001 23:58:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I have a slightly different question related to the B and U flag bits in BU option. I will appreciate if the design team can provide a rationale for that. See my question below. > > > Fast Handovers for MIPv6 (draft-ietf-mobileip-fast-mipv6-00.txt) > suggests that the Binding Update Option should be changed by adding two > more flags, B and U, to the flag bits. The intention is to indicate that > the mobile node would like the (old) access router to do bicasting and > buffering. The draft also specifies that the access router MAY honor > these requests or reject them silently. > > When a BU is sent to the oldAR, the traffic will be redirected to the MN > by the way of the newAR. Since a fast handover procedure has been > initiated (either through a RtSolPr or PrRtAdv message), the MN would > like the handover to be fast and with a small packet loss. Consequently, > both the B and U bit will probably be set by the MN to improve the > handover quality. > > In other words, the MN will set the bits to make the handover as fast as > possible. If these requests are silently ignored by the oldAR (when the > MN is a part of a fast handover procedure), this is most likely due to > link-layer conditions or because of insufficient resources. > > => I agree that they should not be silently ignored > this is something we need to fix in the next revision. > > > Why use these bits in the Binding Update Option when they probably will > be set all the time anyway? Maybe supporting bicasting and buffering > should be made mandatory in the oldAR when using fast handovers? > > [MJ] It seems that bicasting and buffering are network engineering issues and mobiles need not dictate the network which approach(es) to take. How would a mobile know that the network supports bicasting or buffering? I don't recall that these capabilities are annouced in the RA. > > => If the AR doesn't support the B and /or U flags then it should indicate > so in the BAck. The MN needs to request this (especially the B flag) > because the timer in the BUL for the lifetime of the BU MUST be > aligned with the lifetime of the Binding Cache entry in the AR. > > Regards, > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 9 19:02:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11340 for ; Fri, 9 Mar 2001 19:02:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09694; Fri, 9 Mar 2001 16:00:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23826; Fri, 9 Mar 2001 16:00:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f29NwFx18863 for mobile-ip-dist; Fri, 9 Mar 2001 15:58:15 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29NwA118856 for ; Fri, 9 Mar 2001 15:58:10 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16466 for ; Fri, 9 Mar 2001 18:58:11 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA10064 for mobile-ip@sunroof.eng.sun.com; Fri, 9 Mar 2001 18:58:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f29NQF118836 for ; Fri, 9 Mar 2001 15:26:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15018 for ; Fri, 9 Mar 2001 15:26:16 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21153 for ; Fri, 9 Mar 2001 15:26:14 -0800 (PST) Received: by fridge.docomo-usa.com (Postfix, from userid 119) id 3B70397401; Fri, 9 Mar 2001 15:31:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fridge.docomo-usa.com (Postfix) with ESMTP id 32B6D97801 for ; Fri, 9 Mar 2001 15:31:15 -0800 (PST) Date: Fri, 9 Mar 2001 15:31:15 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New I-D in L3 trigger based MIPv4 In-Reply-To: <200103092231.OAA09619@heliopolis.Eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > If you are proposing this as a replacement for the basic router/agent > advert mechanism, then I think you need to give some justification > why the basic router/agent advert mechanism is insufficient. ==> I'm not trying to replace or outdate the router/agent advt mechanism. Prediction can be based upon keeping track of the receptions of router advt messages if frequent enough transmissions of advt messages is permitted, e.g. in the order of less (or at most) 100ms beaconing period. > Maybe the solution is to reduce the overhead on the router/agent advert. ==> I agree with you. Thanks, Youngjune From ronyoung@nortelnetworks.com Sun Mar 11 06:13:21 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09152 for ; Sun, 11 Mar 2001 06:13:21 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sun, 11 Mar 2001 04:37:29 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sun, 11 Mar 2001 04:31:23 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id FAA23620 for ; Sun, 11 Mar 2001 05:20:17 -0500 (EST) Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com; Sun, 11 Mar 2001 05:17:52 -0500 Received: from infomail.es (ncc1.infomail.es [195.235.39.3]) by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5); Sun, 11 Mar 2001 05:20:03 -0500 Received: from upcnet.es ([62.82.146.75]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #984306026.015180001; Sun, 11 Mar 2001 11:20:26 +0100 Message-ID: <3AAB52FF.4567E730@upcnet.es> Date: Sun, 11 Mar 2001 11:27:11 +0100 From: Oscar de Luis X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: es,en,ca MIME-Version: 1.0 To: MOBILE-IP@marvin.corpeast.baynetworks.com, mobile-ip@sunroof.eng.sun.com Subject: unsubscribe mobile-ip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Infomail-Id: 984306026.05EE010A811066.6026 X-SMTP-HELO: infomail.es X-SMTP-MAIL-FROM: oscar.de.luis@upcnet.es X-SMTP-RCPT-TO: MOBILE-IP@standards.nortelnetworks.com X-SMTP-PEER-INFO: ncc1.infomail.es [195.235.39.3] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Sun Mar 11 06:23:51 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09153 for ; Sun, 11 Mar 2001 06:13:21 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Sun, 11 Mar 2001 04:37:29 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Sun, 11 Mar 2001 04:31:24 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id FAA23590 for ; Sun, 11 Mar 2001 05:17:06 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Sun, 11 Mar 2001 05:16:55 -0500 Received: from infomail.es (ncc1.infomail.es [195.235.39.3]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Sun, 11 Mar 2001 05:16:53 -0500 Received: from upcnet.es ([62.82.146.75]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #984305836.009140001; Sun, 11 Mar 2001 11:17:16 +0100 Message-ID: <3AAB5240.2BC46894@upcnet.es> Date: Sun, 11 Mar 2001 11:24:00 +0100 From: Oscar de Luis X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: es,en,ca MIME-Version: 1.0 To: MOBILE-IP@marvin.corpeast.baynetworks.com, mobile-ip@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: unsubscribe mobile-ip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Infomail-Id: 984305836.0392010A811066.5836 X-SMTP-HELO: infomail.es X-SMTP-MAIL-FROM: oscar.de.luis@upcnet.es X-SMTP-RCPT-TO: MOBILE-IP@standards.nortelnetworks.com X-SMTP-PEER-INFO: ncc1.infomail.es [195.235.39.3] X-Orig: X-Orig: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From ronyoung@nortelnetworks.com Mon Mar 12 04:31:34 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06204 for ; Mon, 12 Mar 2001 04:31:34 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Mon, 12 Mar 2001 03:14:09 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Mon, 12 Mar 2001 03:15:38 -0600 Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id EAA25946 for ; Mon, 12 Mar 2001 04:08:05 -0500 (EST) Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com; Mon, 12 Mar 2001 04:07:55 -0500 Received: from web10006.mail.yahoo.com (web10006.mail.yahoo.com [216.136.130.42]) by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5); Mon, 12 Mar 2001 04:07:53 -0500 Message-ID: <20010312090644.40058.qmail@web10006.mail.yahoo.com> Received: from [137.132.3.6] by web10006.mail.yahoo.com; Mon, 12 Mar 2001 01:06:44 PST Date: Mon, 12 Mar 2001 01:06:44 -0800 (PST) From: Stefan Moebius Subject: Question: MobileIP and NAT To: MOBILE-IP@marvin.corpeast.baynetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web10006.mail.yahoo.com X-SMTP-MAIL-FROM: stmoebius@yahoo.com X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: web10006.mail.yahoo.com [216.136.130.42] X-Orig: X-Orig: Hi, Does anyone know what happens to IP in IP traffic (any tunneling protocol) when it encouters a address-and-port-translation device? A proxy we are using in a testbed just drops any packet that is not TCP/UDP. Is that common behaviour for such devices or do they have special treatment for MobileIP packets? (assuming that such packets only travel between FA and HA, they could be routed statically, changing only the IP address) Thanks in advance, Stefan ********* Stefan Moebius Centre for Wireless Communications, Singapore __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 13:41:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16568 for ; Mon, 12 Mar 2001 13:41:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09480; Mon, 12 Mar 2001 10:41:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19801; Mon, 12 Mar 2001 10:41:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CIdYIm024540 for ; Mon, 12 Mar 2001 10:39:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CIdXnT024539 for mobile-ip-dist; Mon, 12 Mar 2001 10:39:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CIdRIm024532 for ; Mon, 12 Mar 2001 10:39:27 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15410 for ; Mon, 12 Mar 2001 13:39:25 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA27040 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 13:39:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2AG9D119775 for ; Sat, 10 Mar 2001 08:09:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13605 for ; Sat, 10 Mar 2001 08:09:13 -0800 (PST) Received: from mailbreak.com ([216.207.225.170]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26180 for ; Sat, 10 Mar 2001 09:09:12 -0700 (MST) Received: from eshim by mailbreak.com with SMTP (MDaemon.v3.5.2.R) for ; Sat, 10 Mar 2001 11:08:24 -0500 Message-ID: <008401c0a97c$c31a1840$6501a8c0@nyc.solidstreaming.net> From: "Eunsoo Shim" To: Cc: "Eunsoo Shim" References: <85AA7486A2C1D411BCA20000F8073E430176C465@crchy271.us.nortel.com> Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Date: Sat, 10 Mar 2001 11:11:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C0A952.D9E0BA90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Return-Path: eunsoo@ctr.columbia.edu X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C0A952.D9E0BA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txtHi, Probably the problem is related to the difficulty of mobility management = without introducing global per-host routing. Of course no one is proposing global per-host routing. Actually the solutions suggested in Mobile IP and Mobile IP Regional = Registration are based on tunneling. And now one of the issues is how to manage/control the tunnels very = well. If you are concerned about the single point of failure introduced by = Mobile IP Regional Registration, our I-D might be worth reading since we = tried to propose a solution to relieve the problem of single point of = failure while keeping the advantages of regional registration. Our I-D is available at the following URL for now: http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-= reg-00.txt http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-= reg-00.pdf Thanks. Eunsoo ----- Original Message -----=20 From: Glenn Morrow=20 To: mobile-ip@sunroof.eng.sun.com=20 Sent: Friday, March 09, 2001 2:39 PM Subject: [mobile-ip] FW: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt Hello,=20 I still do not understand why the ability to place something at an = arbitrary point justifies destroying the connectionless nature of a IP = or even IP mobility. If arbitrary point is so important, why don't you just tunnel to the = arbitrary point based upon routing policy and leave a natural = aggregatable solution connectionless. People can always tinker with = their routes to make single points of failure if they wish but why build = it in. Have people simply given up on keeping things connectionless? Is there = some sort of graph theory that somehow proves that this is a connection = oriented problem domain? Respectfully, I wish to be illuminated on this - one way or the other. = Thanks,=20 Glenn=20 -----Original Message-----=20 From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, March 09, 2001 6:35 AM=20 To: IETF-Announce=20 Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 Title : Mobile IPv6 Regional Registrations=20 Author(s) : J. Malinen, F. Le, C. Perkins=20 Filename : draft-malinen-mobileip-regreg6-01.txt=20 Pages : 28=20 Date : 08-Mar-01=20 =20 This document describes Mobile IPv6 regional registration as an=20 optional extension to Mobile IPv6. Regional registration introduces=20 visited-domain mobility agent functionality for proxying a public=20 care-of-address which remains the same while the mobile node=20 moves in the visited domain. This reduces the binding update=20 signaling latency for the mobile node and signaling load outside the=20 visited domain. The protocol defines regional mobility capability=20 negotiation, regional binding update signaling, and regional-aware=20 data routing through a hierarchy of visited-domain mobility agents.=20 The protocol allows for an arbitrary point in the visited-domain=20 hierarchy to distribute the connection-state maintenance between=20 several mobility agents. IPSec AH is used for securing the protocol=20 as in basic Mobile IPv6.=20 A URL for this Internet-Draft is:=20 = http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt= =20 Internet-Drafts are also available by anonymous FTP. Login with the = username=20 "anonymous" and a password of your e-mail address. After logging in,=20 type "cd internet-drafts" and then=20 "get draft-malinen-mobileip-regreg6-01.txt".=20 A list of Internet-Drafts directories can be found in=20 http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 Internet-Drafts can also be obtained by e-mail.=20 Send a message to:=20 mailserv@ietf.org.=20 In the body type:=20 "FILE /internet-drafts/draft-malinen-mobileip-regreg6-01.txt". = =20 NOTE: The mail server at ietf.org can return the document in=20 MIME-encoded form by using the "mpack" utility. To use this=20 feature, insert the command "ENCODING mime" before the "FILE"=20 command. To decode the response(s), you will need "munpack" = or=20 a MIME-compliant mail reader. Different MIME-compliant mail = readers=20 exhibit different behavior, especially when dealing with=20 "multipart" MIME messages (i.e. documents which have been = split=20 up into multiple messages), so check your local documentation = on=20 how to manipulate these messages.=20 =20 =20 Below is the data which will enable a MIME compliant mail reader=20 implementation to automatically retrieve the ASCII version of the=20 Internet-Draft.=20 =20 ------=_NextPart_000_0081_01C0A952.D9E0BA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt
Hi,
 
Probably the problem is related to the = difficulty=20 of mobility management without introducing global per-host = routing.
Of course no one is proposing global = per-host=20 routing.
Actually the solutions suggested in = Mobile IP and=20 Mobile IP Regional Registration are based on tunneling.
And now one of the issues is how to = manage/control=20 the tunnels very well.
If you are concerned about the single = point of=20 failure introduced by Mobile IP Regional Registration, our I-D might be = worth=20 reading since we tried to propose a solution to relieve the problem of = single=20 point of failure while keeping the advantages of regional=20 registration.
Our I-D is available at the following URL for now:
http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-= reliable-reg-00.txt
http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-= reliable-reg-00.pdf

Thanks.

Eunsoo
----- Original Message -----
From:=20 Glenn Morrow
To: mobile-ip@sunroof.eng.sun.com =
Sent: Friday, March 09, 2001 = 2:39=20 PM
Subject: [mobile-ip] FW: I-D=20 ACTION:draft-malinen-mobileip-regreg6-01.txt

Hello,

I still do not understand why the ability to place = something=20 at an arbitrary point justifies destroying the connectionless nature = of a IP=20 or even IP mobility.

If arbitrary point is so important, why don't you = just tunnel=20 to the arbitrary point based upon routing policy and leave a natural=20 aggregatable solution connectionless. People can always tinker with = their=20 routes to make single points of failure if they wish but why build it=20 in.

Have people simply given up on keeping things = connectionless?=20 Is there some sort of graph theory that somehow proves that this is a=20 connection oriented problem domain?

Respectfully, I wish to be illuminated on this - one = way or=20 the other.

Thanks,

Glenn

-----Original Message-----
From:=20 Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /A>]=20
Sent: Friday, March 09, 2001 6:35 AM =
To: IETF-Announce
Subject: I-D=20 ACTION:draft-malinen-mobileip-regreg6-01.txt


A New Internet-Draft is available from the on-line=20 Internet-Drafts directories.


        Title  =20         : Mobile IPv6 Regional=20 Registrations
        = Author(s)       : J. Malinen, = F. Le, C.=20 Perkins
        Filename        :=20 draft-malinen-mobileip-regreg6-01.txt=20
        Pages  =20         : 28=20
        Date    =         :=20 08-Mar-01
        =
This document describes Mobile IPv6 regional registration as = an=20
optional extension to Mobile IPv6.  Regional=20 registration introduces
visited-domain = mobility agent=20 functionality for proxying a public
care-of-address=20 which remains the same while the mobile node
moves in=20 the visited domain.  This reduces the binding update =
signaling latency for the mobile node and signaling load = outside=20 the
visited domain.  The protocol = defines=20 regional mobility capability
negotiation, = regional=20 binding update signaling, and regional-aware
data=20 routing through a hierarchy of visited-domain mobility agents.=20
The protocol allows for an arbitrary point in the=20 visited-domain
hierarchy to distribute the=20 connection-state maintenance between
several = mobility=20 agents.  IPSec AH is used for securing the protocol =
as in basic Mobile IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malinen-mobilei= p-regreg6-01.txt=20

Internet-Drafts are also available by anonymous FTP. = Login=20 with the username
"anonymous" and a password = of your=20 e-mail address. After logging in,
type "cd=20 internet-drafts" and then=20
        "get=20 draft-malinen-mobileip-regreg6-01.txt".

A list of Internet-Drafts directories can be found = in=20
http://www.ietf.org/shadow.html
or=20 ftp://ftp.ietf.org/ietf/1shadow-sites.txt =


Internet-Drafts can also be obtained by = e-mail.

Send a message to:=20
        mailserv@ietf.org.
In the body = type:=20
        "FILE=20 /internet-drafts/draft-malinen-mobileip-regreg6-01.txt".=20
       
NOTE:   The mail server at ietf.org can return the = document=20 in
        MIME-encoded form by using the "mpack" utility.  To use=20 this
        feature, insert the command "ENCODING mime" before the = "FILE"=20
        command.  To=20 decode the response(s), you will need "munpack" or=20
        a = MIME-compliant=20 mail reader.  Different MIME-compliant mail readers=20
        exhibit = different=20 behavior, especially when dealing with=20
        "multipart" MIME=20 messages (i.e. documents which have been split=20
        up into = multiple=20 messages), so check your local documentation on=20
        how to = manipulate=20 these messages.
       =20        =20
       =20        
Below is = the data=20 which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.

 =20

------=_NextPart_000_0081_01C0A952.D9E0BA90-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 13:54:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16821 for ; Mon, 12 Mar 2001 13:54:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13480; Mon, 12 Mar 2001 10:54:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02333; Mon, 12 Mar 2001 10:54:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CIrHIm024663 for ; Mon, 12 Mar 2001 10:53:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CIrGrr024662 for mobile-ip-dist; Mon, 12 Mar 2001 10:53:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CIr7Im024655 for ; Mon, 12 Mar 2001 10:53:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17804 for ; Mon, 12 Mar 2001 13:53:06 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA27319 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 13:53:12 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2BAGw122219 for ; Sun, 11 Mar 2001 02:16:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08341 for ; Sun, 11 Mar 2001 02:16:57 -0800 (PST) Received: from infomail.es (ncc1.infomail.es [195.235.39.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16696 for ; Sun, 11 Mar 2001 02:16:56 -0800 (PST) Received: from upcnet.es ([62.82.146.75]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #984305836.009140001; Sun, 11 Mar 2001 11:17:16 +0100 Message-ID: <3AAB5240.2BC46894@upcnet.es> Date: Sun, 11 Mar 2001 11:24:00 +0100 From: Oscar de Luis X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: es,en,ca MIME-Version: 1.0 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, mobile-ip@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: [mobile-ip] unsubscribe mobile-ip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Infomail-Id: 984305836.0392010A811066.5836 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit unsubscribe mobile-ip From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 14:02:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16980 for ; Mon, 12 Mar 2001 14:02:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21310; Mon, 12 Mar 2001 11:02:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21358; Mon, 12 Mar 2001 11:02:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJ17Im024722 for ; Mon, 12 Mar 2001 11:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CJ16PX024721 for mobile-ip-dist; Mon, 12 Mar 2001 11:01:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJ11Im024714 for ; Mon, 12 Mar 2001 11:01:02 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12329 for ; Mon, 12 Mar 2001 14:01:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA27475 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 14:01:06 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2BFHx122343 for ; Sun, 11 Mar 2001 07:17:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06510 for ; Sun, 11 Mar 2001 07:18:00 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15365 for ; Sun, 11 Mar 2001 08:17:58 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2BFHvC20412 for ; Sun, 11 Mar 2001 16:17:57 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Mar 11 16:17:57 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Sun, 11 Mar 2001 16:19:36 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC1F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Sun, 11 Mar 2001 16:17:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Glenn, You're absolutely right. That's exactly what we have been avoiding in the HMIPv6 work. There is no need for a non-robust solution that intrduces a tree of single points of failures. As you said network administrators can force routes to introduce this effect if they want their networks to be less robust for other reasons. So far I haven't heard *any* reason for it. Cheers, Hesham > -----Original Message----- > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > Sent: Saturday, 10 March 2001 6:40 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt > > Hello, > > I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. > > If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in. > > Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain? > > Respectfully, I wish to be illuminated on this - one way or the other. > > Thanks, > > Glenn > > -----Original Message----- > From: Internet-Drafts@ietf.org [ ] > Sent: Friday, March 09, 2001 6:35 AM > To: IETF-Announce > Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mobile IPv6 Regional Registrations > Author(s) : J. Malinen, F. Le, C. Perkins > Filename : draft-malinen-mobileip-regreg6-01.txt > Pages : 28 > Date : 08-Mar-01 > > This document describes Mobile IPv6 regional registration as an > optional extension to Mobile IPv6. Regional registration introduces > visited-domain mobility agent functionality for proxying a public > care-of-address which remains the same while the mobile node > moves in the visited domain. This reduces the binding update > signaling latency for the mobile node and signaling load outside the > visited domain. The protocol defines regional mobility capability > negotiation, regional binding update signaling, and regional-aware > data routing through a hierarchy of visited-domain mobility agents. > The protocol allows for an arbitrary point in the visited-domain > hierarchy to distribute the connection-state maintenance between > several mobility agents. IPSec AH is used for securing the protocol > as in basic Mobile IPv6. > > A URL for this Internet-Draft is: > > > 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-malinen-mobileip-regreg6-01.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-malinen-mobileip-regreg6-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. > > << Message: Untitled Attachment >> From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 14:05:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17094 for ; Mon, 12 Mar 2001 14:05:09 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24167; Mon, 12 Mar 2001 11:05:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25783; Mon, 12 Mar 2001 11:04:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJ2kIm024738 for ; Mon, 12 Mar 2001 11:02:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CJ2jNe024737 for mobile-ip-dist; Mon, 12 Mar 2001 11:02:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJ2ZIm024730 for ; Mon, 12 Mar 2001 11:02:40 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12611 for ; Mon, 12 Mar 2001 14:02:34 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA27517 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 14:02:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2BHOk122422 for ; Sun, 11 Mar 2001 09:24:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16452 for ; Sun, 11 Mar 2001 09:24:46 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04455 for ; Sun, 11 Mar 2001 09:24:45 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA18710 for ; Sun, 11 Mar 2001 10:24:40 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA04002 for ; Sun, 11 Mar 2001 10:24:40 -0700 (MST)] Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id G3C79XRW; Sun, 11 Mar 2001 11:24:39 -0600 From: "Ajoy Singh" To: Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 Date: Mon, 12 Mar 2001 11:26:51 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Gwon: I read through your proposed handoff scheme. Although It sounds interesting to me but I have following question: I am not clear how the network layer and link layer handoff scheme will coexist. If you allow control at both network and link layer then how do you guarantee that both will make the same decision. If you think that network layer is controlling the wireless handover then that some trigger mechanism is required from network layer to link layer. Please correct me if I missing something. regards, ajoy > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 14:17:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17452 for ; Mon, 12 Mar 2001 14:17:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05328; Mon, 12 Mar 2001 11:17:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03025; Mon, 12 Mar 2001 11:17:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJFuIm024885 for ; Mon, 12 Mar 2001 11:15:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CJFu10024884 for mobile-ip-dist; Mon, 12 Mar 2001 11:15:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJFoIm024877 for ; Mon, 12 Mar 2001 11:15:51 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15468 for ; Mon, 12 Mar 2001 14:15:49 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA27775 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 14:15:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CIoJIm024641 for ; Mon, 12 Mar 2001 10:50:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21948 for ; Mon, 12 Mar 2001 10:50:18 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08739 for ; Mon, 12 Mar 2001 10:50:16 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2CIoEC21860 for ; Mon, 12 Mar 2001 19:50:14 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 12 19:49:01 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Mon, 12 Mar 2001 19:50:13 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC2F@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Mon, 12 Mar 2001 19:50:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, > > Probably the problem is related to the difficulty of mobility management without introducing global per-host routing. > Of course no one is proposing global per-host routing. > => That's not a reason to intrduce a tree-like topology. There are other ways of doing it. > If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration. > => I think you've missed Glenn's point a little. He was referring to single pointS of failure, not a single point (one point) of failure like the MAP, GFA ....etc. there is no need for introducing a circuit-type approach to replace IP routing. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 14:49:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18522 for ; Mon, 12 Mar 2001 14:49:26 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03582; Mon, 12 Mar 2001 11:49:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06824; Mon, 12 Mar 2001 11:49:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJlNIm025016 for ; Mon, 12 Mar 2001 11:47:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CJlMOK025015 for mobile-ip-dist; Mon, 12 Mar 2001 11:47:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJlHIm025008 for ; Mon, 12 Mar 2001 11:47:18 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21549 for ; Mon, 12 Mar 2001 14:47:16 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA28390 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 14:47:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJSYIm024973 for ; Mon, 12 Mar 2001 11:28:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01752 for ; Mon, 12 Mar 2001 11:28:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23377 for ; Mon, 12 Mar 2001 11:28:32 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA04021; Mon, 12 Mar 2001 11:28:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2CJSRZ07105; Mon, 12 Mar 2001 11:28:27 -0800 X-mProtect: Mon, 12 Mar 2001 11:28:27 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdTY03b7; Mon, 12 Mar 2001 11:26:49 PST Message-ID: <3AAD233E.C8703AB7@iprg.nokia.com> Date: Mon, 12 Mar 2001 11:27:58 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gmorrow@nortelnetworks.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <85AA7486A2C1D411BCA20000F8073E430176C465@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Glenn, > I still do not understand why the ability to place something at an > arbitrary point justifies destroying the connectionless nature of a IP > or even IP mobility. I'm not sure what the connection is between these two clauses. Any sort of localized registration is supposed to hide changes of the care-of address. The mobile node can consent to such hiding. Maybe there is something else about our protocol that looks like an intent to destroy the connectionless nature of IP. Could you please be a little more specific about your concerns here? If I may guess that the mobile node has to keep track of more network state (what one might call "connection state") then I guess you would prefer to minimize that. On this we can agree. Then the discussion should center on ways that state is gratuitously set up as a protocol requirement, and make the tradeoffs. > If arbitrary point is so important, why don't you just tunnel to the > arbitrary point based upon routing policy and leave a natural > aggregatable solution connectionless. People can always tinker with > their routes to make single points of failure if they wish but why > build it in. We basically attempted to do exactly what you suggest, by allowing an anycast address to be used by the mobile node for the purposes of making regional registrations. However, there may be other solutions that have even less connection state required. I agree that getting rid of single points of failure is a good idea. > Have people simply given up on keeping things connectionless? Is there > some sort of graph theory that somehow proves that this is a > connection oriented problem domain? I have not at all given up on it. Some things seem to be "connection- oriented" -- say, for instance, header compression state or QoS. Connectionless has universal appeal because of its simplicity and typically good-enough performance. I think that regionalized registrations lies more on the connectionless side, and that we should aim to make it as connectionless as possible, while still making it possible. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 15:03:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19106 for ; Mon, 12 Mar 2001 15:03:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15599; Mon, 12 Mar 2001 12:03:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10214; Mon, 12 Mar 2001 12:03:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CK1nIm025104 for ; Mon, 12 Mar 2001 12:01:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CK1mL0025103 for mobile-ip-dist; Mon, 12 Mar 2001 12:01:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CK1hIm025096 for ; Mon, 12 Mar 2001 12:01:43 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29882 for ; Mon, 12 Mar 2001 15:01:42 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA28727 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 15:01:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CJa2Im024992 for ; Mon, 12 Mar 2001 11:36:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00540 for ; Mon, 12 Mar 2001 11:35:56 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17816 for ; Mon, 12 Mar 2001 11:35:55 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA04879; Mon, 12 Mar 2001 11:35:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2CJZqV24692; Mon, 12 Mar 2001 11:35:52 -0800 X-mProtect: Mon, 12 Mar 2001 11:35:52 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdUXh2Fb; Mon, 12 Mar 2001 11:34:58 PST Message-ID: <3AAD2524.3903D7DB@iprg.nokia.com> Date: Mon, 12 Mar 2001 11:36:05 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <034BEFD03799D411A59F00508BDF7546013DBC1F@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, > You're absolutely right. That's exactly what we have been avoiding > in the HMIPv6 work. There is no need for a non-robust solution > that intrduces a tree of single points of failures. As you said > network administrators can force routes to introduce this effect > if they want their networks to be less robust for other reasons. I think that the MAP would qualify as a single point of failure. I also think that we need to avoid restricting the solution to work only with a single point of failure. It would be nice to have a more general solution that doesn't make the mobile node learn all the relevant topology. I think what Glenn was suggesting is basically to rely on some scheme that moves all the regional knowledge into the realm of host routing that is controlled by a routing protocol invisible to the mobile node. This might be possible, but there are a lot of problems with it that need attention. In the abstract, I find the idea very appealing. Some of the problems have to do with stale routing information. We'd like to avoid putting routes where they aren't needed -- this is the "proactive" vs. "reactive" debate in new clothes. Our experience with regional registration has shown some ways to do this. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 16:08:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20257 for ; Mon, 12 Mar 2001 16:08:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22385; Mon, 12 Mar 2001 13:08:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28625; Mon, 12 Mar 2001 13:08:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CL6ZIm025286 for ; Mon, 12 Mar 2001 13:06:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CL6Zv9025285 for mobile-ip-dist; Mon, 12 Mar 2001 13:06:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CL6UIm025278 for ; Mon, 12 Mar 2001 13:06:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07220 for ; Mon, 12 Mar 2001 16:06:28 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA29984 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 16:06:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CK1KIm025085 for ; Mon, 12 Mar 2001 12:01:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19131 for ; Mon, 12 Mar 2001 12:01:19 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03943 for ; Mon, 12 Mar 2001 12:01:17 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 12 Mar 2001 14:00:34 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 14:00:32 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E4EB5@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Mon, 12 Mar 2001 14:00:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB2F.18046E10" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AB2F.18046E10 Content-Type: text/plain; charset="iso-8859-1" Eunsoo, Thanks for the reply. I am trying to get people to open up their minds with IPv6. It is still fairly malleable for change and has many tools which can be used to achieve this functionality. The RR draft seems to be let's fork-lift the IPv4 solution and slap in some anycast magic. I think a better solution is out there for this functionality using IPv6's features that leverages any natural aggregation that may exist in any given IP network. In my opinion arbitary point is not a requirement and even if it were there are better solutions which do not require any changes to the protocols, especially if you use tunneling. RR is nothing more than an IP proxy using MIP signaling to provision it. -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@ctr.columbia.edu] Sent: Saturday, March 10, 2001 10:11 AM To: mobile-ip Cc: Eunsoo Shim Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Hi, Probably the problem is related to the difficulty of mobility management without introducing global per-host routing. Of course no one is proposing global per-host routing. [Morrow, Glenn ] RR is doing per-host routing at the edge on select routers, some of which are at possibly remoted arbitrary points. My point was that you could easily tunnel over stupid legacy routers with simple routing policies in order to achieve this arbitrary point without having to change MIP at all. Actually the solutions suggested in Mobile IP and Mobile IP Regional Registration are based on tunneling. [Morrow, Glenn ] Yes and that's why I really don't see a need to alter MIP to handle it as routing policy and tunneling can handle the arbitrary point issue, already. And now one of the issues is how to manage/control the tunnels very well. [Morrow, Glenn ] I believe routing policy combined with tunnels is an already existing method to archive the arbitrary point given the scope of the solution set. We also do not have to change the protocol. If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration. Our I-D is available at the following URL for now: http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg -00.txt http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg -00.pdf [Morrow, Glenn ] This is a regurgitation of a router redundancy scheme applied to the RR functionality - earthshattering, indeed. Thanks. Eunsoo ----- Original Message ----- From: Glenn Morrow To: mobile-ip@sunroof.eng.sun.com Sent: Friday, March 09, 2001 2:39 PM Subject: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Hello, I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in. Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain? Respectfully, I wish to be illuminated on this - one way or the other. Thanks, Glenn -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org ] Sent: Friday, March 09, 2001 6:35 AM To: IETF-Announce Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Regional Registrations Author(s) : J. Malinen, F. Le, C. Perkins Filename : draft-malinen-mobileip-regreg6-01.txt Pages : 28 Date : 08-Mar-01 This document describes Mobile IPv6 regional registration as an optional extension to Mobile IPv6. Regional registration introduces visited-domain mobility agent functionality for proxying a public care-of-address which remains the same while the mobile node moves in the visited domain. This reduces the binding update signaling latency for the mobile node and signaling load outside the visited domain. The protocol defines regional mobility capability negotiation, regional binding update signaling, and regional-aware data routing through a hierarchy of visited-domain mobility agents. The protocol allows for an arbitrary point in the visited-domain hierarchy to distribute the connection-state maintenance between several mobility agents. IPSec AH is used for securing the protocol as in basic Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt 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-malinen-mobileip-regreg6-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-malinen-mobileip-regreg6-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_001_01C0AB2F.18046E10 Content-Type: text/html; charset="iso-8859-1" FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
Eunsoo,
 
Thanks for the reply. I am trying to get people to open up their minds with IPv6. It is still fairly malleable for change and has many tools which can be used to achieve this functionality. The RR draft seems to be let's fork-lift the IPv4 solution and slap in some anycast magic. I think a better solution is out there for this functionality using IPv6's features that leverages any natural aggregation that may exist in any given IP network.
 
In my opinion arbitary point is not a requirement and even if it were there are better solutions  which do not require any changes to the protocols, especially if you use tunneling.
 
RR is nothing more than an IP proxy using MIP signaling to provision it.
 
 
 -----Original Message-----
From: Eunsoo Shim [mailto:eunsoo@ctr.columbia.edu]
Sent: Saturday, March 10, 2001 10:11 AM
To: mobile-ip
Cc: Eunsoo Shim
Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt

Hi,
 
Probably the problem is related to the difficulty of mobility management without introducing global per-host routing.
Of course no one is proposing global per-host routing. 
[Morrow, Glenn ] RR is doing per-host routing at the edge on select routers, some of which are at possibly remoted arbitrary points. My point was that you could easily tunnel over stupid legacy routers with simple routing policies in order to achieve this arbitrary point without having to change MIP at all.
 
Actually the solutions suggested in Mobile IP and Mobile IP Regional Registration are based on tunneling.
[Morrow, Glenn ] Yes and that's why I really don't see a need to alter MIP to handle it as routing policy and tunneling can handle the arbitrary point issue, already. 
And now one of the issues is how to manage/control the tunnels very well.
[Morrow, Glenn ] I believe routing policy combined with tunnels is an already existing method to archive the arbitrary point given the scope of the solution set. We also do not have to change the protocol.
If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration.
This is a regurgitation of a router redundancy scheme applied to the RR functionality - earthshattering, indeed.
 
 
Thanks.

Eunsoo
----- Original Message -----
Sent: Friday, March 09, 2001 2:39 PM
Subject: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt

Hello,

I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility.

If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in.

Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain?

Respectfully, I wish to be illuminated on this - one way or the other.

Thanks,

Glenn

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Friday, March 09, 2001 6:35 AM
To: IETF-Announce
Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Mobile IPv6 Regional Registrations
        Author(s)       : J. Malinen, F. Le, C. Perkins
        Filename        : draft-malinen-mobileip-regreg6-01.txt
        Pages           : 28
        Date            : 08-Mar-01
       
This document describes Mobile IPv6 regional registration as an
optional extension to Mobile IPv6.  Regional registration introduces
visited-domain mobility agent functionality for proxying a public
care-of-address which remains the same while the mobile node
moves in the visited domain.  This reduces the binding update
signaling latency for the mobile node and signaling load outside the
visited domain.  The protocol defines regional mobility capability
negotiation, regional binding update signaling, and regional-aware
data routing through a hierarchy of visited-domain mobility agents.
The protocol allows for an arbitrary point in the visited-domain
hierarchy to distribute the connection-state maintenance between
several mobility agents.  IPSec AH is used for securing the protocol
as in basic Mobile IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt

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-malinen-mobileip-regreg6-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-malinen-mobileip-regreg6-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_001_01C0AB2F.18046E10-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 17:51:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23427 for ; Mon, 12 Mar 2001 17:51:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29294; Mon, 12 Mar 2001 14:51:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17137; Mon, 12 Mar 2001 14:51:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CMnhIm025576 for ; Mon, 12 Mar 2001 14:49:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CMngVJ025575 for mobile-ip-dist; Mon, 12 Mar 2001 14:49:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CMnbIm025568 for ; Mon, 12 Mar 2001 14:49:38 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24939 for ; Mon, 12 Mar 2001 17:49:37 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA02040 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 17:49:42 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CKJOIm025184 for ; Mon, 12 Mar 2001 12:19:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11602 for ; Mon, 12 Mar 2001 12:19:23 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15138 for ; Mon, 12 Mar 2001 12:19:21 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 12 Mar 2001 14:13:19 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 14:18:22 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E4EF0@crchy271.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Mon, 12 Mar 2001 14:18:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB31.95C70810" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AB31.95C70810 Content-Type: text/plain; charset="iso-8859-1" I wish to strike this caustic sentence from the last mail. It is not productive. "RR is nothing more than an IP proxy using MIP signaling to provision it." ------_=_NextPart_001_01C0AB31.95C70810 Content-Type: text/html; charset="iso-8859-1" FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
I wish to strike this caustic sentence from the last mail. It is not productive.
 
 
"RR is nothing more than an IP proxy using MIP signaling to provision it."
 
 
------_=_NextPart_001_01C0AB31.95C70810-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 12 17:57:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23511 for ; Mon, 12 Mar 2001 17:57:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04131; Mon, 12 Mar 2001 14:57:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18560; Mon, 12 Mar 2001 14:57:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CMuCIm025640 for ; Mon, 12 Mar 2001 14:56:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2CMuCUi025639 for mobile-ip-dist; Mon, 12 Mar 2001 14:56:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CMu7Im025632 for ; Mon, 12 Mar 2001 14:56:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00237 for ; Mon, 12 Mar 2001 17:56:07 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA02168 for mobile-ip@sunroof.eng.sun.com; Mon, 12 Mar 2001 17:56:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2CKbFIm025199 for ; Mon, 12 Mar 2001 12:37:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27443 for ; Mon, 12 Mar 2001 12:37:03 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25993 for ; Mon, 12 Mar 2001 12:37:02 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2CKb0C18518 for ; Mon, 12 Mar 2001 21:37:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Mar 12 21:37:01 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 12 Mar 2001 21:33:02 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC37@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Mon, 12 Mar 2001 21:36:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > You're absolutely right. That's exactly what we have been avoiding > > in the HMIPv6 work. There is no need for a non-robust solution > > that intrduces a tree of single points of failures. As you said > > network administrators can force routes to introduce this effect > > if they want their networks to be less robust for other reasons. > > I think that the MAP would qualify as a single point of failure. > => That's true. Just like a HA does. However, forcing a static (hidden) hierarchy between the MAP and the MN is much less robust, and introduces more single points of failure for no foreseen gain. > I also think that we need to avoid restricting the solution to work only > with a single point of failure. > => I agree that some redundancy work is needed for MAPs and HAs. I was intending on starting that after San Diego but this meeting just came too quickly :) > It would be nice to have a more general > solution that doesn't make the mobile node learn all the relevant > topology. > => Is there a solution today that requires the MN's knowledge of the topology ? I think all the current drafts within the group avoid that. Unless I missed something ? Certainly HMIPv6 and the fast handover work in both design teams do avoid such knowledge. > I think what Glenn was suggesting is basically to rely on some scheme > that moves all the regional knowledge into the realm of host routing > that is controlled by a routing protocol invisible to the mobile node. > => I can't speak on behalf of Glenn, but my understanding of his mail was that he didn't like the connection (circuit) oriented approach in the draft in question (the subject of this mail). To be specific there is essentially a circuit between the GMA and the AR that the MN is connected to. The path of traffic is forced and a failure of any of these mobility agents along the path would kill the entire path. That is what I referred to in my mail. Regards, Hesham From ronyoung@nortelnetworks.com Mon Mar 12 19:52:56 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26396 for ; Mon, 12 Mar 2001 19:52:55 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Mon, 12 Mar 2001 18:29:35 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Mon, 12 Mar 2001 18:31:04 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id TAA16922 for ; Mon, 12 Mar 2001 19:17:50 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Mon, 12 Mar 2001 19:21:50 -0500 Received: from intrasvr.kisantel.co.kr ( [211.234.46.15]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Mon, 12 Mar 2001 19:17:33 -0500 Received: by INTRASVR with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Mar 2001 09:15:02 +0900 Message-ID: From: =?EUC-KR?B?s7LB+L/s?= To: MOBILE-IP@marvin.corpeast.baynetworks.com, mobile-ip@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: [mobile-ip] unsubscribe mobile-ip Date: Tue, 13 Mar 2001 09:15:02 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB52.A5B80A46" X-SMTP-HELO: intrasvr.kisantel.co.kr X-SMTP-MAIL-FROM: jwnam@kisantel.co.kr X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: [211.234.46.15] X-Orig: X-Orig: X-Orig: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AB52.A5B80A46 Content-Type: text/plain; charset="ks_c_5601-1987" unsubscribe mobile-ip ------_=_NextPart_001_01C0AB52.A5B80A46 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [mobile-ip] unsubscribe mobile-ip

unsubscribe mobile-ip

------_=_NextPart_001_01C0AB52.A5B80A46-- From ronyoung@nortelnetworks.com Mon Mar 12 20:46:41 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27084 for ; Mon, 12 Mar 2001 20:46:41 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Mon, 12 Mar 2001 19:23:27 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Mon, 12 Mar 2001 19:23:36 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id UAA17877 for ; Mon, 12 Mar 2001 20:16:16 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Mon, 12 Mar 2001 20:20:12 -0500 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Mon, 12 Mar 2001 20:15:58 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08116; Mon, 12 Mar 2001 17:15:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2D1FuT30619; Mon, 12 Mar 2001 17:15:56 -0800 X-mProtect: Mon, 12 Mar 2001 17:15:56 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd79tlz1; Mon, 12 Mar 2001 17:15:48 PST Sender: charliep@iprg.nokia.com Message-ID: <3AAD74C5.24EB80DF@iprg.nokia.com> Date: Mon, 12 Mar 2001 17:15:49 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Glenn Morrow" CC: MOBILE-IP@marvin.corpeast.baynetworks.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: mailhost.iprg.nokia.com X-SMTP-MAIL-FROM: charliep@iprg.nokia.com X-SMTP-RCPT-TO: gmorrow@nortelnetworks.com,MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: mailhost.iprg.nokia.com [205.226.5.12] X-Orig: X-Orig: X-Orig: Hello Glenn, > Thanks for the reply. I am trying to get people to open up their minds with > IPv6. It is still fairly malleable for change and has many tools which can > be used to achieve this functionality. Do you mean to suggest changing IPv6? If you mean changing something else (using its favorable malleability), can you say what? > The RR draft seems to be let's > fork-lift the IPv4 solution and slap in some anycast magic. I think a better > solution is out there for this functionality using IPv6's features that > leverages any natural aggregation that may exist in any given IP network. A slap is not respectful treatment for anybody, not even an anycast address. I think that the anycast address has exactly the right semantics. We also are trying to get people to open their minds with IPv6. Anycast is exactly right, because what the mobile node "wants" is for the crossover router to take the appropriate action, without the mobile node knowing which router it is. Anycast even helps to preserve the connectionless nature which we would like to preserve for regionalized mobility handling. > In my opinion arbitary point is not a requirement and even if it were there > are better solutions which do not require any changes to the protocols, > especially if you use tunneling. I thought that a lot of people wanted to use an arbitrary point of contact (between access network and Internet) as an "anchor point". Or maybe you are referring to something else...? > RR is nothing more than an IP proxy using MIP signaling to provision it. In a subsequent note, you retracted this characterization, but I'd still like to know how you wished to draw the analogy between something in regionalized registration, and an IP proxy (what is an IP proxy?). Regards, Charlie P. From ronyoung@nortelnetworks.com Tue Mar 13 07:38:22 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18851 for ; Tue, 13 Mar 2001 07:38:22 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Tue, 13 Mar 2001 06:20:59 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Tue, 13 Mar 2001 06:22:36 -0600 Received: from smtpott1.nortel.ca (zcars00v.ca.nortel.com [47.56.48.102]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id HAA20643 for ; Tue, 13 Mar 2001 07:14:58 -0500 (EST) Received: from ecarsddd.nortelnetworks.com by smtpott1.nortel.ca; Tue, 13 Mar 2001 07:18:50 -0500 Received: from quicksilver.ukc.ac.uk (quicksilver.ukc.ac.uk [129.12.21.11]) by ecarsddd.nortelnetworks.com with SMTP (MailShield v1.5); Tue, 13 Mar 2001 07:14:38 -0500 Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.16 #1) id 14cnh7-0003mP-00; Tue, 13 Mar 2001 12:14:29 +0000 Received: from pcha.ukc.ac.uk ([129.12.50.201] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 1.92 #1) id 14cnh8-0004mG-00; Tue, 13 Mar 2001 12:14:30 +0000 Message-ID: <3AAE0F25.2497CE56@ukc.ac.uk> Date: Tue, 13 Mar 2001 12:14:29 +0000 From: "H.Al-Raweshidy" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Samir R. Das" CC: MOBILE-IP@marvin.corpeast.baynetworks.com Subject: Re: [MOBILE-IP] Call for Papers: MobiCom 2000 References: <200001101849.MAA00545@wayward.cs.utsa.edu> Content-Type: multipart/mixed; boundary="------------41EA0CB14D87449356580279" X-SMTP-HELO: quicksilver.ukc.ac.uk X-SMTP-MAIL-FROM: H.Al-Raweshidy@ukc.ac.uk X-SMTP-RCPT-TO: MOBILE-IP@standards.nortelnetworks.com X-SMTP-PEER-INFO: quicksilver.ukc.ac.uk [129.12.21.11] X-Orig: X-Orig: X-Orig: This is a multi-part message in MIME format. --------------41EA0CB14D87449356580279 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear All I would like to invite you to submit papers for the WPMC01 in Aalborg/ Denmark on 9-12 September 2001. The session title is " Future Mobile IP". For organisational reasons we would like also the invited speakers to submit an abstract, which it is now possible to do online via www.wpmc01.org. The deadline is April 30. The submission of the final manuscript will be later. Thank you in advance. Hamed --------------41EA0CB14D87449356580279 Content-Type: text/x-vcard; charset=us-ascii; name="H.Al-Raweshidy.vcf" Content-Description: Card for H.Al-Raweshidy Content-Disposition: attachment; filename="H.Al-Raweshidy.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:;Dr H tel;work:0044-1227-823396 x-mozilla-html:FALSE org:Communication Systems Division;Electronic Engineering Laboratory adr:;;University of Kent ;Canterbury;Kent;CT2 7NT;UK version:2.1 email;internet:h.al-raweshidy@ukc.ac.uk title:Dr H. Al-Raweshidy end:vcard --------------41EA0CB14D87449356580279-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 13:50:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26070 for ; Tue, 13 Mar 2001 13:50:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22820; Tue, 13 Mar 2001 10:50:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02852; Tue, 13 Mar 2001 10:49:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DImTIm027542 for ; Tue, 13 Mar 2001 10:48:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DImSGb027541 for mobile-ip-dist; Tue, 13 Mar 2001 10:48:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DImNIm027534 for ; Tue, 13 Mar 2001 10:48:24 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00281 for ; Tue, 13 Mar 2001 13:48:01 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA25226 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 13:48:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2D0ZgIm025948 for ; Mon, 12 Mar 2001 16:35:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21181 for ; Mon, 12 Mar 2001 16:35:42 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14290 for ; Mon, 12 Mar 2001 16:35:30 -0800 (PST) Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f2D0ecq23632 for ; Mon, 12 Mar 2001 16:40:38 -0800 (PST) Date: Mon, 12 Mar 2001 16:40:38 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] New I-D in L3 trigger based MIPv4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Ajoy, First of all, we'd like to mention that our main target is toward the all-IP network mobility issues, perhaps targeting the beyond 3G network. Also, as mentioned in the draft, inter-access technology handovers that are difficult to achieve under L2 diversity. L3 control is essential when L2 trigger is not available for this case. Our method can also be combined with L2-trigger based approach, but the principle philosophy stays the same: treating L3 essential and L2 as side info. In case of L2 and L3 discrepancy (e.g. where L3 prediction error occurs), we may have to develop a sort of fault preventing mechanism that could be implemented based upon the side information. Honestly, this is one of the difficult problems we are facing currently, thus, part of the future work. On Mon, 12 Mar 2001, Ajoy Singh wrote: > Hello Gwon: > I read through your proposed handoff scheme. Although It sounds interesting > to me > but I have following question: > > I am not clear how the network layer and link layer handoff scheme will > coexist. If you allow control at both network and link layer then > how do you guarantee that both will make the same decision. If you think > that > network layer is controlling the wireless handover then that some trigger > mechanism > is required from network layer to link layer. > > Please correct me if I missing something. > > regards, > ajoy > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 14:08:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26337 for ; Tue, 13 Mar 2001 14:08:31 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02066; Tue, 13 Mar 2001 11:08:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07973; Tue, 13 Mar 2001 11:08:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJ6mIm027633 for ; Tue, 13 Mar 2001 11:06:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DJ6mM8027632 for mobile-ip-dist; Tue, 13 Mar 2001 11:06:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJ6hIm027625 for ; Tue, 13 Mar 2001 11:06:43 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23404 for ; Tue, 13 Mar 2001 14:06:43 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA25603 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 14:06:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2D6i5Im026624 for ; Mon, 12 Mar 2001 22:44:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17584 for ; Mon, 12 Mar 2001 22:44:03 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27372 for ; Mon, 12 Mar 2001 23:44:02 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA24375; Mon, 12 Mar 2001 22:44:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2D6hwL17396; Mon, 12 Mar 2001 22:43:58 -0800 X-mProtect: Mon, 12 Mar 2001 22:43:58 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdXivBWU; Mon, 12 Mar 2001 22:43:51 PST Message-ID: <3AADC1B6.1772296C@iprg.nokia.com> Date: Mon, 12 Mar 2001 22:44:06 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow CC: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Comments on Regional Registration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, Sorry if this is a duplicate. I do not know if the original made it out of our site. > Thanks for the reply. I am trying to get people to open up their minds with > IPv6. It is still fairly malleable for change and has many tools which can > be used to achieve this functionality. Do you mean to suggest changing IPv6? If you mean changing something else (using its favorable malleability), can you say what? > The RR draft seems to be let's > fork-lift the IPv4 solution and slap in some anycast magic. I think a better > solution is out there for this functionality using IPv6's features that > leverages any natural aggregation that may exist in any given IP network. A slap is not respectful treatment for anybody, not even an anycast address. I think that the anycast address has exactly the right semantics. We also are trying to get people to open their minds with IPv6. Anycast is exactly right, because what the mobile node "wants" is for the crossover router to take the appropriate action, without the mobile node knowing which router it is. Anycast even helps to preserve the connectionless nature which we would like to preserve for regionalized mobility handling. > In my opinion arbitary point is not a requirement and even if it were there > are better solutions which do not require any changes to the protocols, > especially if you use tunneling. I thought that a lot of people wanted to use an arbitrary point of contact (between access network and Internet) as an "anchor point". Or maybe you are referring to something else. > RR is nothing more than an IP proxy using MIP signaling to provision it. In a subsequent note, you retracted this characterization, but I'd still like to know how you wished to draw the analogy between something in regionalized registration, and an IP proxy (what is an IP proxy?). Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 14:18:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26458 for ; Tue, 13 Mar 2001 14:18:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23838; Tue, 13 Mar 2001 11:18:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16444; Tue, 13 Mar 2001 11:17:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJFgIm027703 for ; Tue, 13 Mar 2001 11:15:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DJFgxd027702 for mobile-ip-dist; Tue, 13 Mar 2001 11:15:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJFQIm027695 for ; Tue, 13 Mar 2001 11:15:26 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05617 for ; Tue, 13 Mar 2001 14:15:25 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA25777 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 14:15:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2D8UoIm026735 for ; Tue, 13 Mar 2001 00:30:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26603 for ; Tue, 13 Mar 2001 00:30:50 -0800 (PST) Received: from mailhost.tbit.dk (mailhostnew.tbit.dk [194.182.135.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18243 for ; Tue, 13 Mar 2001 00:30:46 -0800 (PST) Received: from ted.ericsson.dk (IDENT:root@mailhost.tbit.dk [194.182.135.150]) by mailhost.tbit.dk (8.9.3/8.9.3) with ESMTP id JAA13054; Tue, 13 Mar 2001 09:30:43 +0100 Message-ID: <3AADDAB3.4152E73D@ted.ericsson.dk> Date: Tue, 13 Mar 2001 09:30:43 +0100 From: Peter Grimstrup Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.15-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comments on draft-ietf-mobileip-ipv6-13.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please consider these suggestions to clarify/change draft-ietf-mobileip-ipv6-13.txt learned during the Connectathon event this year: Section "5.7 ICMP Home Agent Address Discovery Reply Message" should mention that the Home Agent Addresses field may be absent if the sending router is the only HA passing the filtering of HA's applied according to section 9.2. Section "8.5 Sending Binding Acknowledgments" states that "... the packet MUST be sent using a Routing header ...". Most often the deregistration is sent from the home address, in this case a routing header is not needed - does not harm though. I suggest using a routing header in this case is admissible, but not required. Peter -- Peter Grimstrup Systems Developer Ericsson Telebit A/S tel: +45 89 38 52 75 Skanderborgvej 232 fax: +45 89 38 51 01 DK 8260 Viby J, Denmark e-mail: peter.grimstrup@ted.ericsson.dk From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 14:37:10 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26932 for ; Tue, 13 Mar 2001 14:37:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10221; Tue, 13 Mar 2001 11:37:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21225; Tue, 13 Mar 2001 11:36:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJZ0Im027776 for ; Tue, 13 Mar 2001 11:35:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DJZ05e027775 for mobile-ip-dist; Tue, 13 Mar 2001 11:35:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJYtIm027768 for ; Tue, 13 Mar 2001 11:34:55 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09318 for ; Tue, 13 Mar 2001 14:34:53 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA26161 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 14:34:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DB28Im027004 for ; Tue, 13 Mar 2001 03:02:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25958 for ; Tue, 13 Mar 2001 03:02:08 -0800 (PST) Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04788 for ; Tue, 13 Mar 2001 03:02:05 -0800 (PST) Received: by mx02.melco.co.jp (mx02) id UAA14755; Tue, 13 Mar 2001 20:01:42 +0900 (JST) Received: by mr02.melco.co.jp (mr02) id UAA18800; Tue, 13 Mar 2001 20:01:41 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id UAA24795; Tue, 13 Mar 2001 20:01:38 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id UAA09026; Tue, 13 Mar 2001 20:01:37 +0900 (JST) Message-ID: <00d801c0abad$1a4c3df0$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: Cc: "Ishibashi" References: Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6) Date: Tue, 13 Mar 2001 20:02:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karim wrote: > Hello > > > Here, I am confusing. > > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip- > > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff. > > Low latency Handoffs proposes two methods: > > - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff > - Network Initiated, Mobile Terminated (NIMOT) Handoff > > This is the combination of two existing drafts. > The first method comes from draft-elmalki-mobileip-fast-handoffs-03 > and the second is from draft-calhoun-mobileip-proactive-fa-03. > > > In this draft, the Registration procedure will be done pro-actively. > > On the other hand, the fast handoff for Mobile IPv6 draft proposes > > another mechanism. > > The v4 and v6 drafts do not propose completely different mechanisms. > You can run a similar handoff procedure in v4 and v6. However you may > be pointing to a NIMOT-like approach in v6? Yes. I think same mechanisms(NIMOT) will be needed. > > And I have another confusion. > > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff) > > without the bi-casting, the loss of packets during the transition > > between networks will be eliminated. > > If you don't use bicasting (independently of the method supported) then > achieving a loss-less v4 handoff depends on when the MN actually disconnects > from the old FA and connects to the new one, if buffering is available etc. > This needs more looking into and hopefully we'll get some discussion going > at this IETF. Yes, I agree. And I recognize that achieving a loss-less v4 handoff has been proposed in "Buffer Management for Mobile IP"draft (draft-mkhalil-mobileip-buffer-00.txt), and achieving a loss-less v6 handoff is discussed on Seamoby CT. So, I am considering simultaneous support of a loss-less handoff and a fast handoff. There are some mechanisms in this simultaneous support. For example, Home Agent should manage according to each microflow, that is, HA should be buffering packets for microflows required a loss-less, and be forwarding packets for microflow required a fast handoff. Or, should HA manage a mobility binding according to each microflow ? But then where are these discussions discussed, mobileip or seamoby CT ? Regards, Ishibashi From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 15:09:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27501 for ; Tue, 13 Mar 2001 15:09:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01683; Tue, 13 Mar 2001 12:09:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22262; Tue, 13 Mar 2001 12:09:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DK8QIm027956 for ; Tue, 13 Mar 2001 12:08:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DK8PD7027955 for mobile-ip-dist; Tue, 13 Mar 2001 12:08:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DK8KIm027948 for ; Tue, 13 Mar 2001 12:08:21 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05227 for ; Tue, 13 Mar 2001 15:08:20 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA28608 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 15:08:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DE8EIm027112 for ; Tue, 13 Mar 2001 06:08:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00386 for ; Tue, 13 Mar 2001 06:08:15 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17079 for ; Tue, 13 Mar 2001 06:08:14 -0800 (PST) Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id PAA14910; Tue, 13 Mar 2001 15:07:51 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id PAA01014; Tue, 13 Mar 2001 15:06:46 +0100 (MET) Message-ID: <3AAE2976.5767DFD0@inrialpes.fr> Date: Tue, 13 Mar 2001 15:06:46 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Hesham Soliman (EPA)" , charliep@iprg.nokia.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <034BEFD03799D411A59F00508BDF7546013DBC1F@esealnt448.al.sw.ericsson.se> <3AAD2524.3903D7DB@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------BCAC481015B2BAC80DAF508C" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------BCAC481015B2BAC80DAF508C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charlie Perkins wrote: > Hello Hesham, > > > You're absolutely right. That's exactly what we have been avoiding > > in the HMIPv6 work. There is no need for a non-robust solution > > that intrduces a tree of single points of failures. As you said > > network administrators can force routes to introduce this effect > > if they want their networks to be less robust for other reasons. > > I think that the MAP would qualify as a single point of failure. > Hello Charlie, a nice property of HMIPv6 (basic mode) is that the RCoA is NOT the address of the MAP... The MAP only proxies the packets (like the HA).... As a result if the MAP fails, another MAP on the links can easily be used to backup the first MAP (of course a protocol is needed here to duplicate the context but this is feasable -see section 3.3 of http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz for more infos) transparently to the CNs (i.e. the RCoA does not change).... Alternatively, if the MAP fails and the previous solution is not implemented, the MN will stop receiving the MAP adverti. message for this MAP and will switch automatically to another MAP...communication will then be reestablished....the first solution might be faster though... So I am not sure that the MAP would qualify as a single point of failure because it can easily be changed dynamically and transparently to the CNs ....... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------BCAC481015B2BAC80DAF508C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Charlie Perkins wrote:
Hello Hesham,

> You're absolutely right. That's exactly what we have been avoiding
> in the HMIPv6 work. There is no need for a non-robust solution
> that intrduces a tree of single points of failures. As you said
> network administrators can force routes to introduce this effect
> if they want their networks to be less robust for other reasons.

I think that the MAP would qualify as a single point of failure.
 

Hello Charlie,

a nice property of HMIPv6 (basic mode)  is that the RCoA is NOT the address of the MAP...
The MAP only proxies the packets (like the HA)....

As a result if the MAP fails, another MAP on the links can easily be used to backup
the first MAP (of course a protocol is needed here to duplicate the context but this
is feasable -see section 3.3 of http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz for more infos)
transparently to the CNs (i.e. the RCoA does not change)....

Alternatively, if the MAP fails and the previous solution is not implemented, the MN will stop receiving the
MAP adverti. message for this MAP and
will switch automatically to another MAP...communication will then be reestablished....the first solution might
be faster though...

So I am not sure that the MAP would qualify as a single point of failure because it can easily
be changed dynamically and transparently to the CNs .......

regards,

Claude.
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------BCAC481015B2BAC80DAF508C-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:10:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28444 for ; Tue, 13 Mar 2001 16:10:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25899; Tue, 13 Mar 2001 13:10:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12229; Tue, 13 Mar 2001 13:10:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DL8AIm028092 for ; Tue, 13 Mar 2001 13:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DL8ABx028091 for mobile-ip-dist; Tue, 13 Mar 2001 13:08:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DL80Im028084 for ; Tue, 13 Mar 2001 13:08:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17793 for ; Tue, 13 Mar 2001 16:08:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA29766 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:08:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DF6fIm027182 for ; Tue, 13 Mar 2001 07:06:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28671 for ; Tue, 13 Mar 2001 07:06:30 -0800 (PST) Received: from exchange.birdstep.org ([194.143.101.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09681 for ; Tue, 13 Mar 2001 07:06:23 -0800 (PST) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <16XPQ8WQ>; Tue, 13 Mar 2001 16:01:26 +0100 Message-ID: <9BF5DD8B8F3CD411959500B0D020ED3E13C07B@EXCHANGE> From: Frode Beckmann Nilsen To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Status for mipv4 fast/low-latency handoff Date: Tue, 13 Mar 2001 16:01:26 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I'm new to this list and are interested in the efforts withing the WG on Mobile IP v4 fast handoff/handover or low-latency handoff/handover. I have checked the WG home page and recognize that there is a new draft on this subject * draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt I have also browsed through the mail archive and recognize that there has been a discussion about merging the following two drafts also addressing the subject: * draft-calhoun-mobileip-proactive-fa-02.txt * draft-elmalki-mobileip-fast-handoffs-03.txt However, I haven't been able to figure out if the attempt to merge the two drafts have succedded? Neither have I been able to determine the history behind the former draft? How is it linked to the latter two draft? Regards, FrodeN From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:17:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28529 for ; Tue, 13 Mar 2001 16:17:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03775; Tue, 13 Mar 2001 13:17:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13876; Tue, 13 Mar 2001 13:17:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLG0Im028179 for ; Tue, 13 Mar 2001 13:16:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLG0FK028178 for mobile-ip-dist; Tue, 13 Mar 2001 13:16:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLFtIm028171 for ; Tue, 13 Mar 2001 13:15:55 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28937 for ; Tue, 13 Mar 2001 16:15:54 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA29979 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:16:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DFCCIm027221 for ; Tue, 13 Mar 2001 07:12:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18180 for ; Tue, 13 Mar 2001 07:12:13 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13467 for ; Tue, 13 Mar 2001 07:12:12 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 13 Mar 2001 09:06:52 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 09:11:55 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5380@crchy271.us.nortel.com> From: "Glenn Morrow" To: IMCEAMAILTO-eunsoo+40ctr+2Ecolumbia+2Eedu@nt.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Tue, 13 Mar 2001 09:11:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABCF.F060A760" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABCF.F060A760 Content-Type: text/plain; charset="iso-8859-1" Eunsoo, In regards to your draft, thank you for taking the time to detail this functionality. Anyone who takes the time to contribute to the IETF should be commended. I believe your draft actually illustrates many of the problematic issues that will occur with the RR solution as is. While I believe your work is sound and well thought out, I am hoping that we can arrive at a solution that is less complicated and more naturally self repairing at the IP layer. I do not believe we have the same "already deployed" limitations with IPv6 that we had with IPv4 at this time. I am hoping we can use this to our advantage. Thanks, Glenn If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration. Our I-D is available at the following URL for now: http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg -00.txt http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg -00.pdf ------_=_NextPart_001_01C0ABCF.F060A760 Content-Type: text/html; charset="iso-8859-1" FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
Eunsoo,
 
In regards to your draft, thank you for taking the time to detail this functionality. Anyone who takes the time to contribute to the IETF should be commended. I believe your draft actually illustrates many of the problematic issues that will occur with the RR solution as is. While I believe your work is sound and well thought out, I am hoping that we can arrive at a solution that is less complicated and more naturally self repairing at the IP layer. I do not believe we have the same "already deployed" limitations with IPv6 that we had with IPv4 at this time. I am hoping we can use this to our advantage.
 
Thanks,
 
Glenn
If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration.

------_=_NextPart_001_01C0ABCF.F060A760-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:33:57 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28673 for ; Tue, 13 Mar 2001 16:33:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19956; Tue, 13 Mar 2001 13:33:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24539; Tue, 13 Mar 2001 13:33:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLWZIm028260 for ; Tue, 13 Mar 2001 13:32:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLWYu4028259 for mobile-ip-dist; Tue, 13 Mar 2001 13:32:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLWPIm028252 for ; Tue, 13 Mar 2001 13:32:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02661 for ; Tue, 13 Mar 2001 16:32:24 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00389 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:32:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DFUFIm027240 for ; Tue, 13 Mar 2001 07:30:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02124 for ; Tue, 13 Mar 2001 07:30:15 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26363 for ; Tue, 13 Mar 2001 07:30:13 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 13 Mar 2001 09:29:37 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 09:29:35 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E53D6@crchy271.us.nortel.com> From: "Glenn Morrow" To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Tue, 13 Mar 2001 09:29:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABD2.67DC5A30" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABD2.67DC5A30 Content-Type: text/plain; charset="iso-8859-1" Charlie, Here are my concerns, founded or not. It seems to me that we might be able to work out a network layer that can provide the RR benefits yet deal with multiple paths into and out of any network without having to pick a single arbitrary point for reverse traffic. I.e. for one stream the mobile might use one GFA while for another stream the mobile might use another most optimal GFA. I know the mechanics of this solution will cause more per-host routes in the local domain per mobile but I believe it may be more route optimal, more self-repairing and leverage any existing routing policy the network provider may have. I also do not relish the thought of having to send double binding updates - one for the regional and one for the CN's and Home Subnets. It seems to me that the mobile shouldn't even need to be aware that this function is happening. In regards to these connection oriented methods CoS and bandwidth management. They are more stateful and we should avoid state when we can; however, these mechanism have and should continue to be designed to repair themselves based upon topological changes. As they are designed today, these healing mechanisms do not interfere with routing policy. This leads us to my concern that RR in IPv6, as it is, may greatly complicate these existing and even newly proposed methods of signaling and accounting for CoS and bandwidth, not to mention traffic engineering and the ability of providers to control routing policy. I see RR as it stands now as a new routing protocol that will likely interfere with any routing policy controlled with say OSPF. Do you believe there is a mechanism to have the AR's, crossovers and GFA's up to an arbitrary tier intercept or be sent the regular binding updates, yet still have the BU's propogate to the CN's? What new problems would these new mechanics create in your opinion? Do you believe we should spend some time to explore these methods, even if it means changing something about MIPv6? My last comment is that I apologize for any caustic statements I may have made in my previous mails. I should have been more clear, to the exact points and constructive. Thanks, Glenn -----Original Message----- From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] Sent: Monday, March 12, 2001 1:28 PM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Hello Glenn, > I still do not understand why the ability to place something at an > arbitrary point justifies destroying the connectionless nature of a IP > or even IP mobility. I'm not sure what the connection is between these two clauses. Any sort of localized registration is supposed to hide changes of the care-of address. The mobile node can consent to such hiding. Maybe there is something else about our protocol that looks like an intent to destroy the connectionless nature of IP. Could you please be a little more specific about your concerns here? If I may guess that the mobile node has to keep track of more network state (what one might call "connection state") then I guess you would prefer to minimize that. On this we can agree. Then the discussion should center on ways that state is gratuitously set up as a protocol requirement, and make the tradeoffs. > If arbitrary point is so important, why don't you just tunnel to the > arbitrary point based upon routing policy and leave a natural > aggregatable solution connectionless. People can always tinker with > their routes to make single points of failure if they wish but why > build it in. We basically attempted to do exactly what you suggest, by allowing an anycast address to be used by the mobile node for the purposes of making regional registrations. However, there may be other solutions that have even less connection state required. I agree that getting rid of single points of failure is a good idea. > Have people simply given up on keeping things connectionless? Is there > some sort of graph theory that somehow proves that this is a > connection oriented problem domain? I have not at all given up on it. Some things seem to be "connection- oriented" -- say, for instance, header compression state or QoS. Connectionless has universal appeal because of its simplicity and typically good-enough performance. I think that regionalized registrations lies more on the connectionless side, and that we should aim to make it as connectionless as possible, while still making it possible. Regards, Charlie P. ------_=_NextPart_001_01C0ABD2.67DC5A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FW: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt

Charlie,

Here are my concerns, founded or not.

It seems to me that we might be able to work out a = network layer that can provide the RR benefits yet deal with multiple = paths into and out of any network without having to pick a single = arbitrary point for reverse traffic. I.e. for one stream the mobile = might use one GFA while for another stream the mobile might use another = most optimal GFA.

I know the mechanics of this solution will cause more = per-host routes in the local domain per mobile but I believe it may be = more route optimal, more self-repairing and leverage any existing = routing policy the network provider may have.

I also do not relish the thought of having to send = double binding updates - one for the regional and one for the CN's and = Home Subnets. It seems to me that the mobile shouldn't even need to be = aware that this function is happening.

In regards to these connection oriented methods CoS = and bandwidth management. They are more stateful and we should avoid = state when we can; however, these mechanism have and should continue to = be designed to repair themselves based upon topological changes. As = they are designed today, these healing mechanisms do not interfere with = routing policy.

This leads us to my concern that RR in IPv6, as it = is, may greatly complicate these existing and even newly proposed = methods of signaling and accounting for CoS and bandwidth, not to = mention traffic engineering and the ability of providers to control = routing policy. I see RR as it stands now as a new routing protocol = that will likely interfere with any routing policy controlled with say = OSPF.

Do you believe there is a mechanism to have the AR's, = crossovers and GFA's up to an arbitrary tier intercept or be sent the = regular binding updates, yet still have the BU's propogate to the CN's? =

What new problems would these new mechanics create in = your opinion?

Do you believe we should spend some time to explore = these methods, even if it means changing something about MIPv6?

My last comment is that I apologize for any caustic = statements I may have made in my previous mails. I should have been = more clear, to the exact points and constructive.

Thanks,

Glenn

-----Original Message-----
From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Monday, March 12, 2001 1:28 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] FW: I-D
ACTION:draft-malinen-mobileip-regreg6-01.txt



Hello Glenn,

> I still do not understand why the ability to = place something at an
> arbitrary point justifies destroying the = connectionless nature of a IP
> or even IP mobility.

I'm not sure what the connection is between these two = clauses.
Any sort of localized registration is supposed to = hide changes of
the care-of address.  The mobile node can = consent to such hiding.
Maybe there is something else about our protocol = that looks like
an intent to destroy the connectionless nature of = IP.  Could you
please be a little more specific about your concerns = here?

If I may guess that the mobile node has to keep track = of more
network state (what one might call "connection = state") then I guess
you would prefer to minimize that.  On this we = can agree.  Then
the discussion should center on ways that state is = gratuitously
set up as a protocol requirement, and make the = tradeoffs.

> If arbitrary point is so important, why don't = you just tunnel to the
> arbitrary point based upon routing policy and = leave a natural
> aggregatable solution connectionless. People = can always tinker with
> their routes to make single points of failure = if they wish but why
> build it in.

We basically attempted to do exactly what you = suggest, by
allowing an anycast address to be used by the mobile = node
for the purposes of making regional = registrations.  However,
there may be other solutions that have even less = connection
state required.  I agree that getting rid of = single points of failure
is a good idea.

> Have people simply given up on keeping things = connectionless? Is there
> some sort of graph theory that somehow proves = that this is a
> connection oriented problem domain?

I have not at all given up on it.  Some things = seem to be "connection-
oriented" -- say, for instance, header = compression state or QoS.
Connectionless has universal appeal because of its = simplicity and
typically good-enough performance.  I think = that regionalized
registrations lies more on the connectionless side, = and that we
should aim to make it as connectionless as possible, = while still
making it possible.

Regards,
Charlie P.


------_=_NextPart_001_01C0ABD2.67DC5A30-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:40:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28788 for ; Tue, 13 Mar 2001 16:40:12 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18703; Tue, 13 Mar 2001 13:40:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09695; Tue, 13 Mar 2001 13:40:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLd1Im028343 for ; Tue, 13 Mar 2001 13:39:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLd1tV028342 for mobile-ip-dist; Tue, 13 Mar 2001 13:39:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLcuIm028335 for ; Tue, 13 Mar 2001 13:38:57 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24576 for ; Tue, 13 Mar 2001 16:38:56 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00519 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:39:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DFsEIm027261 for ; Tue, 13 Mar 2001 07:54:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24223 for ; Tue, 13 Mar 2001 07:54:14 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20589 for ; Tue, 13 Mar 2001 07:54:14 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 13 Mar 2001 09:46:27 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 09:51:30 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5427@crchy271.us.nortel.com> From: "Glenn Morrow" To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: Comments on Regional Registration Date: Tue, 13 Mar 2001 09:51:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABD5.786347D0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABD5.786347D0 Content-Type: text/plain; charset="iso-8859-1" GM> Line item apologies below. -----Original Message----- From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] Sent: Tuesday, March 13, 2001 12:44 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: mobile-ip@sunroof.eng.sun.com Subject: Comments on Regional Registration Hello folks, Sorry if this is a duplicate. I do not know if the original made it out of our site. > Thanks for the reply. I am trying to get people to open up their minds with > IPv6. It is still fairly malleable for change and has many tools which can > be used to achieve this functionality. Do you mean to suggest changing IPv6? If you mean changing something else (using its favorable malleability), can you say what? GM> Charlie, I see the output of work for node mobility in the mobile IP WG as IPv6 - not as MIPv6. Your statement above is correct and I will try to learn to say that. > The RR draft seems to be let's > fork-lift the IPv4 solution and slap in some anycast magic. I think a better > solution is out there for this functionality using IPv6's features that > leverages any natural aggregation that may exist in any given IP network. A slap is not respectful treatment for anybody, not even an anycast address. I think that the anycast address has exactly the right semantics. We also are trying to get people to open their minds with IPv6. GM> My statement above was horrible and extremely immature - downright crapy too. There are significant differences between the v4 and v6 versions and the demonstration of resourceful, creative, forward thinking is most evident in the IPv6 solution. Anycast is exactly right, because what the mobile node "wants" is for the crossover router to take the appropriate action, without the mobile node knowing which router it is. Anycast even helps to preserve the connectionless nature which we would like to preserve for regionalized mobility handling. GM> I agree, I support anycast too. To vilify a solution which employs it as magic was wrong and I apologize. > In my opinion arbitary point is not a requirement and even if it were there > are better solutions which do not require any changes to the protocols, > especially if you use tunneling. I thought that a lot of people wanted to use an arbitrary point of contact (between access network and Internet) as an "anchor point". Or maybe you are referring to something else. GM> I can see instances where it might be useful. I was not clear to begin with on my concerns; hopefully my response to your other mail clarifies the position. > RR is nothing more than an IP proxy using MIP signaling to provision it. In a subsequent note, you retracted this characterization, but I'd still like to know how you wished to draw the analogy between something in regionalized registration, and an IP proxy (what is an IP proxy?). GM> Proxy - Firewall for forward traffic and/or reverse traffic. This statement was not true at all. Regards, Charlie P. GM> Charlie, I sincerely apologize and will strive to not act like a little turd anymore. Thanks, Glenn ------_=_NextPart_001_01C0ABD5.786347D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on Regional Registration

GM> Line item apologies below.

-----Original Message-----
From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Tuesday, March 13, 2001 12:44 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Comments on Regional Registration



Hello folks,

Sorry if this is a duplicate.  I do not know if = the original
made it out of our site.

> Thanks for the reply. I am trying to get people = to open up their minds with
> IPv6. It is still fairly malleable for change = and has many tools which can
> be used to achieve this functionality.

Do you mean to suggest changing IPv6?  If you = mean changing something
else (using its favorable malleability), can you say = what?

GM> Charlie, I see the output of work for node = mobility in the mobile IP WG as IPv6 - not as MIPv6. Your statement = above is correct and I will try to learn to say that.

>          = ;            = ;            = ;         The RR draft seems to = be let's
> fork-lift the IPv4 solution and slap in some = anycast magic. I think a better
> solution is out there for this functionality = using IPv6's features that
> leverages any natural aggregation that may = exist in any given IP network.

A slap is not respectful treatment for anybody, not = even an
anycast address.  I think that the anycast = address has
exactly the right semantics.  We also are = trying to get people
to open their minds with IPv6.

GM> My statement above was horrible and extremely = immature - downright crapy too. There are significant differences = between the v4 and v6 versions and the demonstration of resourceful, = creative, forward thinking is most evident in the IPv6 solution. =

Anycast is exactly right, because what the mobile = node "wants"
is for the crossover router to take the appropriate = action,
without the mobile node knowing which router it = is.

Anycast even helps to preserve the connectionless = nature which
we would like to preserve for regionalized mobility = handling.

GM> I agree, I support anycast too. To vilify a = solution which employs it as magic was wrong and I apologize.

> In my opinion arbitary point is not a = requirement and even if it were there
> are better solutions  which do not require = any changes to the protocols,
> especially if you use tunneling.

I thought that a lot of people wanted to use an = arbitrary point of
contact (between access network and Internet) as an = "anchor point".
Or maybe you are referring to something else.

GM> I can see instances where it might be useful. = I was not clear to begin with on my concerns; hopefully my response to = your other mail clarifies the position.


> RR is nothing more than an IP proxy using MIP = signaling to provision it.

In a subsequent note, you retracted this = characterization, but I'd
still like to know how you wished to draw the = analogy between
something in regionalized registration, and an IP = proxy (what
is an IP proxy?).


GM> Proxy - Firewall for forward traffic and/or = reverse traffic. This statement was not true at all.


Regards,
Charlie P.


GM> Charlie, I sincerely apologize and will strive = to not act like a little turd anymore.

Thanks,

Glenn

------_=_NextPart_001_01C0ABD5.786347D0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:46:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28871 for ; Tue, 13 Mar 2001 16:46:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01642; Tue, 13 Mar 2001 13:46:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11422; Tue, 13 Mar 2001 13:46:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLiwIm028399 for ; Tue, 13 Mar 2001 13:44:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLiwN4028398 for mobile-ip-dist; Tue, 13 Mar 2001 13:44:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLirIm028391 for ; Tue, 13 Mar 2001 13:44:53 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05087 for ; Tue, 13 Mar 2001 16:44:52 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00638 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:44:58 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DFwDIm027272 for ; Tue, 13 Mar 2001 07:58:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07183 for ; Tue, 13 Mar 2001 07:58:14 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16162 for ; Tue, 13 Mar 2001 07:58:12 -0800 (PST) Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id QAA19550 for ; Tue, 13 Mar 2001 16:58:10 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id QAA01206 for ; Tue, 13 Mar 2001 16:57:04 +0100 (MET) Message-ID: <3AAE4350.A7D315E@inrialpes.fr> Date: Tue, 13 Mar 2001 16:57:04 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] -Hierarchical schemes- Content-Type: multipart/alternative; boundary="------------687C7F0238B1984BEACDFD9B" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------687C7F0238B1984BEACDFD9B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, There will be a 20 mn "hierarchical Mobility Schemes" at the next Mobile IP meeting. What is the purpose / goal of this slot ? Should the authors of the different proposals prepare something for this meeting? Did I miss something? thanks, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------687C7F0238B1984BEACDFD9B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

There will be a 20 mn "hierarchical Mobility Schemes" at the next Mobile IP meeting.
What is the purpose / goal of this slot ?

Should the authors of the different proposals prepare something for this meeting?
Did I miss something?
thanks,

Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------687C7F0238B1984BEACDFD9B-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 16:54:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28990 for ; Tue, 13 Mar 2001 16:54:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08438; Tue, 13 Mar 2001 13:54:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13599; Tue, 13 Mar 2001 13:54:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLrZIm028469 for ; Tue, 13 Mar 2001 13:53:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLrZq9028468 for mobile-ip-dist; Tue, 13 Mar 2001 13:53:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLrUIm028461 for ; Tue, 13 Mar 2001 13:53:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06603 for ; Tue, 13 Mar 2001 16:53:29 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00812 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:53:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DG4qIm027285 for ; Tue, 13 Mar 2001 08:04:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08308 for ; Tue, 13 Mar 2001 08:04:53 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20691 for ; Tue, 13 Mar 2001 08:04:50 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 13 Mar 2001 10:00:49 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 10:00:45 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5461@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Tue, 13 Mar 2001 10:00:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABD6.C1B8F910" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABD6.C1B8F910 Content-Type: text/plain; charset="iso-8859-1" Hesham, I hope my response to Charlie's query clears up what I was trying to say technically. I am hoping that we can all work together to come up with the best solution possible as a team; however, my stupid euphamisms have probably reduced any chances of that now. There are merits to both RR and HMIP. As we move forward, we should try to get the best of both worlds. Thanks, Glenn -----Original Message----- From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: Sunday, March 11, 2001 9:18 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Hello Glenn, You're absolutely right. That's exactly what we have been avoiding in the HMIPv6 work. There is no need for a non-robust solution that intrduces a tree of single points of failures. As you said network administrators can force routes to introduce this effect if they want their networks to be less robust for other reasons. So far I haven't heard *any* reason for it. Cheers, Hesham > -----Original Message----- > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > Sent: Saturday, 10 March 2001 6:40 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt > > Hello, > > I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. > > If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in. > > Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain? > > Respectfully, I wish to be illuminated on this - one way or the other. > > Thanks, > > Glenn > > -----Original Message----- > From: Internet-Drafts@ietf.org [ ] > Sent: Friday, March 09, 2001 6:35 AM > To: IETF-Announce > Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mobile IPv6 Regional Registrations > Author(s) : J. Malinen, F. Le, C. Perkins > Filename : draft-malinen-mobileip-regreg6-01.txt > Pages : 28 > Date : 08-Mar-01 > > This document describes Mobile IPv6 regional registration as an > optional extension to Mobile IPv6. Regional registration introduces > visited-domain mobility agent functionality for proxying a public > care-of-address which remains the same while the mobile node > moves in the visited domain. This reduces the binding update > signaling latency for the mobile node and signaling load outside the > visited domain. The protocol defines regional mobility capability > negotiation, regional binding update signaling, and regional-aware > data routing through a hierarchy of visited-domain mobility agents. > The protocol allows for an arbitrary point in the visited-domain > hierarchy to distribute the connection-state maintenance between > several mobility agents. IPSec AH is used for securing the protocol > as in basic Mobile IPv6. > > A URL for this Internet-Draft is: > > > 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-malinen-mobileip-regreg6-01.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-malinen-mobileip-regreg6-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. > > << Message: Untitled Attachment >> ------_=_NextPart_001_01C0ABD6.C1B8F910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FW: I-D = ACTION:draft-malinen-mobileip-regreg6-01. txt

Hesham,

I hope my response to Charlie's query clears up what = I was trying to say technically. 

I am hoping that we can all work together to come up = with the best solution possible as a team; however, my stupid = euphamisms have probably reduced any chances of that now.

There are merits to both RR and HMIP. As we move = forward, we should try to get the best of both worlds.

Thanks,

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era= .ericsson.se]
Sent: Sunday, March 11, 2001 9:18 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: I-D
ACTION:draft-malinen-mobileip-regreg6-01. txt


Hello Glenn,

You're absolutely right. That's exactly what we have = been avoiding
in the HMIPv6 work. There is no need for a = non-robust solution
that intrduces a tree of single points of failures. = As you said
network administrators can force routes to introduce = this effect
if they want their networks to be less robust for = other reasons.

So far I haven't heard *any* reason for it.

Cheers,
Hesham

> -----Original Message-----
> From: Glenn Morrow = [SMTP:gmorrow@nortelnetworks.com]
> Sent: Saturday, 10 March 2001 6:40
> To:   = mobile-ip@sunroof.eng.sun.com
> Subject:      = [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
>
> Hello,
>
> I still do not understand why the ability to = place something at an arbitrary point justifies destroying the = connectionless nature of a IP or even IP mobility.

>
> If arbitrary point is so important, why don't = you just tunnel to the arbitrary point based upon routing policy and = leave a natural aggregatable solution connectionless. People can always = tinker with their routes to make single points of failure if they wish = but why build it in.

>
> Have people simply given up on keeping things = connectionless? Is there some sort of graph theory that somehow proves = that this is a connection oriented problem domain?

>
> Respectfully, I wish to be illuminated on this = - one way or the other.
>
> Thanks,
>
> Glenn
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [ <mailto:Internet-Drafts@ietf.org= >]
> Sent: Friday, March 09, 2001 6:35 AM
> To: IETF-Announce
> Subject: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt
>
>
> A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>
>
>         = Title           : = Mobile IPv6 Regional Registrations
>         = Author(s)       : J. Malinen, F. Le, C. = Perkins
>         = Filename        : = draft-malinen-mobileip-regreg6-01.txt
>         = Pages           : 28 =
>         = Date            = : 08-Mar-01
>         =
> This document describes Mobile IPv6 regional = registration as an
> optional extension to Mobile IPv6.  = Regional registration introduces
> visited-domain mobility agent functionality for = proxying a public
> care-of-address which remains the same while = the mobile node
> moves in the visited domain.  This reduces = the binding update
> signaling latency for the mobile node and = signaling load outside the
> visited domain.  The protocol defines = regional mobility capability
> negotiation, regional binding update signaling, = and regional-aware
> data routing through a hierarchy of = visited-domain mobility agents.
> The protocol allows for an arbitrary point in = the visited-domain
> hierarchy to distribute the connection-state = maintenance between
> several mobility agents.  IPSec AH is used = for securing the protocol
> as in basic Mobile IPv6.
>
> A URL for this Internet-Draft is:
> <http://www.ietf.org/internet-drafts/draft-malinen-mobi= leip-regreg6-01.txt>
>
> 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-malinen-mobileip-regreg6-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-malinen-mobileip-regreg6-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.
>
>    << Message: Untitled = Attachment >>

------_=_NextPart_001_01C0ABD6.C1B8F910-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:00:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29050 for ; Tue, 13 Mar 2001 17:00:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28087; Tue, 13 Mar 2001 14:00:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14858; Tue, 13 Mar 2001 14:00:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLxFIm028545 for ; Tue, 13 Mar 2001 13:59:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DLxFRb028544 for mobile-ip-dist; Tue, 13 Mar 2001 13:59:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLxAIm028537 for ; Tue, 13 Mar 2001 13:59:11 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27604 for ; Tue, 13 Mar 2001 16:59:09 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00931 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 16:59:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DG9lIm027299 for ; Tue, 13 Mar 2001 08:09:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27676 for ; Tue, 13 Mar 2001 08:09:47 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05020 for ; Tue, 13 Mar 2001 08:09:47 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 13 Mar 2001 10:07:27 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 10:07:25 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43017E5476@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, "Hesham Soliman (EPA)" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Tue, 13 Mar 2001 10:07:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABD7.B1365460" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABD7.B1365460 Content-Type: text/plain; charset="iso-8859-1" Charlie, Thank You - you have hit it on the head. I am hoping we can use the existing MIP BU's that eventually end up at the CN's. We need to figure out how to get the local domain routers in the loop of this signaling. The ideas that come to mind do require changes to the basic MIPv6, though. I'm not sure if people are willing to consider changes to it. Thanks, Glenn and I apologize again. -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Monday, March 12, 2001 1:36 PM To: Hesham Soliman (EPA) Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Hello Hesham, > You're absolutely right. That's exactly what we have been avoiding > in the HMIPv6 work. There is no need for a non-robust solution > that intrduces a tree of single points of failures. As you said > network administrators can force routes to introduce this effect > if they want their networks to be less robust for other reasons. I think that the MAP would qualify as a single point of failure. I also think that we need to avoid restricting the solution to work only with a single point of failure. It would be nice to have a more general solution that doesn't make the mobile node learn all the relevant topology. I think what Glenn was suggesting is basically to rely on some scheme that moves all the regional knowledge into the realm of host routing that is controlled by a routing protocol invisible to the mobile node. This might be possible, but there are a lot of problems with it that need attention. In the abstract, I find the idea very appealing. Some of the problems have to do with stale routing information. We'd like to avoid putting routes where they aren't needed -- this is the "proactive" vs. "reactive" debate in new clothes. Our experience with regional registration has shown some ways to do this. Regards, Charlie P. ------_=_NextPart_001_01C0ABD7.B1365460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FW: I-D = ACTION:draft-malinen-mobileip-regreg6-01.txt

Charlie,

Thank You - you have hit it on the head. I am hoping = we can use the existing MIP BU's that eventually end up at the CN's. We = need to figure out how to get the local domain routers in the loop of = this signaling. The ideas that come to mind do require changes to the = basic MIPv6, though. I'm not sure if people are willing to consider = changes to it.

Thanks,

Glenn

and I apologize again.

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Monday, March 12, 2001 1:36 PM
To: Hesham Soliman (EPA)
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] FW: I-D
ACTION:draft-malinen-mobileip-regreg6-01.txt


Hello Hesham,

> You're absolutely right. That's exactly what we = have been avoiding
> in the HMIPv6 work. There is no need for a = non-robust solution
> that intrduces a tree of single points of = failures. As you said
> network administrators can force routes to = introduce this effect
> if they want their networks to be less robust = for other reasons.

I think that the MAP would qualify as a single point = of failure.

I also think that we need to avoid restricting the = solution to work only
with a single point of failure.  It would be = nice to have a more general
solution that doesn't make the mobile node learn all = the relevant
topology.

I think what Glenn was suggesting is basically to = rely on some scheme
that moves all the regional knowledge into the realm = of host routing
that is controlled by a routing protocol invisible = to the mobile node.
This might be possible, but there are a lot of = problems with it that
need attention.  In the abstract, I find the = idea very appealing.  Some
of the problems have to do with stale routing = information.  We'd like
to avoid putting routes where they aren't needed -- = this is the "proactive"
vs. "reactive" debate in new = clothes.  Our experience with regional
registration has shown some ways to do this.

Regards,
Charlie P.

------_=_NextPart_001_01C0ABD7.B1365460-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:07:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29190 for ; Tue, 13 Mar 2001 17:07:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19060; Tue, 13 Mar 2001 14:07:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24898; Tue, 13 Mar 2001 14:07:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DM5aIm028611 for ; Tue, 13 Mar 2001 14:05:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DM5aDV028610 for mobile-ip-dist; Tue, 13 Mar 2001 14:05:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DM5VIm028603 for ; Tue, 13 Mar 2001 14:05:31 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08631 for ; Tue, 13 Mar 2001 17:05:29 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01051 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 17:05:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DGvZIm027381 for ; Tue, 13 Mar 2001 08:57:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05977 for ; Tue, 13 Mar 2001 08:57:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17464 for ; Tue, 13 Mar 2001 08:57:21 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA22873; Tue, 13 Mar 2001 08:57:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2DGvCX32738; Tue, 13 Mar 2001 08:57:12 -0800 X-mProtect: Tue, 13 Mar 2001 08:57:12 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdn5W9iW; Tue, 13 Mar 2001 08:57:07 PST Message-ID: <3AAE51A6.FFB050F@iprg.nokia.com> Date: Tue, 13 Mar 2001 08:58:14 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow CC: mobile-ip@sunroof.eng.sun.com, "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [mobile-ip] Re: Comments on Regional Registration References: <85AA7486A2C1D411BCA20000F8073E43017E5427@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Glenn, Thanks for your notes. I just have one question below, and then a comment about IPv4 regional registration. Glenn Morrow wrote: > Anycast is exactly right, because what the mobile node "wants" > is for the crossover router to take the appropriate action, > without the mobile node knowing which router it is. > > Anycast even helps to preserve the connectionless nature which > we would like to preserve for regionalized mobility handling. > > GM> I agree, I support anycast too. To vilify a solution which employs > it as magic was wrong and I apologize. No need for apology, but I wanted to point out that this particular use of anycast is easy to implement, assuming that one's IPv6 implementation supports anycast at all. I don't know whether we ought to publish the algorithmic steps, but it seems that most people who have coded network protocols could figure out how to make this particular anycast idea work. Thus I am claiming that we are not invoking magic here -- just to be clear. And, to be equally clear, I strongly suspect that you did not intend in your sentence to classify our anycast solution to be counted among those in the "magic" bin. My other comment was that I hope we can forward with the IPv4 regional registration draft. That protocol works, has implementations, has been through last call, and has been reissued with comments responding to last call. It is a very nice protocol (o.k. I am biased). I hope that it won't be neglected because of desires for a more robust and well-controlled host route dissemination mechanism. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:13:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29291 for ; Tue, 13 Mar 2001 17:13:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03628; Tue, 13 Mar 2001 14:13:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25941; Tue, 13 Mar 2001 14:13:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMBsIm028700 for ; Tue, 13 Mar 2001 14:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DMBsPA028699 for mobile-ip-dist; Tue, 13 Mar 2001 14:11:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMBnIm028692 for ; Tue, 13 Mar 2001 14:11:50 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00448 for ; Tue, 13 Mar 2001 17:11:50 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01185 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 17:11:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DJZpIm027778 for ; Tue, 13 Mar 2001 11:35:51 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20932 for ; Tue, 13 Mar 2001 11:35:51 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA29191 for ; Tue, 13 Mar 2001 11:35:50 -0800 (PST) Date: Tue, 13 Mar 2001 11:31:16 -0800 (PST) From: Pat Calhoun Subject: [mobile-ip] next week To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3AADC1B6.1772296C@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Can we do lunch of Wed? A bunch of folks want to talk about gen & AAA keys. PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:17:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29348 for ; Tue, 13 Mar 2001 17:17:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05346; Tue, 13 Mar 2001 14:17:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04148; Tue, 13 Mar 2001 14:17:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMFtIm028741 for ; Tue, 13 Mar 2001 14:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DMFssU028740 for mobile-ip-dist; Tue, 13 Mar 2001 14:15:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMFkIm028733 for ; Tue, 13 Mar 2001 14:15:47 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10284 for ; Tue, 13 Mar 2001 17:15:47 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01267 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 17:15:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DLDkIm028151 for ; Tue, 13 Mar 2001 13:13:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20102 for ; Tue, 13 Mar 2001 13:13:25 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23646 for ; Tue, 13 Mar 2001 13:13:08 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DLCHg23347 for ; Tue, 13 Mar 2001 15:12:17 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Mar 2001 15:12:15 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 15:12:14 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321365F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Tue, 13 Mar 2001 15:12:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Final agenda for the Mobile IP WG meeting at IETF50 Thursday March 22nd - 9:00 AM - 11.30 AM ---------------------------------------- Agenda bashing 5 Mins WG Doc Status 5 Mins MIP at Connectathon - Report 5 Mins - Alper Yegin Mobile IPv6 Discussion 30 Mins - Issues related to using IPSec for binding updates Jeff Schiller 10 Mins - Discussion of draft-bradner-pbk-frame-00.txt Jeff Schiller 5 Mins - Discussion 15 Mins Handoffs - Panel discussion 50 Mins - V6 handoff design team 20 Mins - V4 handoff design team 20 Mins - (draft-gwon-mobileip-l3mp-mipv4-00.txt) Youngjune Gwon 10 Mins Hierarchical Mobility Schemes 15 Mins - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) Hesham Soliman 8 Mins - Comparison/Discussion with draft-malinen-mobileip-regreg6-01.txt 7 Mins Dynamic configuration of Mobile hosts 15 Mins - Sandy Thuel draft-thuel-mobileip-tt-01.txt 8 Mins - Steve Glass draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins QoS Discussion 10 Mins - draft-chaskar-mobileip-qos-01.txt Hemant Chaskar WG Charter review 10 Mins From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:36:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29519 for ; Tue, 13 Mar 2001 17:36:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12578; Tue, 13 Mar 2001 14:36:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23290; Tue, 13 Mar 2001 14:36:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMZ7Im028866 for ; Tue, 13 Mar 2001 14:35:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DMZ6p4028865 for mobile-ip-dist; Tue, 13 Mar 2001 14:35:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMZ1Im028858 for ; Tue, 13 Mar 2001 14:35:02 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13407 for ; Tue, 13 Mar 2001 17:35:03 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01651 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 17:35:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMQWIm028829 for ; Tue, 13 Mar 2001 14:26:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20335 for ; Tue, 13 Mar 2001 14:26:33 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19036 for ; Tue, 13 Mar 2001 14:26:33 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA02752 for ; Tue, 13 Mar 2001 14:26:33 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE24711; Tue, 13 Mar 2001 14:26:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA08013; Tue, 13 Mar 2001 14:26:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15022.40599.881193.607356@thomasm-u1.cisco.com> Date: Tue, 13 Mar 2001 14:26:31 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0321365F@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321365F@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Can I ask why we are discussing solution space for QoS when the requirements aren't even known? Basavaraj.Patil@nokia.com writes: > > Final agenda for the Mobile IP WG meeting at IETF50 > > Thursday March 22nd - 9:00 AM - 11.30 AM > ---------------------------------------- > > Agenda bashing 5 Mins > WG Doc Status 5 Mins > > MIP at Connectathon - Report 5 Mins > - Alper Yegin > > Mobile IPv6 Discussion 30 Mins > - Issues related to using IPSec > for binding updates Jeff Schiller 10 Mins > - Discussion of draft-bradner-pbk-frame-00.txt > Jeff Schiller 5 Mins > - Discussion 15 Mins > > Handoffs - Panel discussion 50 Mins > - V6 handoff design team 20 Mins > - V4 handoff design team 20 Mins > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > Youngjune Gwon 10 Mins > > Hierarchical Mobility Schemes 15 Mins > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > Hesham Soliman 8 Mins > - Comparison/Discussion with > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > Dynamic configuration of Mobile hosts 15 Mins > - Sandy Thuel > draft-thuel-mobileip-tt-01.txt 8 Mins > - Steve Glass > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > QoS Discussion 10 Mins > - draft-chaskar-mobileip-qos-01.txt > Hemant Chaskar > > WG Charter review 10 Mins > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 17:53:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29754 for ; Tue, 13 Mar 2001 17:53:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21410; Tue, 13 Mar 2001 14:53:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26669; Tue, 13 Mar 2001 14:53:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMqJIm028977 for ; Tue, 13 Mar 2001 14:52:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DMqItC028976 for mobile-ip-dist; Tue, 13 Mar 2001 14:52:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMqDIm028969 for ; Tue, 13 Mar 2001 14:52:14 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16610 for ; Tue, 13 Mar 2001 17:52:15 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA02047 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 17:52:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMW7Im028845 for ; Tue, 13 Mar 2001 14:32:07 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07729 for ; Tue, 13 Mar 2001 14:32:08 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA02473 for ; Tue, 13 Mar 2001 14:32:06 -0800 (PST) Date: Tue, 13 Mar 2001 14:27:34 -0800 (PST) From: Pat Calhoun Subject: Re: [mobile-ip] next week To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hmmmm..... not sure how *that* happened. Obviously that was NOT meant for the list..... darn mailers. Please disregard my open invitation to the hundreds of people on this list. PatC > Can we do lunch of Wed? A bunch of folks want to talk about gen & AAA keys. > > PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 18:13:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29961 for ; Tue, 13 Mar 2001 18:13:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14046; Tue, 13 Mar 2001 15:12:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01525; Tue, 13 Mar 2001 15:12:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNB7Im029101 for ; Tue, 13 Mar 2001 15:11:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DNB7mW029100 for mobile-ip-dist; Tue, 13 Mar 2001 15:11:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNB2Im029093 for ; Tue, 13 Mar 2001 15:11:03 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19141 for ; Tue, 13 Mar 2001 18:11:03 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02410 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 18:11:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMmbIm028956 for ; Tue, 13 Mar 2001 14:48:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25930 for ; Tue, 13 Mar 2001 14:48:39 -0800 (PST) Received: from web3102.mail.yahoo.com (web3102.mail.yahoo.com [204.71.202.187]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA23866 for ; Tue, 13 Mar 2001 14:48:38 -0800 (PST) Message-ID: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Received: from [216.98.102.225] by web3102.mail.yahoo.com; Tue, 13 Mar 2001 14:48:37 PST Date: Tue, 13 Mar 2001 14:48:37 -0800 (PST) From: Guangrui Fu Subject: [mobile-ip] Mobile IP implementation for FreeBSD To: mobile-ip , freebsd-net , freebsd-mobile MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I'm looking for open-sourced Mobile IP implementation on FreeBSD. Could anyone please give me some information? Many thanks, Guangrui __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 18:26:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00096 for ; Tue, 13 Mar 2001 18:26:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24593; Tue, 13 Mar 2001 15:26:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04730; Tue, 13 Mar 2001 15:26:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNOrIm029179 for ; Tue, 13 Mar 2001 15:24:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DNOqgx029178 for mobile-ip-dist; Tue, 13 Mar 2001 15:24:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNOlIm029171 for ; Tue, 13 Mar 2001 15:24:48 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11054 for ; Tue, 13 Mar 2001 18:24:48 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04477 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 18:24:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMsPIm028987 for ; Tue, 13 Mar 2001 14:54:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04771 for ; Tue, 13 Mar 2001 14:54:26 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17692 for ; Tue, 13 Mar 2001 15:54:25 -0700 (MST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA21565 for ; Tue, 13 Mar 2001 16:54:24 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f2DMsNV26239 for ; Tue, 13 Mar 2001 16:54:23 -0600 (CST) Message-ID: <3AAE96F9.BEFBC9EC@usa.alcatel.com> Date: Tue, 13 Mar 2001 16:54:01 -0500 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321365F@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Raj, Is there any possiblity of moving the handoff drafts to the Seamoby WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO researchers? Regards, Basavaraj.Patil@nokia.com wrote: > Final agenda for the Mobile IP WG meeting at IETF50 > > > > Handoffs - Panel discussion 50 Mins > - V6 handoff design team 20 Mins > - V4 handoff design team 20 Mins > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > Youngjune Gwon 10 Mins -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 18:33:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00186 for ; Tue, 13 Mar 2001 18:33:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07766; Tue, 13 Mar 2001 15:33:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08081; Tue, 13 Mar 2001 15:33:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNVpIm029242 for ; Tue, 13 Mar 2001 15:31:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2DNVoXv029241 for mobile-ip-dist; Tue, 13 Mar 2001 15:31:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNVjIm029234 for ; Tue, 13 Mar 2001 15:31:46 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22460 for ; Tue, 13 Mar 2001 18:31:44 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA06418 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 18:31:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DMt6Im029009 for ; Tue, 13 Mar 2001 14:55:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27046 for ; Tue, 13 Mar 2001 14:55:07 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15341 for ; Tue, 13 Mar 2001 14:55:03 -0800 (PST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2DMqIi27308 for ; Tue, 13 Mar 2001 16:52:33 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f2DMpZt00860 for ; Tue, 13 Mar 2001 16:51:35 -0600 (CST) Received: from LMC37.lmc.ericsson.se (lmc51.lmc.ericsson.se [142.133.16.191]) by noah.lmc.ericsson.se (8.9.2/8.9.2) with ESMTP id RAA29453 for ; Tue, 13 Mar 2001 17:51:21 -0500 (EST) Received: by lmc37.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 17:51:20 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC72CC97@lmc37.lmc.ericsson.se> From: "Youcef Dahmane (LMC)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] unsubscribe Date: Tue, 13 Mar 2001 17:51:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: unsubscribe From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 19:02:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00517 for ; Tue, 13 Mar 2001 19:02:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18952; Tue, 13 Mar 2001 16:01:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15034; Tue, 13 Mar 2001 16:01:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E00TIm029480 for ; Tue, 13 Mar 2001 16:00:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E00SZX029479 for mobile-ip-dist; Tue, 13 Mar 2001 16:00:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E00KIm029472 for ; Tue, 13 Mar 2001 16:00:24 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25723 for ; Tue, 13 Mar 2001 19:00:21 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA07044 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 19:00:26 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNCIIm029103 for ; Tue, 13 Mar 2001 15:12:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16573 for ; Tue, 13 Mar 2001 15:12:19 -0800 (PST) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13327 for ; Tue, 13 Mar 2001 15:12:19 -0800 (PST) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA01031 for ; Tue, 13 Mar 2001 18:12:18 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA00984 for ; Tue, 13 Mar 2001 18:12:13 -0500 (EST) Received: by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA24555; Tue, 13 Mar 2001 17:12:12 -0600 (CST) To: mobile-ip@sunroof.eng.sun.com Received: from rjmarkspc by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA24546; Tue, 13 Mar 2001 17:12:11 -0600 (CST) From: "Robert J Marks" Original-To: Subject: RE: [mobile-ip] next week Date: Tue, 13 Mar 2001 17:11:28 -0600 Message-ID: <002801c0ac13$04f07f00$06868318@ce.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Once again, it is proven... There ain't no such thing as a free lunch Bob Pat Calhoun wrote: > > hmmmm..... not sure how *that* happened. Obviously that was > NOT meant for the > list..... darn mailers. > > Please disregard my open invitation to the hundreds of people > on this list. > > PatC > > Can we do lunch of Wed? A bunch of folks want to talk about > gen & AAA keys. > > > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 19:08:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00608 for ; Tue, 13 Mar 2001 19:08:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23312; Tue, 13 Mar 2001 16:08:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20654; Tue, 13 Mar 2001 16:07:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E06MIm029612 for ; Tue, 13 Mar 2001 16:06:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E06Lea029611 for mobile-ip-dist; Tue, 13 Mar 2001 16:06:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E069Im029601 for ; Tue, 13 Mar 2001 16:06:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15823 for ; Tue, 13 Mar 2001 19:06:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA07169 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 19:06:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNaUIm029358 for ; Tue, 13 Mar 2001 15:36:30 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08856 for ; Tue, 13 Mar 2001 15:36:31 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA03825 for ; Tue, 13 Mar 2001 15:36:29 -0800 (PST) Date: Tue, 13 Mar 2001 15:31:56 -0800 (PST) From: Pat Calhoun Subject: [mobile-ip] New list behavior To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <85AA7486A2C1D411BCA20000F8073E43017E5461@crchy271.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I finally realized why my e-mail was sent to the list. The new list (since it has moved) has the list as the Reply-To address, where lists are typically configured to keep the author of the e-mail in the Reply-To. Could we default back to the "normal" mode. I am quite certain that I am not the last to get caught (and embarassed :) PatC From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 13 19:17:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00770 for ; Tue, 13 Mar 2001 19:17:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00029; Tue, 13 Mar 2001 16:17:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16706; Tue, 13 Mar 2001 16:17:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E0G3Im029725 for ; Tue, 13 Mar 2001 16:16:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2E0G2DE029724 for mobile-ip-dist; Tue, 13 Mar 2001 16:16:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E0FvIm029717 for ; Tue, 13 Mar 2001 16:15:58 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17009 for ; Tue, 13 Mar 2001 19:15:58 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA07359 for mobile-ip@sunroof.eng.sun.com; Tue, 13 Mar 2001 19:16:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2DNbWIm029375 for ; Tue, 13 Mar 2001 15:37:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09036 for ; Tue, 13 Mar 2001 15:37:32 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01859 for ; Tue, 13 Mar 2001 15:37:32 -0800 (PST) Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f2DNgoO22373 for ; Tue, 13 Mar 2001 15:42:50 -0800 (PST) Date: Tue, 13 Mar 2001 15:42:50 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 In-Reply-To: <3AAE96F9.BEFBC9EC@usa.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Basavaraj, Can I ask your intention of requesting our presentation moving to Seamoby? Youngjune Gwon DoCoMo USA Labs On Tue, 13 Mar 2001, Behcet Sarikaya wrote: > Hi Raj, > Is there any possiblity of moving the handoff drafts to the Seamoby > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > researchers? > > Regards, > > Basavaraj.Patil@nokia.com wrote: > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Handoffs - Panel discussion 50 Mins > > - V6 handoff design team 20 Mins > > - V4 handoff design team 20 Mins > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > Youngjune Gwon 10 Mins > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 12:08:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28258 for ; Wed, 14 Mar 2001 12:08:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18647; Wed, 14 Mar 2001 09:08:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22370; Wed, 14 Mar 2001 09:08:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EH6kIm001419 for ; Wed, 14 Mar 2001 09:06:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EH6jiC001418 for mobile-ip-dist; Wed, 14 Mar 2001 09:06:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EH6eIm001411 for ; Wed, 14 Mar 2001 09:06:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22931 for ; Wed, 14 Mar 2001 12:06:37 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA26788 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 12:06:42 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2E0fUIm029829 for ; Tue, 13 Mar 2001 16:41:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21959 for ; Tue, 13 Mar 2001 16:41:31 -0800 (PST) From: rajeev.koodli@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16399 for ; Tue, 13 Mar 2001 17:41:30 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2E0fVg27146 for ; Tue, 13 Mar 2001 18:41:31 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Mar 2001 18:41:29 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 18:41:29 -0600 Message-ID: To: mobile-ip@sunroof.eng.sun.com Cc: rajeev.koodli@nokia.com, Charles.Perkins@nokia.com Subject: [mobile-ip] An analysis of the fastv6 draft. Date: Tue, 13 Mar 2001 18:41:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0AC1F.81BD62D0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0AC1F.81BD62D0 Content-Type: text/plain; charset="iso-8859-1" > Hello George, and fellow MIPv6 folks, > > I have done a simple analysis of the design team's fastv6 draft. I may > have missed something in the draft. If so, I would be happy to know it. I > would appreciate your comments. > > Regards, > > -Rajeev > > > > <> > > > - Rajeev.Koodli@nokia.com > > Nokia Research Center > 313 Fairchild Drive > Mountain View, CA 94043 > +1 650 625 2359 > > ------_=_NextPart_000_01C0AC1F.81BD62D0 Content-Type: text/plain; name="fastv6-comments.txt" Content-Disposition: attachment; filename="fastv6-comments.txt" Content-Transfer-Encoding: quoted-printable Baseline Scenario for optimization ------------------------------------------- The key observation is that the IP layer signaling should overlap with = Layer 2=20 establishment delay in order for IP fast handover signaling delay to = approch zero.=20 There is general agreement on this. So, going with this observation, = the following scenario best captures the _general_ case for fast handovers. (RTT/2)-air | =20 V <--------> <--L2-est-delay--> <--- RTT-air----> -----X--------X----X----X------------X---X---------------X-------> ^ ^ ^ ^ ^ ^ ^ =20 | | | | | | | PAR sends | | PAR receives | | MN receives = BAck, can use new-CoA ProxyRtAdv, | | HAck | | HI | | | | | MN transmitts BU, | |=20 | leaves PAR | | | | | MN receives | | ProxyRtAdv New L2 | established | with NAR | | | MN sends NA 1. PAR sends ProxyRtAdv, and sends HI messages to NAR. 2. MN receives ProxyRtAdv, forms a BU, transmitts BU and leaves PAR = immediately.=20 3. A delay corresponding to "L2-establishment delay" elapses, during = which the MN attempts to establish a new link with NAR. Some time during this = period, BU reaches PAR. HAck could reach PAR even before PAR receives BU, but it is = sufficient to note that it should reach PAR before "L2-establishment delay" = expires.=20 4. MN attaches to NAR, sends NA, receives BAck as a confirmation to use = new-CoA. The MN can send and receive packets using new-CoA. A deduction from the preceding discussion is that if a MN has to wait = at PAR to receive a BAck, it would contribute an additional delay of at least = RTT/2=20 over the air interface. This is because only after the MN terminates = its current=20 L2 with PAR (after receiving BAck) that it would initiate L2 = establishment with NAR.=20 Thus, in the general case, it should be observed that the MN cannot initiate L2 establishment with NAR until it relinquishes = its current L2 with PAR. This scenario is the one for which we need to optimize the overlapping of fast handover signaling with L2 delays. The scenario = in which the MN can initiate L2 establishment with NAR while still being attached to = PAR is a speacial case in which L2 initiation epoch with NAR _preceeds_ L2 = termination epoch=20 with PAR. In the general case, the two epochs are the same or the L2 = termination epoch with PAR happens before L2 initiation epoch with NAR.=20 Sources of deficiency --------------------- The current specification succeeds in trying to achive overlapping of=20 fast handover signaling with L2 establishment delays, with the = exception of the case when the MN ends up waiting at PAR to receive a BAck. Although the = specification does not require that the MN has to wait at PAR until it receives a = BAck, the above=20 general case can be stated explicitly in the draft to clearly depict = the scenario=20 needing optimization. Now, the sources of deficiency in the current specification. a> "single packet of failure" can eliminate the optimization gains, if = BAck is lost. Since the MN cannot use its new CoA until it receives a BAck, the BAck = message becomes the failure point. If this message is lost, the MN has to = retransmit the BU to PAR through NAR. What source address will the MN use in such a BU = ? It appears that the draft requires using new CoA for re-transmitting BU, = while=20 disallowing its use until a BAck is received. This is ambiguous.=20 Note that using old CoA is risky: ingress filtering could discard this Binding Update when there is no host route entry. = Furthermore, what address can the MN use in sending BU to its home agent ? It is clear = that without receiving BAck, the MN cannot determine what should be its new CoA. In = other words, performance of the protocol is undesirably skewed upon the succesfull = delivery=20 of a single packet that originates from the router the MN was attached = to prior to handover. b> "single bottleneck packet" delays the MN's ability to use new CoA = until it receives a BAck This follows from observation a> above. The MN may eventually receive a = BAck even when some earlier BAcks are lost through re-transmitting Binding = Updates.=20 All this while, PAR may be forwarding packets to the MN, either to new = CoA or=20 through a host route at NAR to old CoA. The draft does not specify what happens to these packets, nor does it explain what the MN behavior = should be if it receives those packets. Sugegsted Improvements (for a> and b>) -------------------------------------- Whereas it can be argued that one can devise mechanisms to specially = protect the BAck packet, what we propose here makes reception of a BAck packet = unimportant=20 from the point of being able to acquire a confirmed IP address for the = MN.=20 A simple observation reveals that the NAR could simply forward the = received packets=20 to the MN, either directly to new CoA or via host route to old CoA. The = MN can=20 determine by observing whether encapsulation is present (or not) in the = received=20 packets the type of CoA it is allowed to use.=20 If the packet is tunneled to new CoA, it means the MN can use new CoA, = if it is sent directly to old CoA, the MN cannot use its new CoA (and hence = resort to forming a new, topologically correct CoA).=20 This simple extension decouples the performance of the protocol from = the fallibility of a single packet failure. This addresses both a> and b> above. =20 In the following, we discuss the propagation of Neighbor Advertisement = message once the MN attaches to NAR. c> after L2 establishment with NAR, NA message could incorrectly update = the ND cache entries.=20 The MN sends a Neighbor Advertisement (NA) message after attaching to = NAR. What type of NA is sent is unclear. Typically, unsolicited NA messages are sent = to all-nodes multicast address to propagate new information to all the nodes. Since = there is no solicitation message described, we assume that unsolicited NA is sent. = In such a message,=20 the O-flag SHOULD be set to indicate that the receiving nodes should = override their cache entries with the information supplied in this message. The source IP = address in this=20 message is "an address assigned to the interface from which the = advertisement is sent [RFC 2461]", which means it could be a link-local address or a global = IPv6 address.=20 Anyway, there are two cases to consider here.=20 First, assuming that the NAR is proxying new CoA and has sent proxy NA = message(s) before the MN attaches to NAR, the NA sent by the MN correctly updates = ND cache entries in all the nodes. On the other hand, if the NAR was not succesful in = being able to=20 proxy the new CoA, e.g, due to the address being in use already, then = the NA message=20 sent by the MN would incorrectly update ND cache entries in all the = nodes. This latter situation must be avoided. Even though the draft attempts to ensure = that the MN does not use a new address until a confirmation is received (i.e., BAck = message approves the use of new CoA), the use of NA in this fashion contradicts the = objective.=20 Suggestion for handling scenario c> ----------------------------------- We propose to include a new 'T' bit in the NA message that the MN sends = after attaching to NAR. This bit MUST be set to one only by the MN undergoing fast = handover.=20 When the 'T' bit is set, it indicates that the sender is trying to = propagate its information to all the nodes on-link providing that its IP address is = tentative. The=20 nodes trying to propagate their new information when their IP addresses = are confirmed,=20 MUST NOT set the 'T' bit to one. Thus, if a node receives an NA message = with 'T' bit set to one, it MUST NOT override an already existing = corresponding ND cache entry.=20 If a node has a proxy ND cache entry, the presence of a 'T' bit set to = one indicates=20 that the node SHOULD override the entry if the entry corresponds to the = sender of the NA.=20 If a node is proxying an address that does not belong to the MN, the = 'T' bit would=20 disallow overriding the ND cache entry.=20 Note that this solution would not work when two MNs participating in = fast handovers=20 simultaneously try to acquire the same address and simultaneously try = to announce=20 their presence via NA messages both setting the 'T' bit.=20 Although the 'T' bit extension can be used in multicast NA messages as = well, limiting the message to unicast only to the NAR would ensure that other nodes = on-link would observe=20 transparency. Thus, we recommend that the proposed extension be carried = in a unicast=20 NA message to NAR. Once the MN confirms its new IP address, it may send = a mulicast NA message with the 'T' bit set to zero.=20 The following cases sumamrize the process. i> another node on the link is using new CoA.=20 Note that NAR has fairly recent information about this, since it = would have failed to defend the address for the MN. NAR MUST NOT overide its = cache and report the error with possible recourse back to the MN. ii> NAR is proxying the address for the MN. NAR SHOULD overide its cache entry with the information in the NA = message providing that the 'T' bit is set.=20 iii> NAR is proxying new CoA for some other node (off-link or on-link). Any node whose legitimate (meaning its address is known to be not = tentative) IP=20 address is currently being proxied by NAR, MUST NOT set the 'T' bit = when it sends=20 NA message. This allows NAR to override the entry when necessary. If = NAR receives=20 a NA message with 'T' bit set, the 'T' bit allows NAR to distinguish = that the request arrived from a node for which it is not proxying the address. =20 Whereas the above extension addresses the incorrect update to ND cache = entries when there is address conflict, it does not the address the problem that it = takes an=20 RTT-air delay before the MN can use a new IP address. The solution to = this problem in the next e-mail. ------_=_NextPart_000_01C0AC1F.81BD62D0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 12:35:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29209 for ; Wed, 14 Mar 2001 12:35:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20499; Wed, 14 Mar 2001 09:34:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13922; Wed, 14 Mar 2001 09:34:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHXPIm001524 for ; Wed, 14 Mar 2001 09:33:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EHXOlJ001523 for mobile-ip-dist; Wed, 14 Mar 2001 09:33:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHXJIm001516 for ; Wed, 14 Mar 2001 09:33:20 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06994 for ; Wed, 14 Mar 2001 12:33:18 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA27375 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 12:33:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EBMQIm000662 for ; Wed, 14 Mar 2001 03:22:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11701 for ; Wed, 14 Mar 2001 03:22:25 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-59.dsl.lsan03.pacbell.net [63.207.60.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15813 for ; Wed, 14 Mar 2001 04:22:24 -0700 (MST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C9A7D66B6C; Wed, 14 Mar 2001 03:22:19 -0800 (PST) Date: Wed, 14 Mar 2001 03:22:19 -0800 From: Kris Kennaway To: Guangrui Fu Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: [mobile-ip] Re: Mobile IP implementation for FreeBSD Message-ID: <20010314032219.A30923@mollari.cthul.hu> References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313224837.21080.qmail@web3102.mail.yahoo.com>; from guangruifu@yahoo.com on Tue, Mar 13, 2001 at 02:48:37PM -0800 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2001 at 02:48:37PM -0800, Guangrui Fu wrote: > Hi, >=20 > I'm looking for open-sourced Mobile IP implementation > on FreeBSD. Could anyone please give me some > information? KAME (www.kame.net) has an experimental implementation which will be integrated into FreeBSD at some point in the future once it's considered ready enough. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6r1RrWry0BWjoQKURAq+5AKDQhahBiMpxloTDQgsLF5jphJh34ACdEJIf 0nbm260/T/ZLfyu+IYWN4/4= =D/Zh -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 12:39:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29399 for ; Wed, 14 Mar 2001 12:39:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22863; Wed, 14 Mar 2001 09:39:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28977; Wed, 14 Mar 2001 09:39:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHbRIm001576 for ; Wed, 14 Mar 2001 09:37:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EHbRSK001575 for mobile-ip-dist; Wed, 14 Mar 2001 09:37:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHbMIm001568 for ; Wed, 14 Mar 2001 09:37:22 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07627 for ; Wed, 14 Mar 2001 12:37:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA27464 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 12:37:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ECMoIm000728 for ; Wed, 14 Mar 2001 04:22:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22440 for ; Wed, 14 Mar 2001 04:22:50 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12554 for ; Wed, 14 Mar 2001 04:22:48 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2ECMlC08963 for ; Wed, 14 Mar 2001 13:22:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 14 13:22:42 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 14 Mar 2001 13:24:26 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC4E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 13:22:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The handoff drafts are MIP WG drafts. Why would they move to SEAMOBY ??? I think the other draft you refer to from NTT DOCOMO is also relevant to the MIP work. Obviously the authors think so that's why it was submitted to MIP. Hesham > -----Original Message----- > From: Behcet Sarikaya [SMTP:behcet.sarikaya@usa.alcatel.com] > Sent: Wednesday, 14 March 2001 8:54 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 > > Hi Raj, > Is there any possiblity of moving the handoff drafts to the Seamoby > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > researchers? > > Regards, > > Basavaraj.Patil@nokia.com wrote: > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Handoffs - Panel discussion 50 Mins > > - V6 handoff design team 20 Mins > > - V4 handoff design team 20 Mins > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > Youngjune Gwon 10 Mins > > -- > Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 12:53:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29772 for ; Wed, 14 Mar 2001 12:53:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27403; Wed, 14 Mar 2001 09:48:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01298; Wed, 14 Mar 2001 09:48:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHkrIm001694 for ; Wed, 14 Mar 2001 09:46:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EHkrZV001693 for mobile-ip-dist; Wed, 14 Mar 2001 09:46:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHkmIm001686 for ; Wed, 14 Mar 2001 09:46:48 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09269 for ; Wed, 14 Mar 2001 12:46:47 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA27702 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 12:46:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ECohIm000819 for ; Wed, 14 Mar 2001 04:50:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17381 for ; Wed, 14 Mar 2001 04:50:42 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA19646 for ; Wed, 14 Mar 2001 05:50:41 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id VAA23800; Wed, 14 Mar 2001 21:50:32 +0900 (JST) To: Kris Kennaway cc: Guangrui Fu , mobile-ip , freebsd-net , freebsd-mobile In-reply-to: kris's message of Wed, 14 Mar 2001 03:22:19 PST. <20010314032219.A30923@mollari.cthul.hu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: [mobile-ip] Re: Mobile IP implementation for FreeBSD From: itojun@iijlab.net Date: Wed, 14 Mar 2001 21:50:32 +0900 Message-ID: <23798.984574232@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> I'm looking for open-sourced Mobile IP implementation >> on FreeBSD. Could anyone please give me some >> information? > >KAME (www.kame.net) has an experimental implementation which will be >integrated into FreeBSD at some point in the future once it's >considered ready enough. KAME does mobile-ip6 only. we don't do mobile-ip4. itojun From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 13:28:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00455 for ; Wed, 14 Mar 2001 13:28:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01159; Wed, 14 Mar 2001 10:28:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26243; Wed, 14 Mar 2001 10:28:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIQgIm001848 for ; Wed, 14 Mar 2001 10:26:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EIQfrO001847 for mobile-ip-dist; Wed, 14 Mar 2001 10:26:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIQaIm001840 for ; Wed, 14 Mar 2001 10:26:37 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15543 for ; Wed, 14 Mar 2001 13:26:36 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA28526 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 13:26:41 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EEEvIm000840 for ; Wed, 14 Mar 2001 06:14:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01513 for ; Wed, 14 Mar 2001 06:14:57 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28015 for ; Wed, 14 Mar 2001 07:14:56 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EEEqg18687 for ; Wed, 14 Mar 2001 08:14:57 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 08:14:45 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 08:14:44 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213667@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: behcet.sarikaya@usa.alcatel.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 08:14:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: No. -Basavaraj > -----Original Message----- > From: ext Behcet Sarikaya [mailto:behcet.sarikaya@usa.alcatel.com] > Sent: Tuesday, March 13, 2001 3:54 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG > meeting at IETF50 > > > Hi Raj, > Is there any possiblity of moving the handoff drafts to the Seamoby > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > researchers? > > Regards, > > Basavaraj.Patil@nokia.com wrote: > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Handoffs - Panel discussion 50 Mins > > - V6 handoff design team 20 Mins > > - V4 handoff design team 20 Mins > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > Youngjune Gwon 10 Mins > > -- > Behcet > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 13:43:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00994 for ; Wed, 14 Mar 2001 13:43:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24523; Wed, 14 Mar 2001 10:43:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29952; Wed, 14 Mar 2001 10:43:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIg2Im001984 for ; Wed, 14 Mar 2001 10:42:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EIg2E9001983 for mobile-ip-dist; Wed, 14 Mar 2001 10:42:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIfvIm001976 for ; Wed, 14 Mar 2001 10:41:57 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18212 for ; Wed, 14 Mar 2001 13:41:55 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA28859 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 13:42:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EEUfIm000853 for ; Wed, 14 Mar 2001 06:30:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09171 for ; Wed, 14 Mar 2001 06:30:41 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05655 for ; Wed, 14 Mar 2001 07:30:11 -0700 (MST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EEUBg20351 for ; Wed, 14 Mar 2001 08:30:11 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 08:30:09 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 08:30:08 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366B@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: claude.castelluccia@inrialpes.fr Subject: RE: [mobile-ip] -Hierarchical schemes- Date: Wed, 14 Mar 2001 08:30:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC93.44D0D2C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AC93.44D0D2C0 Content-Type: text/plain; charset="iso-8859-1" > >Hello, >There will be a 20 mn "hierarchical Mobility Schemes" at the next >Mobile IP meeting. >What is the purpose / goal of this slot ? > In SanDiego, we did not have enough time to allow people to raise all their concerns about HMIPv6. This slot is intended to provide an update on the changes in the new version of the WG I-D and then open the floor for a discussion. >Should the authors of the different proposals prepare something for >this meeting? The only slide(s) we will have is one that shows the changes in the new version of the HMIPv6 I-D and nothing else. There is no intent to have another presentation of HMIPv6 or anything else. Not really. This slot is for discussion only. >Did I miss something? >thanks, > >Claude. > -Basavaraj >-- > >---------------------------------------- >Claude CASTELLUCCIA, INRIA Rhone-Alpes >ph: +33 4.76.61.52.15 (fax: 52.52) >http://www.inrialpes.fr/planete/ ------_=_NextPart_001_01C0AC93.44D0D2C0 Content-Type: text/html; charset="iso-8859-1"
>
>Hello,
>There will be a 20 mn "hierarchical Mobility Schemes" at the next
>Mobile IP meeting. 
>What is the purpose / goal of this slot ?
>
 
In SanDiego, we did not have enough time to allow people to raise all
their concerns about HMIPv6. This slot is intended to provide an
update on the changes in the new version of the WG I-D and then open
the floor for a discussion.
 
>Should the authors of the different proposals prepare something for
>this meeting? 
 
The only slide(s) we will have is one that shows the changes in the
new version of the HMIPv6 I-D and nothing else. There is no intent to
have another presentation of HMIPv6 or anything else.
Not really. This slot is for discussion only.
 
>Did I miss something?
>thanks,
>
>Claude.
>
 
-Basavaraj
 
>--
>
>----------------------------------------
>Claude CASTELLUCCIA, INRIA Rhone-Alpes 
>ph:  +33 4.76.61.52.15 (fax: 52.52)
>http://www.inrialpes.fr/planete/
 
------_=_NextPart_001_01C0AC93.44D0D2C0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 13:48:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01096 for ; Wed, 14 Mar 2001 13:48:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27029; Wed, 14 Mar 2001 10:47:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24475; Wed, 14 Mar 2001 10:47:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIkSIm002098 for ; Wed, 14 Mar 2001 10:46:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EIkRwH002097 for mobile-ip-dist; Wed, 14 Mar 2001 10:46:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIkMIm002087 for ; Wed, 14 Mar 2001 10:46:22 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12166 for ; Wed, 14 Mar 2001 13:46:21 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA28941 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 13:46:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EEtDIm000871 for ; Wed, 14 Mar 2001 06:55:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01301 for ; Wed, 14 Mar 2001 06:54:49 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21109 for ; Wed, 14 Mar 2001 06:54:49 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EEsog23608 for ; Wed, 14 Mar 2001 08:54:50 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 08:54:48 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 08:54:48 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366C@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 08:54:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Michael, > Can I ask why we are discussing solution space for QoS > when the requirements aren't even known? The requirements may not be explicitly stated as such. The requirements for QoS from a Mobile IP perspective are as follows: 1. If QoS has been established for a session between an MN and CN, how do you deal with it when the MN changes it's point of attachment, and as a result the path of the packet flow changes 2. What are the implications on QoS for a session w.r.t fast handoffs. 3. More? I am not sure. -Basavaraj > > Basavaraj.Patil@nokia.com writes: > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > Thursday March 22nd - 9:00 AM - 11.30 AM > > ---------------------------------------- > > > > Agenda bashing 5 Mins > > WG Doc Status 5 Mins > > > > MIP at Connectathon - Report 5 Mins > > - Alper Yegin > > > > Mobile IPv6 Discussion 30 Mins > > - Issues related to using IPSec > > for binding updates Jeff Schiller 10 Mins > > - Discussion of draft-bradner-pbk-frame-00.txt > > Jeff Schiller 5 Mins > > - Discussion 15 Mins > > > > Handoffs - Panel discussion 50 Mins > > - V6 handoff design team 20 Mins > > - V4 handoff design team 20 Mins > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > Youngjune Gwon 10 Mins > > > > Hierarchical Mobility Schemes 15 Mins > > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > > Hesham Soliman 8 Mins > > - Comparison/Discussion with > > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > > > Dynamic configuration of Mobile hosts 15 Mins > > - Sandy Thuel > > draft-thuel-mobileip-tt-01.txt 8 Mins > > - Steve Glass > > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > > > QoS Discussion 10 Mins > > - draft-chaskar-mobileip-qos-01.txt > > Hemant Chaskar > > > > WG Charter review 10 Mins > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 13:58:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01358 for ; Wed, 14 Mar 2001 13:58:04 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29161; Wed, 14 Mar 2001 10:57:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03052; Wed, 14 Mar 2001 10:57:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIuOIm002241 for ; Wed, 14 Mar 2001 10:56:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EIuOcw002239 for mobile-ip-dist; Wed, 14 Mar 2001 10:56:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIuHIm002225 for ; Wed, 14 Mar 2001 10:56:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20760 for ; Wed, 14 Mar 2001 13:56:16 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA29135 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 13:56:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFKaIm000900 for ; Wed, 14 Mar 2001 07:20:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04138 for ; Wed, 14 Mar 2001 07:20:36 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03469 for ; Wed, 14 Mar 2001 07:20:36 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA23526; Wed, 14 Mar 2001 09:20:35 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f2EFK7h17167; Wed, 14 Mar 2001 09:20:07 -0600 (CST) Message-ID: <3AAF8D29.6AE23004@usa.alcatel.com> Date: Wed, 14 Mar 2001 09:24:25 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 References: <7B5C0390ACE7D211BC9C0008C7EABA2B03213667@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > No. > > -Basavaraj > > > > Hi Raj, > > Is there any possiblity of moving the handoff drafts to the Seamoby > > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > > researchers? If someone has a draft on fast handover (s)he should submit it to Mobile IP WG, and if someone has a draft on seamless handover (s)he should submit it to Seamoby WG. Isn't confusing? Just asking. --behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 14:04:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01525 for ; Wed, 14 Mar 2001 14:04:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05620; Wed, 14 Mar 2001 11:04:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05125; Wed, 14 Mar 2001 11:04:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJ36Im002363 for ; Wed, 14 Mar 2001 11:03:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EJ35NZ002362 for mobile-ip-dist; Wed, 14 Mar 2001 11:03:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJ30Im002355 for ; Wed, 14 Mar 2001 11:03:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22063 for ; Wed, 14 Mar 2001 14:03:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA29272 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 14:03:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EFi0Im001001 for ; Wed, 14 Mar 2001 07:44:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17987 for ; Wed, 14 Mar 2001 07:44:00 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20441 for ; Wed, 14 Mar 2001 07:44:00 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 14 Mar 2001 09:19:58 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 09:19:56 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301854726@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 09:19:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC9A.38CE5040" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AC9A.38CE5040 Content-Type: text/plain; charset="iso-8859-1" Were representatives from DoCoMo excluded from the HO DTs? It appears to me that this draft is trying to extend and use the MIP protocol. Wouldn't it make sense for it to be discussed in the MIP WG? -----Original Message----- From: Youngjune Lee Gwon [mailto:gyj@dcl.docomo-usa.com] Sent: Tuesday, March 13, 2001 5:43 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Basavaraj, Can I ask your intention of requesting our presentation moving to Seamoby? Youngjune Gwon DoCoMo USA Labs On Tue, 13 Mar 2001, Behcet Sarikaya wrote: > Hi Raj, > Is there any possiblity of moving the handoff drafts to the Seamoby > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > researchers? > > Regards, > > Basavaraj.Patil@nokia.com wrote: > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Handoffs - Panel discussion 50 Mins > > - V6 handoff design team 20 Mins > > - V4 handoff design team 20 Mins > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > Youngjune Gwon 10 Mins > > -- > Behcet > ------_=_NextPart_001_01C0AC9A.38CE5040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at = IETF50

Were representatives from DoCoMo excluded from the HO = DTs? It appears to me that this draft is trying to extend and use the = MIP protocol. Wouldn't it make sense for it to be discussed in the MIP = WG?

-----Original Message-----
From: Youngjune Lee Gwon [mailto:gyj@dcl.docomo-usa.com= ]
Sent: Tuesday, March 13, 2001 5:43 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Final Agenda for Mobile IP = WG meeting at IETF50


Basavaraj,

Can I ask your intention of requesting our = presentation moving to Seamoby?

Youngjune Gwon
DoCoMo USA Labs

On Tue, 13 Mar 2001, Behcet Sarikaya wrote:

> Hi Raj,
>   Is there any possiblity of moving = the handoff drafts to the Seamoby
> WG, as per Pat's recent comments on a draft = submitted by NTT DOCOMO
> researchers?
>
> Regards,
>
> Basavaraj.Patil@nokia.com wrote:
>
> > Final agenda for the Mobile IP WG meeting = at IETF50
> >
> >
> >
> > Handoffs - Panel = discussion          &n= bsp;          50 = Mins
> >  - V6 handoff design team 20 = Mins
> >  - V4 handoff design team 20 = Mins
> >  - = (draft-gwon-mobileip-l3mp-mipv4-00.txt)
> >    Youngjune Gwon 10 = Mins
>
> --
> Behcet
>

------_=_NextPart_001_01C0AC9A.38CE5040-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 14:15:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01721 for ; Wed, 14 Mar 2001 14:15:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14114; Wed, 14 Mar 2001 11:15:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08566; Wed, 14 Mar 2001 11:15:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJE8Im002492 for ; Wed, 14 Mar 2001 11:14:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EJE7W0002491 for mobile-ip-dist; Wed, 14 Mar 2001 11:14:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJE3Im002484 for ; Wed, 14 Mar 2001 11:14:03 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17755 for ; Wed, 14 Mar 2001 14:14:02 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA29489 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 14:14:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHkVIm001672 for ; Wed, 14 Mar 2001 09:46:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00819 for ; Wed, 14 Mar 2001 09:46:31 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07809 for ; Wed, 14 Mar 2001 10:46:29 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2EHkRC05448 for ; Wed, 14 Mar 2001 18:46:27 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 14 18:49:33 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 14 Mar 2001 18:42:28 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC5D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Wed, 14 Mar 2001 18:46:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Glenn, > I hope my response to Charlie's query clears up what I was trying to say technically. > => Yes it did and it gave me a chance to mention my concerns. > I am hoping that we can all work together to come up with the best solution possible as a team; however, my stupid euphamisms have probably reduced any chances of that now. > => Not at all. > There are merits to both RR and HMIP. As we move forward, we should try to get the best of both worlds. > => Absolutely, I think we've put in 99% (leaving 1% just in case) of the comments e received. You can see that we received lots of comments by reading the ACK section :) So we welcome any suggestions that will improve the draft's quality. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 14:22:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01846 for ; Wed, 14 Mar 2001 14:22:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13312; Wed, 14 Mar 2001 11:21:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25008; Wed, 14 Mar 2001 11:21:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJJPIm002602 for ; Wed, 14 Mar 2001 11:19:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EJJP7r002601 for mobile-ip-dist; Wed, 14 Mar 2001 11:19:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJJFIm002591 for ; Wed, 14 Mar 2001 11:19:20 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24666 for ; Wed, 14 Mar 2001 14:19:15 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA29591 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 14:19:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHpGIm001759 for ; Wed, 14 Mar 2001 09:51:16 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10955 for ; Wed, 14 Mar 2001 09:51:16 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA23690 for ; Wed, 14 Mar 2001 09:51:14 -0800 (PST) Date: Wed, 14 Mar 2001 09:46:40 -0800 (PST) From: Pat Calhoun Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF7546013DBC4E@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The handoff drafts are MIP WG drafts. Why would they move > to SEAMOBY ??? To be clear, the I-D I was talking about had to do with L3 handoff signals. I do not see why this is a MIP issue. Fast handoffs (using MIP) do belong in MIP. > > I think the other draft you refer to from NTT DOCOMO is also > relevant to the MIP work. Obviously the authors think so > that's why it was submitted to MIP. Right, as has many other I-Ds that are not necessarily of relevance to the WG, and not in charter. Just because someone believes an I-D belongs in a WG doesn't mean it does. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 15:55:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04047 for ; Wed, 14 Mar 2001 15:55:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17321; Wed, 14 Mar 2001 12:55:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11707; Wed, 14 Mar 2001 12:55:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EKrFIm002944 for ; Wed, 14 Mar 2001 12:53:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EKrEdX002943 for mobile-ip-dist; Wed, 14 Mar 2001 12:53:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EKr5Im002936 for ; Wed, 14 Mar 2001 12:53:05 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15175 for ; Wed, 14 Mar 2001 15:53:03 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA01447 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 15:53:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EHpGIm001759 for ; Wed, 14 Mar 2001 09:51:16 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10955 for ; Wed, 14 Mar 2001 09:51:16 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA23690 for ; Wed, 14 Mar 2001 09:51:14 -0800 (PST) Date: Wed, 14 Mar 2001 09:46:40 -0800 (PST) From: Pat Calhoun Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF7546013DBC4E@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The handoff drafts are MIP WG drafts. Why would they move > to SEAMOBY ??? To be clear, the I-D I was talking about had to do with L3 handoff signals. I do not see why this is a MIP issue. Fast handoffs (using MIP) do belong in MIP. > > I think the other draft you refer to from NTT DOCOMO is also > relevant to the MIP work. Obviously the authors think so > that's why it was submitted to MIP. Right, as has many other I-Ds that are not necessarily of relevance to the WG, and not in charter. Just because someone believes an I-D belongs in a WG doesn't mean it does. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 16:17:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04567 for ; Wed, 14 Mar 2001 16:17:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03880; Wed, 14 Mar 2001 13:17:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08899; Wed, 14 Mar 2001 13:17:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELE5Im003023 for ; Wed, 14 Mar 2001 13:14:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ELE4Pw003022 for mobile-ip-dist; Wed, 14 Mar 2001 13:14:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELDxIm003015 for ; Wed, 14 Mar 2001 13:14:00 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11786 for ; Wed, 14 Mar 2001 16:13:55 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA01849 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 16:14:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIL2Im001826 for ; Wed, 14 Mar 2001 10:21:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17364 for ; Wed, 14 Mar 2001 10:21:02 -0800 (PST) Received: from mymlan.lifix.fi (mymlan.lifix.fi [195.197.211.98]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04593 for ; Wed, 14 Mar 2001 10:20:56 -0800 (PST) Received: from ban by mymlan.lifix.fi with local id 14dF1v-0004t1-00; Wed, 14 Mar 2001 19:25:47 +0200 Date: Wed, 14 Mar 2001 19:25:47 +0200 From: Bjorn Andersson To: Guangrui Fu Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: [mobile-ip] Re: Mobile IP implementation for FreeBSD Message-ID: <20010314192547.B18619@mymlan.lifix.fi> Mail-Followup-To: Bjorn Andersson , Guangrui Fu , mobile-ip , freebsd-net , freebsd-mobile References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313224837.21080.qmail@web3102.mail.yahoo.com>; from guangruifu@yahoo.com on Tue, Mar 13, 2001 at 02:48:37PM -0800 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id NAA03880 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04567 On Tue, Mar 13 2001, at 14:48:37 -0800, Guangrui Fu wrote: > I'm looking for open-sourced Mobile IP implementation > on FreeBSD. Could anyone please give me some > information? Check out the Monarch Project: http://www.monarch.cs.cmu.edu/ Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 16:26:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04741 for ; Wed, 14 Mar 2001 16:26:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17565; Wed, 14 Mar 2001 13:26:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10781; Wed, 14 Mar 2001 13:26:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELOgIm003105 for ; Wed, 14 Mar 2001 13:24:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ELOfCG003104 for mobile-ip-dist; Wed, 14 Mar 2001 13:24:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELOZIm003094 for ; Wed, 14 Mar 2001 13:24:35 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13816 for ; Wed, 14 Mar 2001 16:24:34 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA02068 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 16:24:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EIvmIm002266 for ; Wed, 14 Mar 2001 10:57:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03686 for ; Wed, 14 Mar 2001 10:57:47 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27617 for ; Wed, 14 Mar 2001 10:57:44 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 14 Mar 2001 09:10:47 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 09:15:51 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E430185471B@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Wed, 14 Mar 2001 09:15:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC99.A6078BA0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AC99.A6078BA0 Content-Type: text/plain; charset="iso-8859-1" Sorry Charlie but I'm not that sorry. If four chairs are each missing one leg, they both fall down irrespective of which particular leg they are missing. The leg missing from your proposal is single point of failure and there are already proposed solutions that have the same leg missing and yet require none or fewer changes to the protocol. While it is not for me to decide, it appears to me that it would be an injustice to accept it in light of these other solutions. Routing policy and configuration can also guarantee arbitrary point with these other solutions. I also believe your solution conflicts with current technologies for controlling routing policy. Thanks, Glenn -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, March 13, 2001 10:58 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: mobile-ip@sunroof.eng.sun.com; Basavaraj Patil (NTC/Dallas); Phil Roberts Subject: [mobile-ip] Re: Comments on Regional Registration Hello Glenn, Thanks for your notes. I just have one question below, and then a comment about IPv4 regional registration. Glenn Morrow wrote: > Anycast is exactly right, because what the mobile node "wants" > is for the crossover router to take the appropriate action, > without the mobile node knowing which router it is. > > Anycast even helps to preserve the connectionless nature which > we would like to preserve for regionalized mobility handling. > > GM> I agree, I support anycast too. To vilify a solution which employs > it as magic was wrong and I apologize. No need for apology, but I wanted to point out that this particular use of anycast is easy to implement, assuming that one's IPv6 implementation supports anycast at all. I don't know whether we ought to publish the algorithmic steps, but it seems that most people who have coded network protocols could figure out how to make this particular anycast idea work. Thus I am claiming that we are not invoking magic here -- just to be clear. And, to be equally clear, I strongly suspect that you did not intend in your sentence to classify our anycast solution to be counted among those in the "magic" bin. My other comment was that I hope we can forward with the IPv4 regional registration draft. That protocol works, has implementations, has been through last call, and has been reissued with comments responding to last call. It is a very nice protocol (o.k. I am biased). I hope that it won't be neglected because of desires for a more robust and well-controlled host route dissemination mechanism. Regards, Charlie P. ------_=_NextPart_001_01C0AC99.A6078BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: Comments on Regional Registration

Sorry Charlie but I'm not that sorry.

If four chairs are each missing one leg, they both = fall down irrespective of which particular leg they are missing.

The leg missing from your proposal is single point of = failure and there are already proposed solutions that have the same leg = missing and yet require none or fewer changes to the = protocol.

While it is not for me to decide, it appears to me = that it would be an injustice to accept it in light of these other = solutions.

Routing policy and configuration can also guarantee = arbitrary point with these other solutions. I also believe your = solution conflicts with current technologies for controlling routing = policy.

Thanks,

Glenn

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, March 13, 2001 10:58 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: mobile-ip@sunroof.eng.sun.com; Basavaraj Patil = (NTC/Dallas); Phil
Roberts
Subject: [mobile-ip] Re: Comments on Regional = Registration


Hello Glenn,

Thanks for your notes.  I just have one question = below,
and then a comment about IPv4 regional = registration.

Glenn Morrow wrote:

> Anycast is exactly right, because what the = mobile node "wants"
> is for the crossover router to take the = appropriate action,
> without the mobile node knowing which router it = is.
>
> Anycast even helps to preserve the = connectionless nature which
> we would like to preserve for regionalized = mobility handling.
>
> GM> I agree, I support anycast too. To = vilify a solution which employs
> it as magic was wrong and I apologize.

No need for apology, but I wanted to point out that = this particular
use of anycast is easy to implement, assuming that = one's IPv6
implementation supports anycast at all.  I = don't know whether
we ought to publish the algorithmic steps, but it = seems that most
people who have coded network protocols could figure = out how
to make this particular anycast idea work.  = Thus I am claiming
that we are not invoking magic here -- just to be = clear.  And, to
be equally clear, I strongly suspect that you did = not intend in your
sentence to classify our anycast solution to be = counted among
those in the "magic" bin.

My other comment was that I hope we can forward with = the
IPv4 regional registration draft.  That = protocol works, has
implementations, has been through last call, and has = been
reissued with comments responding to last call. = It is a very
nice protocol (o.k. I am biased).  I hope that = it won't
be neglected because of desires for a more robust = and
well-controlled host route dissemination = mechanism.


Regards,
Charlie P.


------_=_NextPart_001_01C0AC99.A6078BA0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 16:41:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05002 for ; Wed, 14 Mar 2001 16:41:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14395; Wed, 14 Mar 2001 13:41:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29633; Wed, 14 Mar 2001 13:41:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELdDIm003204 for ; Wed, 14 Mar 2001 13:39:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ELdCkZ003203 for mobile-ip-dist; Wed, 14 Mar 2001 13:39:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELd7Im003196 for ; Wed, 14 Mar 2001 13:39:08 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16060 for ; Wed, 14 Mar 2001 16:39:06 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA02358 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 16:39:12 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJ4mIm002387 for ; Wed, 14 Mar 2001 11:04:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05664 for ; Wed, 14 Mar 2001 11:04:48 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05183 for ; Wed, 14 Mar 2001 11:04:47 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07749; Wed, 14 Mar 2001 11:05:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE41254; Wed, 14 Mar 2001 11:04:43 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08280; Wed, 14 Mar 2001 11:04:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.49355.693665.413637@thomasm-u1.cisco.com> Date: Wed, 14 Mar 2001 11:04:43 -0800 (PST) To: Cc: mobile-ip@sunroof.eng.sun.com, mat@cisco.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366C@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366C@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I understand that, but this draft in particular is positing a completely different way to perform signaled QoS admission control which has global implications: CN's and interior routers would need to implement this as well. As you may know, I've spent a fair amount of time trying to figure out what the implications of our current signaled QoS admission control scheme -- RSVP -- are with MIP and I can tell you as a very quick summary that positing a completely different signaling scheme is *far* too premature. It would be much, much better to analyze what the current state of affairs is and compare that to MIP requirements before we decide whether a specific solution is in order. In fact, even if it is, I cannot imagine that the MIP WG is the right place to pursue this. I have volunteered to discuss my analysis (draft- thomas-seamoby-rsvp-analysis-00) and will do so again at this point, but even if you don't take me up on this, I cannot see what will be productive about discussing this draft for the second IETF in a row: all of the same arguments of scope and wholesale reinvention apply. Mike Basavaraj.Patil@nokia.com writes: > > Michael, > > > Can I ask why we are discussing solution space for QoS > > when the requirements aren't even known? > > The requirements may not be explicitly stated as such. The requirements > for QoS from a Mobile IP perspective are as follows: > > 1. If QoS has been established for a session between an MN and CN, how do > you > deal with it when the MN changes it's point of attachment, and as a > result the path of the > packet flow changes > 2. What are the implications on QoS for a session w.r.t fast handoffs. > 3. More? I am not sure. > > -Basavaraj > > > > > Basavaraj.Patil@nokia.com writes: > > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > Thursday March 22nd - 9:00 AM - 11.30 AM > > > ---------------------------------------- > > > > > > Agenda bashing 5 Mins > > > WG Doc Status 5 Mins > > > > > > MIP at Connectathon - Report 5 Mins > > > - Alper Yegin > > > > > > Mobile IPv6 Discussion 30 Mins > > > - Issues related to using IPSec > > > for binding updates Jeff Schiller 10 Mins > > > - Discussion of draft-bradner-pbk-frame-00.txt > > > Jeff Schiller 5 Mins > > > - Discussion 15 Mins > > > > > > Handoffs - Panel discussion 50 Mins > > > - V6 handoff design team 20 Mins > > > - V4 handoff design team 20 Mins > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > Youngjune Gwon 10 Mins > > > > > > Hierarchical Mobility Schemes 15 Mins > > > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > > > Hesham Soliman 8 Mins > > > - Comparison/Discussion with > > > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > > > > > Dynamic configuration of Mobile hosts 15 Mins > > > - Sandy Thuel > > > draft-thuel-mobileip-tt-01.txt 8 Mins > > > - Steve Glass > > > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > > > > > QoS Discussion 10 Mins > > > - draft-chaskar-mobileip-qos-01.txt > > > Hemant Chaskar > > > > > > WG Charter review 10 Mins > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 17:18:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05589 for ; Wed, 14 Mar 2001 17:18:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29902; Wed, 14 Mar 2001 14:18:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03000; Wed, 14 Mar 2001 14:18:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMH1Im003345 for ; Wed, 14 Mar 2001 14:17:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EMH1IO003344 for mobile-ip-dist; Wed, 14 Mar 2001 14:17:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMGuIm003337 for ; Wed, 14 Mar 2001 14:16:56 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23108 for ; Wed, 14 Mar 2001 17:16:53 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA03089 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 17:16:59 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EJxrIm002877 for ; Wed, 14 Mar 2001 11:59:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21874 for ; Wed, 14 Mar 2001 11:59:51 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26580 for ; Wed, 14 Mar 2001 11:59:41 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EJxWg16283 for ; Wed, 14 Mar 2001 13:59:43 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 13:59:30 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 13:59:30 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: gyj@dcl.docomo-usa.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 13:59:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I never suggested that your presentation be moved to Seamoby! -Basavaraj > -----Original Message----- > From: ext Youngjune Lee Gwon [mailto:gyj@dcl.docomo-usa.com] > Sent: Tuesday, March 13, 2001 5:43 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG > meeting at IETF50 > > > Basavaraj, > > Can I ask your intention of requesting our presentation > moving to Seamoby? > > Youngjune Gwon > DoCoMo USA Labs > > On Tue, 13 Mar 2001, Behcet Sarikaya wrote: > > > Hi Raj, > > Is there any possiblity of moving the handoff drafts to > the Seamoby > > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > > researchers? > > > > Regards, > > > > Basavaraj.Patil@nokia.com wrote: > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > > > > > Handoffs - Panel discussion 50 Mins > > > - V6 handoff design team 20 Mins > > > - V4 handoff design team 20 Mins > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > Youngjune Gwon 10 Mins > > > > -- > > Behcet > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 17:57:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06069 for ; Wed, 14 Mar 2001 17:57:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16780; Wed, 14 Mar 2001 14:56:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11782; Wed, 14 Mar 2001 14:56:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMtbIm003475 for ; Wed, 14 Mar 2001 14:55:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2EMtbmQ003474 for mobile-ip-dist; Wed, 14 Mar 2001 14:55:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMtWIm003467 for ; Wed, 14 Mar 2001 14:55:32 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06126 for ; Wed, 14 Mar 2001 17:55:32 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA03843 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 17:55:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EKiVIm002923 for ; Wed, 14 Mar 2001 12:44:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15895 for ; Wed, 14 Mar 2001 12:44:30 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04599 for ; Wed, 14 Mar 2001 13:44:28 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2EKiQC04474 for ; Wed, 14 Mar 2001 21:44:26 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 14 21:46:08 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 14 Mar 2001 21:44:25 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC64@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Wed, 14 Mar 2001 21:44:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I think the other draft you refer to from NTT DOCOMO is also > > relevant to the MIP work. Obviously the authors think so > > that's why it was submitted to MIP. > > Right, as has many other I-Ds that are not necessarily of relevance to the WG, > and not in charter. Just because someone believes an I-D belongs in a WG > doesn't mean it does. > => Sure, but I got my opinion when I read the draft in question. Anyway, everyone is entitled to present their draft in their chosen WG, at last once :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 18:19:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06325 for ; Wed, 14 Mar 2001 18:19:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24992; Wed, 14 Mar 2001 15:18:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17847; Wed, 14 Mar 2001 15:18:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENHOIm003543 for ; Wed, 14 Mar 2001 15:17:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ENHNuj003542 for mobile-ip-dist; Wed, 14 Mar 2001 15:17:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENHJIm003535 for ; Wed, 14 Mar 2001 15:17:19 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04244 for ; Wed, 14 Mar 2001 18:17:19 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04264 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 18:17:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ELkKIm003273 for ; Wed, 14 Mar 2001 13:46:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23567 for ; Wed, 14 Mar 2001 13:46:19 -0800 (PST) Received: from cisco.com (pita.cisco.com [171.71.68.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03877 for ; Wed, 14 Mar 2001 13:46:19 -0800 (PST) Received: from WSIDDIQI-W2K1.cisco.com (dhcp-10-34-195-68.cisco.com [10.34.195.68]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA24527 for ; Wed, 14 Mar 2001 13:46:18 -0800 (PST) Message-Id: <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com> X-Sender: wsiddiqi@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Mar 2001 13:47:07 -0800 To: mobile-ip@sunroof.eng.sun.com From: Waseem Siddiqi Subject: [mobile-ip] Mobile IP on Windows ? In-Reply-To: <20010314192547.B18619@mymlan.lifix.fi> References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010313224837.21080.qmail@web3102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hi, anyone know of a working MIPv4 implementation on Windows ? Microsoft is only working on MIPv6 and I know NUS has an alpha version of their MIPv4 that they have stopped working on. thanks waseem From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 18:26:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06400 for ; Wed, 14 Mar 2001 18:26:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28324; Wed, 14 Mar 2001 15:26:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21521; Wed, 14 Mar 2001 15:26:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENPQIm003609 for ; Wed, 14 Mar 2001 15:25:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ENPQZn003608 for mobile-ip-dist; Wed, 14 Mar 2001 15:25:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENPLIm003601 for ; Wed, 14 Mar 2001 15:25:21 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10508 for ; Wed, 14 Mar 2001 18:25:21 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04420 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 18:25:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMPnIm003413 for ; Wed, 14 Mar 2001 14:25:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03662 for ; Wed, 14 Mar 2001 14:25:50 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16146 for ; Wed, 14 Mar 2001 14:25:48 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2EMPlC19951 for ; Wed, 14 Mar 2001 23:25:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 14 23:25:46 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 14 Mar 2001 23:25:46 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC68@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Wed, 14 Mar 2001 23:20:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > > GM> I agree, I support anycast too. To vilify a solution which employs > > it as magic was wrong and I apologize. > > No need for apology, but I wanted to point out that this particular > use of anycast is easy to implement, assuming that one's IPv6 > implementation supports anycast at all. > => I'm a bit confused by this statement. How can it be easy to implement a BU to an anycast address ? BUs have to be secured with AH, so how can you setup this security association when there are no standards defined to do so ? Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 18:42:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06591 for ; Wed, 14 Mar 2001 18:42:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04160; Wed, 14 Mar 2001 15:42:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13294; Wed, 14 Mar 2001 15:42:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENeUIm003738 for ; Wed, 14 Mar 2001 15:40:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ENeTqc003737 for mobile-ip-dist; Wed, 14 Mar 2001 15:40:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENeOIm003730 for ; Wed, 14 Mar 2001 15:40:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12800 for ; Wed, 14 Mar 2001 18:40:25 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04713 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 18:40:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2EMU7Im003433 for ; Wed, 14 Mar 2001 14:30:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05830 for ; Wed, 14 Mar 2001 14:30:04 -0800 (PST) Received: from fridge.docomo-usa.com ([216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11319 for ; Wed, 14 Mar 2001 14:30:04 -0800 (PST) Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f2EMZOD21628 for ; Wed, 14 Mar 2001 14:35:25 -0800 (PST) Date: Wed, 14 Mar 2001 14:35:24 -0800 (PST) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0321366F@daeis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Oh, it was my mistake ... It should've been to Behcet Sarikaya, and now everything seems clear for me. Thanks people, Youngjune On Wed, 14 Mar 2001 Basavaraj.Patil@nokia.com wrote: > I never suggested that your presentation be moved to Seamoby! > > -Basavaraj > > > -----Original Message----- > > From: ext Youngjune Lee Gwon [mailto:gyj@dcl.docomo-usa.com] > > Sent: Tuesday, March 13, 2001 5:43 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Final Agenda for Mobile IP WG > > meeting at IETF50 > > > > > > Basavaraj, > > > > Can I ask your intention of requesting our presentation > > moving to Seamoby? > > > > Youngjune Gwon > > DoCoMo USA Labs > > > > On Tue, 13 Mar 2001, Behcet Sarikaya wrote: > > > > > Hi Raj, > > > Is there any possiblity of moving the handoff drafts to > > the Seamoby > > > WG, as per Pat's recent comments on a draft submitted by NTT DOCOMO > > > researchers? > > > > > > Regards, > > > > > > Basavaraj.Patil@nokia.com wrote: > > > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > > > > > > > > > Handoffs - Panel discussion 50 Mins > > > > - V6 handoff design team 20 Mins > > > > - V4 handoff design team 20 Mins > > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > > Youngjune Gwon 10 Mins > > > > > > -- > > > Behcet > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 18:46:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06658 for ; Wed, 14 Mar 2001 18:46:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03164; Wed, 14 Mar 2001 15:46:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14184; Wed, 14 Mar 2001 15:46:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENiiIm003791 for ; Wed, 14 Mar 2001 15:44:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2ENiibR003790 for mobile-ip-dist; Wed, 14 Mar 2001 15:44:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENidIm003783 for ; Wed, 14 Mar 2001 15:44:39 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08021 for ; Wed, 14 Mar 2001 18:44:39 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04802 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 18:44:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENYrIm003704 for ; Wed, 14 Mar 2001 15:34:53 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00798 for ; Wed, 14 Mar 2001 15:34:53 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA01858 for ; Wed, 14 Mar 2001 15:34:52 -0800 (PST) Date: Wed, 14 Mar 2001 15:30:18 -0800 (PST) From: Pat Calhoun Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF7546013DBC64@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => Sure, but I got my opinion when I read the draft > in question. Anyway, everyone is entitled to present > their draft in their chosen WG, at last once :) > Then perhaps I can share an snippet from an e-mail from the TSV ADs to WG chairs, which should apply to all WGs IMHO: "A while back we sent you a note reminding you that we do not want to take valuable face-to-face IETF session time to have people present their Internet Drafts. If someone has published an Internet Draft, and that draft has been discussed on the working group mailing list, and confusions or issues have come up during that discussion, then it is reasonable to take session time to discuss those issues. (Assuming that the topic of the Internet Draft falls within the existing Working Group charter: another practice we wish to discourage is using face-to-face time to "try out" new topics for the working group - this should be minimized, and used only when truly pressing new views of the WG mission have emerged. And such topics should be discussed with the ADs before session discussion). [...] Scott & Allison" Food for thought. PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 19:20:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06889 for ; Wed, 14 Mar 2001 19:20:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02575; Wed, 14 Mar 2001 16:20:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03111; Wed, 14 Mar 2001 16:20:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F0J6Im003888 for ; Wed, 14 Mar 2001 16:19:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F0J63i003887 for mobile-ip-dist; Wed, 14 Mar 2001 16:19:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F0IwIm003880 for ; Wed, 14 Mar 2001 16:19:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17440 for ; Wed, 14 Mar 2001 19:18:58 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA05459 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 19:19:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2ENbcIm003717 for ; Wed, 14 Mar 2001 15:37:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01948 for ; Wed, 14 Mar 2001 15:37:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05759 for ; Wed, 14 Mar 2001 15:37:38 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA15291 for ; Wed, 14 Mar 2001 15:37:38 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2ENbZu12801 for ; Wed, 14 Mar 2001 15:37:35 -0800 X-mProtect: Wed, 14 Mar 2001 15:37:35 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdRpO44b; Wed, 14 Mar 2001 15:36:44 PST Message-ID: <3AB000CE.4A4A4DA@iprg.nokia.com> Date: Wed, 14 Mar 2001 15:37:51 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Comments on Regional Registration References: <034BEFD03799D411A59F00508BDF7546013DBC68@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, We want to get the routing part figured out, and I believe we have a pretty good handle on it. Setting up security will allow a mobile node to provide authentication data that can be checked by one of the anycast group members. I know several ways to do that. It will be more productive to start on that task once two other things are out of the way: - Fixing the authentication mechanism for base Mobile IPv6 - Getting the routing part figured out. If you wish to disqualify all anycast-based solutions because there are no standards for establishing security between a node and the members of an anycast group, then I would just prefer to say that we believe the problem is wholly solvable for the particular anycast group we have designed. We don't intend to get in the business of solving it for the general case. Regards, Charlie P. "Hesham Soliman (ERA)" wrote: > Hello Charlie, > > > > > > GM> I agree, I support anycast too. To vilify a solution which employs > > > it as magic was wrong and I apologize. > > > > No need for apology, but I wanted to point out that this particular > > use of anycast is easy to implement, assuming that one's IPv6 > > implementation supports anycast at all. > > > => I'm a bit confused by this statement. How can it be easy > to implement a BU to an anycast address ? > BUs have to be secured with AH, so how can you setup this > security association when there are no standards defined > to do so ? > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 20:35:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07590 for ; Wed, 14 Mar 2001 20:34:59 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27283; Wed, 14 Mar 2001 17:34:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17561; Wed, 14 Mar 2001 17:34:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1XeIm004112 for ; Wed, 14 Mar 2001 17:33:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F1XeYr004111 for mobile-ip-dist; Wed, 14 Mar 2001 17:33:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1XZIm004104 for ; Wed, 14 Mar 2001 17:33:35 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25037 for ; Wed, 14 Mar 2001 20:33:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA06913 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 20:33:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F0qjIm003999 for ; Wed, 14 Mar 2001 16:52:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09687 for ; Wed, 14 Mar 2001 16:52:46 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26751 for ; Wed, 14 Mar 2001 16:52:44 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2F0qhC06589 for ; Thu, 15 Mar 2001 01:52:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 15 01:54:27 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 01:55:49 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC6C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 01:52:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > We want to get the routing part figured out, and I believe > we have a pretty good handle on it. > > Setting up security will allow a mobile node to provide > authentication data that can be checked by one of the > anycast group members. I know several ways to do that. > It will be more productive to start on that task once two > other things are out of the way: > - Fixing the authentication mechanism for base Mobile IPv6 > - Getting the routing part figured out. > => I don't understand what needs to be solved on the routing aspect of the problem ? Do you not like the routing provided by HMIPv6 ? If so why ? We use standard IP routing between the MAP and the MN or the CN for that matter. I think it's as solved as Internet routing today is. > If you wish to disqualify all anycast-based solutions because > there are no standards for establishing security between a > node and the members of an anycast group, then I would > just prefer to say that we believe the problem is wholly > solvable for the particular anycast group we have designed. > We don't intend to get in the business of solving it for the > general case. > => I'm not at all trying to discredit anycastl. I'm just wondering how you could use it in light of the current standards. You still didn't tell me what the solution is. Proposing a solution for setting up an SA with an anycast group would be a great proposal, but I don't think we need several standards to solve this particular problem. We already have a solution and I'm starting to question the need for alternatives if nothing is raised against HMIPv6. Especally if the alternative is a lot less robust and overrides the use of standard routing between the anchor point and the MN. Thanks, Hesham > "Hesham Soliman (ERA)" wrote: > > > Hello Charlie, > > > > > > > > > GM> I agree, I support anycast too. To vilify a solution which employs > > > > it as magic was wrong and I apologize. > > > > > > No need for apology, but I wanted to point out that this particular > > > use of anycast is easy to implement, assuming that one's IPv6 > > > implementation supports anycast at all. > > > > > => I'm a bit confused by this statement. How can it be easy > > to implement a BU to an anycast address ? > > BUs have to be secured with AH, so how can you setup this > > security association when there are no standards defined > > to do so ? > > > > Regards, > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 20:39:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07636 for ; Wed, 14 Mar 2001 20:39:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13897; Wed, 14 Mar 2001 17:38:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19244; Wed, 14 Mar 2001 17:38:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1boIm004163 for ; Wed, 14 Mar 2001 17:37:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F1bo17004162 for mobile-ip-dist; Wed, 14 Mar 2001 17:37:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1bjIm004155 for ; Wed, 14 Mar 2001 17:37:45 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20053 for ; Wed, 14 Mar 2001 20:37:45 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA06994 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 20:37:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F0rPIm004021 for ; Wed, 14 Mar 2001 16:53:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09791 for ; Wed, 14 Mar 2001 16:53:25 -0800 (PST) Received: from hotmail.com (f181.law7.hotmail.com [216.33.237.181]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15858 for ; Wed, 14 Mar 2001 16:53:24 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Mar 2001 16:53:24 -0800 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 15 Mar 2001 00:53:23 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Thu, 15 Mar 2001 00:53:23 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Mar 2001 00:53:24.0133 (UTC) FILETIME=[56956550:01C0ACEA] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The 01 version of the draft (draft-chaskar-mobileip-qos-01.txt) explicitly points out the performance problems with RSVP, when it is used in the mobile environment. The 00 version of the draft was presented in SD meeting. A question that was raised during that meeting was - how and why should it be different from RSVP? 01 version answers that question, and clearly shows that RSVP introduces unacceptable latency in the QoS programming after handover. In other words, the 01 version addresses what was not explicit in the 00 version, thus trying to clarify the situation from the performance angle. It will be apparent on reading the draft that a whole new section on the performance analysis of the two approaches (RSVP vs the hop-by-hop QoS object approach) is added in the 01 version. Thus, it is an appropriate sequel of 00 version discussion. Also, the RSVP approach studied in the draft (for the case when CoA changes) in the SeaMoby WG (draft-thomas-seamoby-rsvp-analysis-00.txt) is not immune to the above performance problem. The author of that draft has observed this phenomenon as well. Hemant >From: Michael Thomas >Reply-To: mobile-ip@sunroof.eng.sun.com >To: >CC: mobile-ip@sunroof.eng.sun.com, mat@cisco.com >Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 >Date: Wed, 14 Mar 2001 11:04:43 -0800 (PST) > >I understand that, but this draft in particular is >positing a completely different way to perform >signaled QoS admission control which has global >implications: CN's and interior routers would need >to implement this as well. > >As you may know, I've spent a fair amount of time >trying to figure out what the implications of our >current signaled QoS admission control scheme -- >RSVP -- are with MIP and I can tell you as a very >quick summary that positing a completely different >signaling scheme is *far* too premature. It would >be much, much better to analyze what the current >state of affairs is and compare that to MIP >requirements before we decide whether a specific >solution is in order. In fact, even if it is, I >cannot imagine that the MIP WG is the right place >to pursue this. > >I have volunteered to discuss my analysis (draft- >thomas-seamoby-rsvp-analysis-00) and will do so >again at this point, but even if you don't take me >up on this, I cannot see what will be productive >about discussing this draft for the second IETF >in a row: all of the same arguments of scope >and wholesale reinvention apply. > > Mike > >Basavaraj.Patil@nokia.com writes: > > > > Michael, > > > > > Can I ask why we are discussing solution space for QoS > > > when the requirements aren't even known? > > > > The requirements may not be explicitly stated as such. The >requirements > > for QoS from a Mobile IP perspective are as follows: > > > > 1. If QoS has been established for a session between an MN and CN, how >do > > you > > deal with it when the MN changes it's point of attachment, and as a > > result the path of the > > packet flow changes > > 2. What are the implications on QoS for a session w.r.t fast handoffs. > > 3. More? I am not sure. > > > > -Basavaraj > > > > > > > > Basavaraj.Patil@nokia.com writes: > > > > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Thursday March 22nd - 9:00 AM - 11.30 AM > > > > ---------------------------------------- > > > > > > > > Agenda bashing 5 Mins > > > > WG Doc Status 5 Mins > > > > > > > > MIP at Connectathon - Report 5 Mins > > > > - Alper Yegin > > > > > > > > Mobile IPv6 Discussion 30 Mins > > > > - Issues related to using IPSec > > > > for binding updates Jeff Schiller 10 Mins > > > > - Discussion of draft-bradner-pbk-frame-00.txt > > > > Jeff Schiller 5 Mins > > > > - Discussion 15 Mins > > > > > > > > Handoffs - Panel discussion 50 Mins > > > > - V6 handoff design team 20 Mins > > > > - V4 handoff design team 20 Mins > > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > > Youngjune Gwon 10 Mins > > > > > > > > Hierarchical Mobility Schemes 15 Mins > > > > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > > > > Hesham Soliman 8 Mins > > > > - Comparison/Discussion with > > > > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > > > > > > > Dynamic configuration of Mobile hosts 15 Mins > > > > - Sandy Thuel > > > > draft-thuel-mobileip-tt-01.txt 8 Mins > > > > - Steve Glass > > > > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > > > > > > > QoS Discussion 10 Mins > > > > - draft-chaskar-mobileip-qos-01.txt > > > > Hemant Chaskar > > > > > > > > WG Charter review 10 Mins > > > > > > > > > > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 20:42:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07686 for ; Wed, 14 Mar 2001 20:42:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02731; Wed, 14 Mar 2001 17:42:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18855; Wed, 14 Mar 2001 17:42:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1f2Im004240 for ; Wed, 14 Mar 2001 17:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F1f2CJ004239 for mobile-ip-dist; Wed, 14 Mar 2001 17:41:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1evIm004230 for ; Wed, 14 Mar 2001 17:40:57 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25691 for ; Wed, 14 Mar 2001 20:40:57 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA07058 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 20:41:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F0w5Im004032 for ; Wed, 14 Mar 2001 16:58:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27984 for ; Wed, 14 Mar 2001 16:58:06 -0800 (PST) Received: from hotmail.com (f203.law7.hotmail.com [216.33.237.203]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08694 for ; Wed, 14 Mar 2001 16:58:05 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Mar 2001 16:58:05 -0800 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 15 Mar 2001 00:58:05 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Thu, 15 Mar 2001 00:58:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Mar 2001 00:58:05.0904 (UTC) FILETIME=[FE883D00:01C0ACEA] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The 01 version of the draft (draft-chaskar-mobileip-qos-01.txt) explicitly points out the performance problems with RSVP, when it is used in the mobile environment. The 00 version of the draft was presented in SD meeting. A question that was raised during that meeting was - how and why should it be different from RSVP? 01 version answers that question, and clearly shows that RSVP introduces unacceptable latency in the QoS programming after handover. In other words, the 01 version addresses what was not explicit in the 00 version, thus trying to clarify the situation from the performance angle. It will be apparent on reading the draft that a whole new section on the performance analysis of the two approaches (RSVP vs the hop-by-hop QoS object approach) is added in the 01 version. Thus, it is an appropriate sequel of 00 version discussion. Also, the RSVP approach studied in the draft (for the case when CoA changes) in the SeaMoby WG (draft-thomas-seamoby-rsvp-analysis-00.txt) is not immune to the above performance problem. The author of that draft has observed this phenomenon as well. >From the implementation standpoint, the draft (draft-chaskar-mobileip-qos-01.txt) is for Mobile IPv6. IPv6 deployment has not already taken place at the global Internet scale. Deployment of v6 provides a clear transition phase for the implementation of new and better solutions. Thus, I do not see any big issue with implementation of CN's and core routers as far as the IPv6 deployment is considered. Hemant >From: Michael Thomas >Reply-To: mobile-ip@sunroof.eng.sun.com >To: >CC: mobile-ip@sunroof.eng.sun.com, mat@cisco.com >Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 >Date: Wed, 14 Mar 2001 11:04:43 -0800 (PST) > >I understand that, but this draft in particular is >positing a completely different way to perform >signaled QoS admission control which has global >implications: CN's and interior routers would need >to implement this as well. > >As you may know, I've spent a fair amount of time >trying to figure out what the implications of our >current signaled QoS admission control scheme -- >RSVP -- are with MIP and I can tell you as a very >quick summary that positing a completely different >signaling scheme is *far* too premature. It would >be much, much better to analyze what the current >state of affairs is and compare that to MIP >requirements before we decide whether a specific >solution is in order. In fact, even if it is, I >cannot imagine that the MIP WG is the right place >to pursue this. > >I have volunteered to discuss my analysis (draft- >thomas-seamoby-rsvp-analysis-00) and will do so >again at this point, but even if you don't take me >up on this, I cannot see what will be productive >about discussing this draft for the second IETF >in a row: all of the same arguments of scope >and wholesale reinvention apply. > > Mike > >Basavaraj.Patil@nokia.com writes: > > > > Michael, > > > > > Can I ask why we are discussing solution space for QoS > > > when the requirements aren't even known? > > > > The requirements may not be explicitly stated as such. The >requirements > > for QoS from a Mobile IP perspective are as follows: > > > > 1. If QoS has been established for a session between an MN and CN, how >do > > you > > deal with it when the MN changes it's point of attachment, and as a > > result the path of the > > packet flow changes > > 2. What are the implications on QoS for a session w.r.t fast handoffs. > > 3. More? I am not sure. > > > > -Basavaraj > > > > > > > > Basavaraj.Patil@nokia.com writes: > > > > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > Thursday March 22nd - 9:00 AM - 11.30 AM > > > > ---------------------------------------- > > > > > > > > Agenda bashing 5 Mins > > > > WG Doc Status 5 Mins > > > > > > > > MIP at Connectathon - Report 5 Mins > > > > - Alper Yegin > > > > > > > > Mobile IPv6 Discussion 30 Mins > > > > - Issues related to using IPSec > > > > for binding updates Jeff Schiller 10 Mins > > > > - Discussion of draft-bradner-pbk-frame-00.txt > > > > Jeff Schiller 5 Mins > > > > - Discussion 15 Mins > > > > > > > > Handoffs - Panel discussion 50 Mins > > > > - V6 handoff design team 20 Mins > > > > - V4 handoff design team 20 Mins > > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > > Youngjune Gwon 10 Mins > > > > > > > > Hierarchical Mobility Schemes 15 Mins > > > > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > > > > Hesham Soliman 8 Mins > > > > - Comparison/Discussion with > > > > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > > > > > > > Dynamic configuration of Mobile hosts 15 Mins > > > > - Sandy Thuel > > > > draft-thuel-mobileip-tt-01.txt 8 Mins > > > > - Steve Glass > > > > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > > > > > > > QoS Discussion 10 Mins > > > > - draft-chaskar-mobileip-qos-01.txt > > > > Hemant Chaskar > > > > > > > > WG Charter review 10 Mins > > > > > > > > > > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 20:46:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07749 for ; Wed, 14 Mar 2001 20:46:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16512; Wed, 14 Mar 2001 17:46:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07705; Wed, 14 Mar 2001 17:46:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1ixIm004310 for ; Wed, 14 Mar 2001 17:44:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F1ixLU004309 for mobile-ip-dist; Wed, 14 Mar 2001 17:44:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1isIm004302 for ; Wed, 14 Mar 2001 17:44:54 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20703 for ; Wed, 14 Mar 2001 20:44:53 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA07138 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 20:44:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1CcIm004063 for ; Wed, 14 Mar 2001 17:12:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13007 for ; Wed, 14 Mar 2001 17:12:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18987 for ; Wed, 14 Mar 2001 17:12:37 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA24174 for ; Wed, 14 Mar 2001 17:12:37 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F1CXL27040 for ; Wed, 14 Mar 2001 17:12:33 -0800 X-mProtect: Wed, 14 Mar 2001 17:12:33 -0800 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpdFEIzLf; Wed, 14 Mar 2001 17:12:25 PST Message-ID: <3AB016FD.37B76008@cs.ucl.ac.uk> Date: Wed, 14 Mar 2001 17:12:29 -0800 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Some questions on Hierarchical MIPv6 References: <034BEFD03799D411A59F00508BDF7546013DBC64@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I would appreiciate if the HMIP authors could shed some light in some statements in the hmipv6-02 draft that got out recently. In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP. The question is which one the home address or the onlink (LCoA)? If a MAP is serving as a mobile AR you enforce that it must advertise its and all MAP options available. Does that imply that the 'preference' is specific here? Further (page 20, top statement) you state that this would allow the MN to obtain a new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA). The reason I ask here is because you state that in the extended mode the MN is bound to use the mobile AR/MAP IP address. Also you state that the MN should send a BU to the (further ???) MAP to bind its Home Addr with the MR's CoA. Can you explain why you need to do that? Do you mean by further, a MAP higher (upstream) in the routing hierarchy? How can you possibly have location privacy if the upstream packets have as their source address the MNs LCoA. If you do not have the LCoA as the source address, then start praying over egress filtering. If you have load balancing effected which RCoA do you send back to the HA? Regs. Theo UCL / Mobile systems From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 14 20:50:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07801 for ; Wed, 14 Mar 2001 20:50:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08037; Wed, 14 Mar 2001 17:50:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08318; Wed, 14 Mar 2001 17:50:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1mrIm004370 for ; Wed, 14 Mar 2001 17:48:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2F1mrn3004369 for mobile-ip-dist; Wed, 14 Mar 2001 17:48:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1mmIm004362 for ; Wed, 14 Mar 2001 17:48:49 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21145 for ; Wed, 14 Mar 2001 20:48:48 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA07219 for mobile-ip@sunroof.eng.sun.com; Wed, 14 Mar 2001 20:48:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F1lTIm004317 for ; Wed, 14 Mar 2001 17:47:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15647 for ; Wed, 14 Mar 2001 17:47:29 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA02995 for ; Wed, 14 Mar 2001 18:47:28 -0700 (MST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2F1lKg18898 for ; Wed, 14 Mar 2001 19:47:30 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 14 Mar 2001 19:47:17 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 19:47:17 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC3CA@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Wed, 14 Mar 2001 19:47:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Hesham, > => I'm not at all trying to discredit anycastl. I'm just > wondering how you could use it in light of the current > standards. You still didn't tell me what the solution > is. > Proposing a solution for setting up an SA with an > anycast group would be a great proposal, but > I don't think we need several standards to solve > this particular problem. We already have a solution > and I'm starting to question the need for alternatives > if nothing is raised against HMIPv6. Especally if > the alternative is a lot less robust and overrides > the use of standard routing between the anchor point > and the MN. > actually that there are different proposals on the way to set up Security Associations and to authenticate the BU using AH in Appendix B of the draft. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 12:25:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03807 for ; Thu, 15 Mar 2001 12:25:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26980; Thu, 15 Mar 2001 09:25:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10860; Thu, 15 Mar 2001 09:25:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHO1Im005434 for ; Thu, 15 Mar 2001 09:24:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FHO1v2005433 for mobile-ip-dist; Thu, 15 Mar 2001 09:24:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHNqIm005426 for ; Thu, 15 Mar 2001 09:23:56 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03570 for ; Thu, 15 Mar 2001 12:23:52 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA25183 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 12:23:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F24uIm004437 for ; Wed, 14 Mar 2001 18:04:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22359 for ; Wed, 14 Mar 2001 18:04:55 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17678 for ; Wed, 14 Mar 2001 18:04:54 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA08799; Wed, 14 Mar 2001 18:05:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACI03796; Wed, 14 Mar 2001 18:04:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA08387; Wed, 14 Mar 2001 18:04:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15024.9028.54884.980740@thomasm-u1.cisco.com> Date: Wed, 14 Mar 2001 18:04:52 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Dave Oran , rcoltun@redback.com Subject: [mobile-ip] Question to Chairs re: QoS In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, I'm the author of that draft. Even though the draft points out a number of deficiencies with RSVP as it currently stands, that should not give the MIP WG free reign to create a new QoS admission control protocol which is mainly aimed at solving the narrow niche of mobile IP and nothing else, and considering little else . Question to the AD's and Chairs: does MIP WG include in its charter the task of recreating RSVP just because at first blush it's not clear how RSVP will interact with MIP? I see that MIP has in its charter that it needs to *consider* Intserv and Diffserv QoS, but that is surely not the same as free license to recreate QoS protocols and semantics. If not, I suggest that this is an inappropriate use of this time slot for QoS discussions. Mike Hemant Chaskar writes: > The 01 version of the draft (draft-chaskar-mobileip-qos-01.txt) explicitly > points out the performance problems with RSVP, when it is used in the mobile > environment. The 00 version of the draft was presented in SD meeting. A > question that was raised during that meeting was - how and why should it be > different from RSVP? 01 version answers that question, and clearly shows > that RSVP introduces unacceptable latency in the QoS programming after > handover. In other words, the 01 version addresses what was not explicit in > the 00 version, thus trying to clarify the situation from the performance > angle. It will be apparent on reading the draft that a whole new section on > the performance analysis of the two approaches (RSVP vs the hop-by-hop QoS > object approach) is added in the 01 version. Thus, it is an appropriate > sequel of 00 version discussion. > > Also, the RSVP approach studied in the draft (for the case when CoA changes) > in the SeaMoby WG (draft-thomas-seamoby-rsvp-analysis-00.txt) is not immune > to the above performance problem. The author of that draft has observed this > phenomenon as well. > > >From the implementation standpoint, the draft > (draft-chaskar-mobileip-qos-01.txt) is for Mobile IPv6. IPv6 deployment has > not already taken place at the global Internet scale. Deployment of v6 > provides a clear transition phase for the implementation of new and better > solutions. Thus, I do not see any big issue with implementation of CN's and > core routers as far as the IPv6 deployment is considered. > > Hemant > > >From: Michael Thomas > >Reply-To: mobile-ip@sunroof.eng.sun.com > >To: > >CC: mobile-ip@sunroof.eng.sun.com, mat@cisco.com > >Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 > >Date: Wed, 14 Mar 2001 11:04:43 -0800 (PST) > > > >I understand that, but this draft in particular is > >positing a completely different way to perform > >signaled QoS admission control which has global > >implications: CN's and interior routers would need > >to implement this as well. > > > >As you may know, I've spent a fair amount of time > >trying to figure out what the implications of our > >current signaled QoS admission control scheme -- > >RSVP -- are with MIP and I can tell you as a very > >quick summary that positing a completely different > >signaling scheme is *far* too premature. It would > >be much, much better to analyze what the current > >state of affairs is and compare that to MIP > >requirements before we decide whether a specific > >solution is in order. In fact, even if it is, I > >cannot imagine that the MIP WG is the right place > >to pursue this. > > > >I have volunteered to discuss my analysis (draft- > >thomas-seamoby-rsvp-analysis-00) and will do so > >again at this point, but even if you don't take me > >up on this, I cannot see what will be productive > >about discussing this draft for the second IETF > >in a row: all of the same arguments of scope > >and wholesale reinvention apply. > > > > Mike > > > >Basavaraj.Patil@nokia.com writes: > > > > > > Michael, > > > > > > > Can I ask why we are discussing solution space for QoS > > > > when the requirements aren't even known? > > > > > > The requirements may not be explicitly stated as such. The > >requirements > > > for QoS from a Mobile IP perspective are as follows: > > > > > > 1. If QoS has been established for a session between an MN and CN, how > >do > > > you > > > deal with it when the MN changes it's point of attachment, and as a > > > result the path of the > > > packet flow changes > > > 2. What are the implications on QoS for a session w.r.t fast handoffs. > > > 3. More? I am not sure. > > > > > > -Basavaraj > > > > > > > > > > > Basavaraj.Patil@nokia.com writes: > > > > > > > > > > Final agenda for the Mobile IP WG meeting at IETF50 > > > > > > > > > > Thursday March 22nd - 9:00 AM - 11.30 AM > > > > > ---------------------------------------- > > > > > > > > > > Agenda bashing 5 Mins > > > > > WG Doc Status 5 Mins > > > > > > > > > > MIP at Connectathon - Report 5 Mins > > > > > - Alper Yegin > > > > > > > > > > Mobile IPv6 Discussion 30 Mins > > > > > - Issues related to using IPSec > > > > > for binding updates Jeff Schiller 10 Mins > > > > > - Discussion of draft-bradner-pbk-frame-00.txt > > > > > Jeff Schiller 5 Mins > > > > > - Discussion 15 Mins > > > > > > > > > > Handoffs - Panel discussion 50 Mins > > > > > - V6 handoff design team 20 Mins > > > > > - V4 handoff design team 20 Mins > > > > > - (draft-gwon-mobileip-l3mp-mipv4-00.txt) > > > > > Youngjune Gwon 10 Mins > > > > > > > > > > Hierarchical Mobility Schemes 15 Mins > > > > > - HMIPv6 (draft-ietf-mobileip-hmipv6-02.txt) > > > > > Hesham Soliman 8 Mins > > > > > - Comparison/Discussion with > > > > > draft-malinen-mobileip-regreg6-01.txt 7 Mins > > > > > > > > > > Dynamic configuration of Mobile hosts 15 Mins > > > > > - Sandy Thuel > > > > > draft-thuel-mobileip-tt-01.txt 8 Mins > > > > > - Steve Glass > > > > > draft-glass-mobileip-agent-dhcp-proxy-01.txt 7 Mins > > > > > > > > > > QoS Discussion 10 Mins > > > > > - draft-chaskar-mobileip-qos-01.txt > > > > > Hemant Chaskar > > > > > > > > > > WG Charter review 10 Mins > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 12:45:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04272 for ; Thu, 15 Mar 2001 12:45:17 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20603; Thu, 15 Mar 2001 09:45:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12123; Thu, 15 Mar 2001 09:45:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHh8Im005517 for ; Thu, 15 Mar 2001 09:43:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FHh8dB005516 for mobile-ip-dist; Thu, 15 Mar 2001 09:43:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHh3Im005509 for ; Thu, 15 Mar 2001 09:43:03 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07701 for ; Thu, 15 Mar 2001 12:43:03 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA25573 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 12:43:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F45DIm004501 for ; Wed, 14 Mar 2001 20:05:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24419 for ; Wed, 14 Mar 2001 20:05:13 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10786 for ; Wed, 14 Mar 2001 20:05:12 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA04828 for ; Wed, 14 Mar 2001 20:05:11 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F45Ax18181 for ; Wed, 14 Mar 2001 20:05:10 -0800 X-mProtect: Wed, 14 Mar 2001 20:05:10 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdJ7543v; Wed, 14 Mar 2001 20:05:02 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id UAA13287 for ; Wed, 14 Mar 2001 20:05:02 -0800 (PST) Message-ID: <3AB03F6E.8735D28E@iprg.nokia.com> Date: Wed, 14 Mar 2001 20:05:02 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, "Hesham Soliman (ERA)" wrote: > > Hello Glenn, > > You're absolutely right. That's exactly what we have been avoiding > in the HMIPv6 work. There is no need for a non-robust solution > that intrduces a tree of single points of failures. As you said > network administrators can force routes to introduce this effect > if they want their networks to be less robust for other reasons. Or regreg6 configurator can freely decide on the number of hierarchy levels according to his needs, including having one only. And, I do not believe it impossible to have dynamic configuration option for regreg6, it is something extra to natural routing, but doable. In fact, having some redundancy in mobility binding state in the hierarchy may help reconstructing the state once a regional router goes down. Once a MAP goes down, you'll need some effort to set up those forwarding entries to the tunnels for mobile nodes under it. Simply moving the regional CoAs to anothe box is not enough. In a scalable solution, I do not believe timeout and full re-registration in every case for every mobile node is all that can be done, either. > So far I haven't heard *any* reason for it [multiple levels of hierarchy]. Consider the following: Some users of a localized mobility scheme consider bandwidth of the last mile a very precious resource. They may also envision that the number of mobile nodes can be very large. In fact, so large that one MAP box is not enough to handle the signaling load of a visite domain. Suppose the last mile is so precious that we can't use but one RCoA/MAP option on the router advertisement. How would the load balancing with MAP work? If we can distribute load to more than one box by maintaining e.g. one level of lower routers, locality of movement naturally brings location update signaling load down to other boxes from a GMA. When simultaneously increasing the number of mobile nodes, I believe the signaling difference becomes significant. > Cheers, > Hesham Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 13:55:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05435 for ; Thu, 15 Mar 2001 13:55:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10274; Thu, 15 Mar 2001 10:55:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03301; Thu, 15 Mar 2001 10:54:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FIrTIm005834 for ; Thu, 15 Mar 2001 10:53:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FIrS6b005833 for mobile-ip-dist; Thu, 15 Mar 2001 10:53:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FIrNIm005826 for ; Thu, 15 Mar 2001 10:53:24 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19815 for ; Thu, 15 Mar 2001 13:53:19 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA26926 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 13:53:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F4CFIm004523 for ; Wed, 14 Mar 2001 20:12:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07044 for ; Wed, 14 Mar 2001 20:12:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29796 for ; Wed, 14 Mar 2001 20:12:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA05328 for ; Wed, 14 Mar 2001 20:12:13 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F4CBl21353 for ; Wed, 14 Mar 2001 20:12:11 -0800 X-mProtect: Wed, 14 Mar 2001 20:12:11 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpddJBiRf; Wed, 14 Mar 2001 20:12:06 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id UAA13294 for ; Wed, 14 Mar 2001 20:12:09 -0800 (PST) Message-ID: <3AB04118.FC7B7910@iprg.nokia.com> Date: Wed, 14 Mar 2001 20:12:08 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, A bit late, but here are my comments. I believe simply labeling our solution connection-oriented does not do justice to the options possible with it. > Glenn Morrow wrote: > > Hello, > > I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings we introduce state used in a similar way as state used for maintaining plain next hop forwarding. I read your use of term connection-oriented to mean the use of mobility bindings for forwarding instead of exclusively relying on host/network/default routes. Introducing robustness in this form of forwarding is a problem both HMIP and regreg6 face. In fact, even basic Mobile IPv6 while forwarding packets via the home agent has this feature. On terms used in discussions, we should also recognize that mobility bindings cause only an indirection to the forwarding and do not alter the data packets on flight, thus word proxy is a bit off the mark here. > If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in. > > Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain? > > Respectfully, I wish to be illuminated on this - one way or the other. Mobility introduces soft state, if we use mobility bindings. This is the case with any localized mobility scheme, whether one, or multiple levels of hierarchy. Mobility state is used for packet forwarding through encapsulation in a way resembling what host-based routing does with next-hop state. It can use aggregation, if you want to. What comes to our particular solution, it gives the flexibility to set up a hierarchy of one or more levels, but does not force one to do that. On configuring a hierarchy, I believe it is quite possible to have a dynamic configuration option with provisions for robustness even with our solution. Providing options for different configurations for a large variety of requirements where some configurations are more static than others does not necessarily make the solution radically more connection-oriented than some other solutions. To always use "natural aggregation" while having a stationary care-of-address has a price. It will reduce the point of mobility binding state management to a hotspot which does not necessarily scale well given that we want continuously to keep the mobility signaling localized. Therefore, to address the other side of the coin, "natural aggregation" calls for concentrating the mobility binding state management to as few points as possible. I do not think a solution should disallow distribution of mobility state maintenance to scale for receiving a huge number of simultaneous RBUs. Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 14:57:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06863 for ; Thu, 15 Mar 2001 14:57:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03259; Thu, 15 Mar 2001 11:57:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24830; Thu, 15 Mar 2001 11:57:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FJtdIm006121 for ; Thu, 15 Mar 2001 11:55:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FJtdBi006120 for mobile-ip-dist; Thu, 15 Mar 2001 11:55:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FJtYIm006113 for ; Thu, 15 Mar 2001 11:55:34 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11329 for ; Thu, 15 Mar 2001 14:55:33 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA28280 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 14:55:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F5InIm004605 for ; Wed, 14 Mar 2001 21:18:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17075 for ; Wed, 14 Mar 2001 21:18:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA07362 for ; Wed, 14 Mar 2001 22:18:47 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA08103 for ; Wed, 14 Mar 2001 21:18:47 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2F5IjM23855 for ; Wed, 14 Mar 2001 21:18:45 -0800 X-mProtect: Wed, 14 Mar 2001 21:18:45 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpduqIMWR; Wed, 14 Mar 2001 21:18:34 PST Message-ID: <3AB05047.746578AE@iprg.nokia.com> Date: Wed, 14 Mar 2001 21:16:55 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Comments on Regional Registration References: <034BEFD03799D411A59F00508BDF7546013DBC6C@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, > > - Getting the routing part figured out. > > > => I don't understand what needs to be solved on the > routing aspect of the problem ? Do you not like > the routing provided by HMIPv6 ? If so why ? I think it's important to support more than one level of regionalized care-of address, at least for the organization of mobility management we have in mind for "All-IP" networks. I also like that anycast addressing allows the mobile node to accomplish the regional binding update without having to know about the topology of the visited domain. > => I'm not at all trying to discredit anycastl. I'm just > wondering how you could use it in light of the current > standards. You still didn't tell me what the solution > is. > Proposing a solution for setting up an SA with an > anycast group would be a great proposal, but > I don't think we need several standards to solve > this particular problem. We already have a solution > and I'm starting to question the need for alternatives > if nothing is raised against HMIPv6. Especally if > the alternative is a lot less robust and overrides > the use of standard routing between the anchor point > and the MN. Your statement is near tautological. Of course, we'd also like to arrive at a robust protocol that uses as much standard routing as is possible. We also wish to allow betterm localization of binding updates than HMIPv6 could provide. That can translate into better scalability for the foreseeable future. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 15:17:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07469 for ; Thu, 15 Mar 2001 15:17:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08177; Thu, 15 Mar 2001 12:07:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21915; Thu, 15 Mar 2001 12:07:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FK5UIm006195 for ; Thu, 15 Mar 2001 12:05:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FK5TlT006194 for mobile-ip-dist; Thu, 15 Mar 2001 12:05:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FK5OIm006187 for ; Thu, 15 Mar 2001 12:05:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13569 for ; Thu, 15 Mar 2001 15:05:24 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA28547 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 15:05:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2F8m1Im004798 for ; Thu, 15 Mar 2001 00:48:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06171 for ; Thu, 15 Mar 2001 00:47:57 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02486 for ; Thu, 15 Mar 2001 00:47:56 -0800 (PST) Received: from fokus.gmd.de (centauri [193.175.132.71]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA27473; Thu, 15 Mar 2001 09:47:55 +0100 (MET) Message-ID: <3AB081BB.E750868D@fokus.gmd.de> Date: Thu, 15 Mar 2001 09:47:55 +0100 From: Reinhard Ruppelt Organization: GMD FOKUS / MOBIS X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IP on Windows ? References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010313224837.21080.qmail@web3102.mail.yahoo.com> <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com> Content-Type: multipart/mixed; boundary="------------E684FDC47625E9532D6CB6C7" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------E684FDC47625E9532D6CB6C7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 V2FzZWVtIFNpZGRpcWkgd3JvdGU6DQoNCj4gaGksDQo+DQo+IGFueW9uZSBrbm93IG9mIGEg d29ya2luZyBNSVB2NCBpbXBsZW1lbnRhdGlvbiBvbiBXaW5kb3dzID8NCj4gTWljcm9zb2Z0 IGlzIG9ubHkgd29ya2luZyBvbiBNSVB2NiBhbmQgSSBrbm93IE5VUyBoYXMgYW4gYWxwaGEg dmVyc2lvbiBvZg0KPiB0aGVpciBNSVB2NCB0aGF0DQo+IHRoZXkgaGF2ZSBzdG9wcGVkIHdv cmtpbmcgb24uDQo+DQo+IHRoYW5rcw0KPiB3YXNlZW0NCg0KV2UgaGF2ZSBvbmUuIEN1cnJl bnRseSBvdXIgVy1OVCBNb2JpbGUgSVAgY29kZSBpcyBzdWJqZWN0IHRvIGEgcmV2aXNpb24u DQpBZGRpdGlvbmFsbHkNCndlIGFyZSBub3cgaW1wbGVtZW50aW5nIElQc2VjIHNlY3VyaXR5 IGZlYXR1cmVzLiBTb29uIHRoZSByZXN1bHRpbmcgbmV3DQp2ZXJzaW9uIHdpbGwgc3Vic3Rp dHV0ZSB0aGUgY3VycmVudCBvbmUgYW5kIGJlIHN1YmplY3QgdG8gbWFya2V0aW5nLg0KUGxl YXNlIGZlZWwgZnJlZSB0byBkb3dubG9hZCB0aGUgY3VycmVudCB2ZXJzaW9uIGZyb20NCmh0 dHBzOi8vd3d3Lm1vYmlsZS1pcC5kZS9+YW5kcmVpL3JvYW1pbi8gKHVzZXI6IHJvYW1pbiwg cGFzc3dvcmQ6DQpvbWE2a2VjaCkuDQpXZSB3b3VsZCBhcHByZWNpYXRlIHZlcnkgbXVjaCBp ZiB5b3UgY291bGQgZ2l2ZSB1cyBpbmZvcm1hdGlvbiBvZiB0aGUNCnBsYW5uZWQgZGVwbG95 bWVudCBzY2VuYXJpbyBhbmQgc29tZSBmZWVkYmFjayBvbiB5b3VyIGV4cGVyaWVuY2VzLg0K QmVzdCByZWdhcmRzLA0KUmVpbmhhcmQgUnVwcGVsdA0KDQpQUw0KQSBXLTk4IHZlcnNpb24g aXMgYWxzbyBhdmFpbGFibGUNCg0KLS0NCkdNRCBGT0tVUyAvIE1PQklTDQpHZXJtYW4gTmF0 aW9uYWwgUmVzZWFyY2ggQ2VudGVyIGZvciBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQotIElu c3RpdHV0ZSBmb3IgT3BlbiBDb21tdW5pY2F0aW9uIFN5c3RlbXMgLQ0KS2Fpc2VyaW4tQXVn dXN0YS1BbGxlZSAzMSwgRC0xMDU4OSBCZXJsaW4sIEdlcm1hbnkNClZvaWNlOiArNDkgMzAg MzQ2My03MjQ5LCBGYXg6IC04MjQ5DQpFbWFpbDogUmVpbmhhcmQuUnVwcGVsdEBnbWQuZGUN CldXVzogd3d3LmZva3VzLmdtZC5kZS91c3IvcmVpbmhhcmQucnVwcGVsdC8NCg0KDQo= --------------E684FDC47625E9532D6CB6C7 Content-Type: application/octet-stream; name="roamin-software-agreement.pdf" Content-Disposition: attachment; filename="roamin-software-agreement.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAzMTgwDQovRmlsdGVyIC9G bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSImMV01z28gRvatK/2FqT0BKoAl+iGL5snY5cjnJ ZlMWc0itcwCBIYkVCTADQIr+fd7rngFAxYpTdlEDoGe65/XX64+b66t393OTms3u+iqdmSn+ 4c9yNbldm9XtdDKbm83p+mpq9pD8/JCafXN9lUwn0+nMbHJ80NXz9dVv0UOc3EZ1nMyiXfuc OWviJJ1Gf4nXURkniyiPk7vIxrOoaqz5IN/2FHbW8suJMrZqTfzPzZ+oMUkn6dJsPnEtqkRN ZOLN79dXmz+8NmMRzPgbzTjKaRk0OTk9K0zLVwdq9JbtapGSHzH7Weys9vFdpNKy1Ylljckz ebK7LmybLaKXOIXwFufN5G672sXJWpaqpKifK9WQFaPja9nh4jQyXaPv5Y18/IrlUk3KoDxd RF/iWeoljPnGW1Cfs6OdGbWr1WIC7B2uJxcpPLTEjtClvQfXHrqf4Ct4cR7V9GC8hIHA0vL1 t3hiNge92zIyD7X6mOuyMZTV+/71U5ysYC+MlpNMWbWUIoppKpsL3LrkDvlgClc+2aDLlKfz kU8n/lRtCbiwzfwih9fbUj6qKoCyoLfn0Y2+4JmIMv4QvjQ6nfmqoj5RLI5a02nRCIvEgyEQ hA1wixq1iIzofAp3P5quLY9lK/d5ieepN4dKufuM3dlW7WxrIxi1Tgx4GowXPYURJa3ZdRWP 5xFtWVeZqBHjXRbAaHsAXWPqnWkPw2kDhjDXfOduee9yueU/6s50VWFd02awoj1kLc9zkqKG uVtWB69vjphHWhbymOGxktUeQYH9EFQTsJ2Y0bIMEjNiA6zHMTdK49+iRmNsgdNptAdlAZz1 b3nkL3A0yClT1CKAXKr5uoCQhMbU79y5+iSILHzE4dyKvy2z6MZwEy76+ZdPvGKCW9zHt9Gv fPjz3x+Y24uoI/SNnvcSzxBuHR144rdHeSvHNx1LSnr7vRB6BbPg6s8DFjgvrxnfdOVcoD3K SpGCQzzkyCCHdA7OseZct/BBmR2NK5vHxmwtQLGKSqqoFOXgF9kjekOeTgxdriBjY1MfLQsY VV/6aDKdB+udbc4ApAw+yAr7ry4bbDdnB7NyomZo6DbLH5PubNSoHUsg7SiyNpPv2F2eT4wl xEnBwMnrqvIHPCOhVihs/yNivHsfLgKHValrWABmwWuIjU5u6mhkH1h8kgOqujVcVBBsy/bI dUFP+1qNYqpBZr6r8QaOkj3NRazIssMZ5mwd4DoNmt8MlFWA2oeFBYZ0vuAoKIZEx0vDCHC6 JKayAIJtVlZWI6dPRg03eddJUhuJpURa4bGufHRQbdda502tindw87HOeTQz/Wgq2z7rOQzI x4mq+a8+Ipf4KK1KY1mg/E5QEkoJICEIw8nsgpWX0iQYhYukkb9pgyc0nBDXveM1vfoAv7Dw doAZ3EObylqK8xaI112ljSFULNiJOgZYTg17bZ+Otqwybz0gQ3s9IopF408I3Q8s4DxXRLmH OUL7ZQdFvsX4NAnNC2G2U5owugDCh+GZ7cGKaCCUvIG2BoY3U2q5IuNJF35KUZxbz7doXZKS bp30DkD2QA5R3QSqIrqD6wxigQVd7adXImuGeiJmj27xOmlRSIa87fHsHURXlDAaEGYVopyA 7ay7EQGT5bk9t+wj0lhBYEy4mv23/DmjOjWarJJ/5lieytZKHlOhDyLRKsVPDx41vQuLQ7kO HYOdIrloEWgDLPqqTA471UW502d2qLKhoTXDq5OyoSXB34zVo6w866UlF7VFe+CgvS8d1VBh fJstT6HsDfslrftWSqQuC04gyWnP1Vm6hRjm+kcyYCZYBvLrSSY8dfafQHVdKUm+P4iIEXJJ 5vkslOSzVbIsBCAcFmqLstfAWGeRZ9hgwVUma/kE8iOHqtr0lVqw40O/V80kh7ajA3hiQ3jk qREO+mHvo14mDNn7w95d1LaRfNjrADMHe/tesRlzHacpB3R0q8RqOsQq2+1s7SHZu6xqQwXR RJyYN5qfn3re3S/8rPam4dG32WIFoc883QzD0hszFGIiTG/d9ndEg88fn66al1pYPkjcOqls lnXNlw1mCl/e/8o0GSKc/RY2NOPWHEAL2XpjgFOVNN0Wb1ipPMkU4udrwQ89xRNaXLfZ9aWa /Nub5+rBQdLTWs978Cz9cIfYuKEZWjLUZfkRDQkOV6ukFLMWvpFX0z6vxkPmAwcameJ0LtOW V40Hx1E6GBkvcxifcyH7XJFVue/VOpwO55s+yXhQUefdRYAzKcdZZYadmiyssbVk61leVppi Mik2ZlA2EWU/isulj8upSdJJujKbT6/clS7Gs4dw0JaqXF3tjy/gNnmgK9neV3EZRuCxpu0p UMOAvINhqDjsaJl2tBvhXAKbxOeJbcn4E+XhzLEw83SD7Kald1vpEzM5D0PsnvyiNbXX5vyl 9U5LudOF11d3YZYpoWTJkcXFt1Lj2B74CqxO/lq891Vv6X0DeRBQCTto5xUgw/072lpzJVvh 6BfzWKKA3rGnSMNNOPhBx1bOzfFzEFnRD9m9EG59Rd5GMUOVGpp8oiQXDepnd+Q3rkz2lOEa HF8vJ5wLX07XIdzrMIY2nF1lyEUD3JV8MvyBwdEJhiyEk8vwOI/K9mVivrTsVAcIpHTmSkZb P8WONwNCLFv+IFDArLHYyikFOFUhKjU/YxnRsFeE4Uknf3E7jqlP9fFJZsb07RHja50F382j L5WR8seBwjHCGjanG85wJ+uY3Gz4HMo4HMFJDBx5L0Xt3AHdLQqIOXfuXDcWXWnQe1GDA7TJ uKxtwgxX73Y8lFEV5VAXhw4CawXZL571k4J0TcNxaqe1B9HeiYgKBA7l/MZSEkJckugOL/4z k0tW9bY82qQ8Twrbd/KweCGW4oq6eFFcha9l3p7fa8wjmOvSvt++u7+9KBS3r5IqGdfS7Ytp JL4LCWhGvlZKG1IDoSqDo49r8202m6OXNLnPJCaYpAg+LDgcNbQSjS7WjKQcdxvJNowCxYtk ST0w2nf3K2/xerK+NVP8k8X8FqauzXw+Qx0wm5PmxdLs4VrCW0pXa3JXbu3Pu/qxayb7UwEU xe1/3FxfpaY011f9OUKY09V8cndnAMPdAtF7fQW9Hzdj3NKZ2IA/y/nitQXUrgHNMYOKkvl6 shrV5DfohHpjLiLKIGbmq21aV+YtwqnxRGJcCUcBfNmX03GhP8mYquwIjOgGNNmBZRx9DyYZ Gg2BKHLhc+pbtKefo9ksUF5t5yz+XXUEwVKWgv+VzfGYydyru3Zeh9lm+WPSnX1GKsHVPxel Lh2mLCcq0ful/+jQJUsl7tIn7Huyf4C17VqY48LMx7pwFGmRa5QW9FfoN7/3eeO87JzVjjow q5RP2qqUA9TuUUnZnULxQz4y5iDkHzc/6OSvS/10Fko9IVhGodx7H9Ba1GsrCK8BsIwnqLkH ec/yWOnkyeqgMhxRGuuepEdYs+2czbpQI6UNTaMbShI+KanPZeMB+P+M4CPb6jp6eVXt32CQ WtFZWy8i472hCVox7amGFy7Y/rkP3PrsStuqP/EyhJ0ySsYexjbEpNm5+jTyvwsMZyKC5kPz RsOdLoMXttILn60UMLnluofjrDkBKFppxOAUbdlK9/R4PlfSXptDKbI6r6TqnQOaRYstCl4a FSKh7tPmKyfRaYzuqKMg8HK1nGW9v/9Td7WsNgwDwV8RPbVgB9LQew+lUHLoweTUXFSTYIEf wnagn9+Z3XUsNc3NwtJqtY/ZmdkC9LxMgzEk5pXRA4jzW0xzWFcwl/T57pTmCJJMmKwgRgSE d9ALEVAXh1GBi/VzGs6FQ0m2rVP5Aj87z9nUO6oXVS60GsAUpkuMbcC0l/YV/j+MUybNkmb5 UrjcuQrHcKmYOUSIO0B9SXqFWN05m1fjyzr4RW2ZZN2R0TtTo5Iu6MpeEqsBVjkqKdEyQjSz OuWDtBJHAPBFfZsK3Rz9XDeqfEi1C9huKDoo8LBKwPkcftZ9V0gVKLqpWiWHa6Gf3PFR5Q24 AgqpJqYlKG/OyHsewOoqMlwLaCVYYTDNn8cnuLOhvNrebHJ+kYAQGFS0XPJWEbYewBO17RRl c8+vGahyq3+TkYRdJ9x2GXH4a9Ih9LgP3KRZK2yjBz+UwnPkaAVb+pA/HJiSA3DZ4nKnETBp MCLwUJ0fjUsdV8aHmJCx9rOvZ1gWe28lfXwH5fmEG3uG44CPyn3by9hTUr0lotSRZXmQaWE1 suO1S2jhf51BfvMLvdDL/Q0KZW5kc3RyZWFtDQplbmRvYmoNCjMgMCBvYmoNCjw8DQovUHJv Y1NldCBbL1BERiAvVGV4dCBdDQovRm9udCA8PA0KL0YzIDQgMCBSDQovRjQgNSAwIFINCi9G NSA2IDAgUg0KL0Y2IDcgMCBSDQovRjcgOCAwIFINCj4+DQovRXh0R1N0YXRlIDw8DQovR1Mx IDkgMCBSDQo+Pg0KPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8DQovTGVuZ3RoIDI0NTANCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiaRX74/jthH9vsD+D8R9kgrbtbU/ vP54aZJDmwYNsA6KIOkHWaLX7EmiQ1Lru/++b2ZIWdr15i4oDue1peFwOPPmzeM32+urv35/ q1Zqu7++WhVqiX/4c7de3G/U+n65KG7Utr2+WqonWH54XKknf301Xy6WS6yp8EK+na6vfs1+ K27X6lb9O5+vszK/yZwru5DPi5vsc77aZErl/9n+g3zNV4vVndp+S9/ZCTvIVL797/XV9i8v NlgVaYPtQatHuw+n0ml1KL0KVu20+r0vG7M3ulZ45O28KpsGP97tXT5/yLQ+lRSRy4tM05d3 +TpbqPdNONj+Kd9kB/Xhx3y+KrJv59/nd9m/8vkm++HnR6U/4ekqK1vTwVvA3hI/BTiJ73YT 45PY4MNpfCgsX2b00+fLjGI1wcvDpxyOyabTjgwaVeHT5qusPTb0PBjbKXrT1epkKSL3kT7p 0Q5mpjGBo/ucF6ssWYYD2fDeydDrjlxr2dfu1bNxvScTP0M8quKlqrMBmeSghzOOipAdna6a vkYehhrh4HepMOFQBs7QUJ3KdqE02PQm67yq9V5XOLx1al/2TfALtT30fAAPgGQzlCBlf5X9 QKf4GV8e1dHZZ1NrP3XOZ6EyEsq8Mp6+z9jduEapPncxynf5Q3YCCkw4KEAkhsLL6JUqKdmc 1yIDNoLCZhHCBSUaRbS89R7bwhrPl/H5R8OrunrGXg7aEdJ0fosinK1q46umNK3n7RlfS0qt 58wY1J5AfAllv2aCK0ZLh9QEE2s4tl7dJSQarnqDDbK+Nh3jbaZ2OBNVujGtCbQekLEzyi1V /vIOCpjhOFv66cjtgU3CFItFxOIMT9TehI5XR7zvcTwyV8cEYhcMueob/pHP7/Gud0fL0JyR 1WUkjvnmqB0ct1QIHK/Ss9hxVSXQctz3Fb6vhYFmShgB5WtMuYtNRPRUbBJ+qHyd7eam25Mt sQblb8OrWjanb10gCBs/1FS7ocUAm7R0SoBoCh9M6AMAfanK8/HpUh2UJJLZIhhhi6OkUDEz 7IEy1BCx0FMuNfMP/aeAhWioogv1uj1eUu801Zsxtec43p36Z45uIACViadyOba8EM4cQUMY 6ssbT4t8k9IgxDAHM4CT6S+3CrikMZXOiV7oiN46UP+B2goABxvQXKAaN1rRT+rbSMhcCtuT m4gcKY5FGzh15BHhvOU37FvtX5rWxrFZFcChHf2ib5enQ7FJOfRHKgShnpLEOeIGJR/D01oP vRVfYnPCDT3/vZ+goKY/bTkMEz/Cg6Bnjmg/5zfp6Ny8uWzNPVfGgALDxKk/Qxv5lG3f6NG6 bLkLUwd5zuZrki6KuKCxPhDtg0LAbvjFDPTEGLP1yTTNLM4wvD5Z91H5YI/H8gntT53vRH3c ct/fJ9req4GQfc+5aMh9ZdsjupGmkml6TBbLZm8da7VOx2rLZt93FcF/puiMT2hpAYXHUBHG UHtn2wnonELcSrC1Bz3wWPNxrM2UftadMpFveRoC8/OkTogLSPTsNKxegY2aqayfjccEwXFZ rlzs6SLhEWTrzW6kJAgnWEoJ2gxYeY2ymeq7hpdEio/zIxkKFPkMzEOUEEmF9PKaJNYaEos+ H38rigIjvAsR2rYTcAMlTw4RNqnv3kbb6iGVpdOUdyy5yUR7MOy6QB1Uy1CowIKX9Z7QB3hD sM7cAVnDSiEyQDEwAINayj5hFUJ7GjecSar0XkgFp3yLBhFfpxlOpEAOb7Hi0FatrQ3PJ97I CDkx5kZCKc06iXA3IrDJWeJQKzuMhy/TtIyCe7XVDsK45JBHby+D7iyRf+EcyUzgkrOXSEGC KJll7/9okJ0FLy9oWEtoIUklCxO9sb2QFhuzRyPimmkvUeUmamlOVjAsd9Tu/JyZ2QdnI6vi GTM2L+U91YTZ3qic0y0krfCDaCPqDALZoXS1qkW5kOp4JobrdCCS86IrLSl8ThPjCcznzuyq Wl2bMmog+Kvs0WjPSE+M8AoYYxYZRu5PzpJDNiOF3S6kc4mNlNC5ICdEDAiAhrptMmFC/mip GakFS6kXz21USo22gBlP2qBZOmuUx7R8mqCbqNA2L6IdLoWJL1MH7mTzsjpMYc5XCS+0AMxy Rs7x6laTpGNPf8+RMumKF0GQn/6I1enkyd1sGsNQlHgDpcsfbjEMniGgF1Ap5KZFGPpjLcYI BojOd8zznGHubAQYwtgj8V6zblDRZlAEBJN0SRWckNWjnAzdM9xp1U/ODmDne0K7YKX+mIQN 2IAe4MZXqNR8NZvcwq+z/bCcb6rqgUg3Ko4VPi+qfhFPvXs2cuQpbZhpLf8/8RuF7lp9F+9m FiL7b7jKOtv48fq3BPNmzHPxbOhEyjJiwAUvkjARyindQynET5QP3o5vRCefKM5F2jExv93o DR+3h+OmHF4iFy8I7YP0IuVsuFNwmRwJRYw2ZkT21X3dxQtjrxtdq5j3GH19OFhnRleemTAs ohWDJ3Qaz1c0hP7EyaBDs8pFKiLmsObEXDEyIQun54m6xi8m3KYvTtnF8j7G/mxsUybUsKpf RpHoe1DGWSbyBnSUDLnn3EKOligMB0LjhUVpj7YRh36hvhFPtWW3p66xZW1kDzYeMtV7VtfL F/Nath7IBL7EU/8VNcHJI+3MV4mA45xBslkPMldYefdk40spTnEmL6mU00nCHYXEvD7z9Gjp iSBDU8IJmXfpZTjEwXCBGmm+RZ1lqzQ/6tEhQesd6cwa2pxCr6QHUbNZlM/kQpVKFEjJenGY a97UNHEsK6Tp1S2eiRuKxo2woO3hHl8fBkDzSoBksjjqOcCkMf6rCEX45EH9aHylm6bstO39 l/XSWaRvv6yF+PlReIKPo1P/h0GbjxiIfjOFqjK6PfskpUyWfA1kygAcOzOSOMyzUW/FCM6b QjyT8xN77NLeR54ewYzuBZHBvghq3x+1w40mqWxiy6MzRBbTCYuiT9SGZ2yOsNsFBgrXz1NT I1YKlKNsx4M/kIupjt9F0YXnJXRCPYHqqxus5dtRQReqJa8tEsPEs4N1T2DJxADU8p9iDvna ep/hToqvdS7rB4baQf9ROm8lnSCpc+A3uFDS1ZXejlktyp7RlKRN34OIYUj/W8qG5lXQvQoG B/rV1EQbO/r65r1rnerUd7oDsVRMOnxxSlwz1WDSfVyS0pNqYs49hyhqlTRuFu9iTu9jv7d0 saXUptmiwnlcjKdFIBjjNqW9L8dNncxfKsl4nonc4En5keFrQjT/bnt99b8BAKMLg/4NCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxMyAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0IF0N Ci9Gb250IDw8DQovRjQgNSAwIFINCj4+DQovRXh0R1N0YXRlIDw8DQovR1MxIDkgMCBSDQo+ Pg0KPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8DQovTGVuZ3RoIDYwNg0KL0ZpbHRlciAvRmxh dGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJbFTLbtswELwb8D/skSwilZRf9TFpGqMtih6inoIe ZImyGEiUQVJ28vfdJSWnBgxDssSdfczs2A/5fPb5aQES8no+kxkI/ODXapOut7BZizRbQN7N ZwIOiNw9Szi4+SwRqRCYU2IgFUt8Os9nL0yZurclTzZMFftWpTyRkkHeaAf3PNmyA98yy5Mv TPEFXojreIJPxoNriraFvQLMEQHYnwLCGlXBPlR653LLIqCgkKmg7I3zdghhKlrBYKqYBztq SYe2Kwy0xXmc597wJJuqVdodB68chjKs/Tf/QVwTmcoV5I+B3kh04hyY9hZKvmItpuEsK6Y7 B1bRCb15bSJdaud78EGBQwDQ1VEaPRguGXEnNCUGCfAb3LB/VdTBx/xwSLc3gl5aD06fQuh1 sNpVmseY172Bvp7yIqv8EzGLK8smHjvFl6QP3g0XDL72g/UujSJ/53IRj6nQkgZYshO+qxGO wzWU6lHQcTHvPBMMi0CrDhRqoe5DwHaAol1j9ji/oWLOoZxLFpG4Ue1xJ3Q+dXb+0mdwRK3g cvk/s2tHrid+nbJlUxh/B8e2iM6k7FGuMgh1sd4DX0e/tNrcwU6Rbz6sQu4hMyuoC90OFx9T vWC1XzTdY/KEkv+m959/nml56i2605baqRu7kJtxVm0g7iFqtBCjpDYocVSkkJ8g2TVEo9cE a2gn0clH2590RZkVbsBCkDFUwjZnjYRN78lsqGKA0dURg5BDS6dOcKY7mQyzR7I3J6jRN7EH WB1G+JjIxd/dzWW9sEZZdfnRpiPqG/4v/RNgAEg/LJMNCmVuZHN0cmVhbQ0KZW5kb2JqDQox NiAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0IF0NCi9Gb250IDw8DQovRjMgNCAw IFINCj4+DQovRXh0R1N0YXRlIDw8DQovR1MxIDkgMCBSDQo+Pg0KPj4NCmVuZG9iag0KMTcg MCBvYmoNCjw8DQovVHlwZSAvSGFsZnRvbmUNCi9IYWxmdG9uZVR5cGUgMQ0KL0hhbGZ0b25l TmFtZSAoRGVmYXVsdCkNCi9GcmVxdWVuY3kgNjANCi9BbmdsZSA0NQ0KL1Nwb3RGdW5jdGlv biAvUm91bmQNCj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8DQovVHlwZSAvRXh0R1N0YXRlDQov U0EgZmFsc2UNCi9PUCBmYWxzZQ0KL0hUIC9EZWZhdWx0DQo+Pg0KZW5kb2JqDQo0IDAgb2Jq DQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YzDQovQmFzZUZv bnQgL1RpbWVzLVJvbWFuDQo+Pg0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQN Ci9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0Y0DQovRW5jb2RpbmcgMTggMCBSDQovQmFzZUZv bnQgL1RpbWVzLVJvbWFuDQo+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQN Ci9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0Y1DQovQmFzZUZvbnQgL1RpbWVzLUJvbGQNCj4+ DQplbmRvYmoNCjcgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQov TmFtZSAvRjYNCi9FbmNvZGluZyAxOCAwIFINCi9CYXNlRm9udCAvVGltZXMtQm9sZA0KPj4N CmVuZG9iag0KOCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9O YW1lIC9GNw0KL0Jhc2VGb250IC9Db3VyaWVyLUJvbGQNCj4+DQplbmRvYmoNCjE4IDAgb2Jq DQo8PA0KL1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWyAwL2dyYXZlL2FjdXRlL2Np cmN1bWZsZXgvdGlsZGUvbWFjcm9uL2JyZXZlL2RvdGFjY2VudC9kaWVyZXNpcw0KL3Jpbmcv Y2VkaWxsYS9odW5nYXJ1bWxhdXQvb2dvbmVrL2Nhcm9uL2RvdGxlc3NpL2ZpL2ZsDQovTHNs YXNoL2xzbGFzaC9aY2Fyb24vemNhcm9uL21pbnVzIDM5L3F1b3Rlc2luZ2xlIDk2L2dyYXZl IDEzMC9xdW90ZXNpbmdsYmFzZQ0KL2Zsb3Jpbi9xdW90ZWRibGJhc2UvZWxsaXBzaXMvZGFn Z2VyL2RhZ2dlcmRibC9jaXJjdW1mbGV4L3BlcnRob3VzYW5kL1NjYXJvbg0KL2d1aWxzaW5n bGxlZnQvT0UgMTQ1L3F1b3RlbGVmdC9xdW90ZXJpZ2h0L3F1b3RlZGJsbGVmdC9xdW90ZWRi bHJpZ2h0L2J1bGxldC9lbmRhc2gNCi9lbWRhc2gvdGlsZGUvdHJhZGVtYXJrL3NjYXJvbi9n dWlsc2luZ2xyaWdodC9vZSAxNTkvWWRpZXJlc2lzIDE2NC9jdXJyZW5jeQ0KIDE2Ni9icm9r ZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodC9vcmRmZW1pbmluZSAxNzIvbG9naWNhbG5v dC9oeXBoZW4vcmVnaXN0ZXJlZC9tYWNyb24NCi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVy aW9yL3RocmVlc3VwZXJpb3IvYWN1dGUvbXUgMTgzL3BlcmlvZGNlbnRlcmVkL2NlZGlsbGEN Ci9vbmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXIvb25laGFsZi90aHJl ZXF1YXJ0ZXJzIDE5Mi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4DQovQXRpbGRlL0FkaWVy ZXNpcy9BcmluZy9BRS9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4DQovRWRp ZXJlc2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0aC9OdGlsZGUv T2dyYXZlDQovT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZS9PZGllcmVzaXMvbXVsdGlwbHkv T3NsYXNoL1VncmF2ZS9VYWN1dGUNCi9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlL1Ro b3JuL2dlcm1hbmRibHMvYWdyYXZlL2FhY3V0ZS9hY2lyY3VtZmxleA0KL2F0aWxkZS9hZGll cmVzaXMvYXJpbmcvYWUvY2NlZGlsbGEvZWdyYXZlL2VhY3V0ZS9lY2lyY3VtZmxleA0KL2Vk aWVyZXNpcy9pZ3JhdmUvaWFjdXRlL2ljaXJjdW1mbGV4L2lkaWVyZXNpcy9ldGgvbnRpbGRl L29ncmF2ZQ0KL29hY3V0ZS9vY2lyY3VtZmxleC9vdGlsZGUvb2RpZXJlc2lzL2RpdmlkZS9v c2xhc2gvdWdyYXZlL3VhY3V0ZQ0KL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhv cm4veWRpZXJlc2lzDQpdDQo+Pg0KZW5kb2JqDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UN Ci9QYXJlbnQgMTAgMCBSDQovUmVzb3VyY2VzIDMgMCBSDQovQ29udGVudHMgMiAwIFINCj4+ DQplbmRvYmoNCjExIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMTAgMCBSDQov UmVzb3VyY2VzIDEzIDAgUg0KL0NvbnRlbnRzIDEyIDAgUg0KPj4NCmVuZG9iag0KMTQgMCBv YmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCAxMCAwIFINCi9SZXNvdXJjZXMgMTYgMCBS DQovQ29udGVudHMgMTUgMCBSDQo+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwNCi9UeXBlIC9Q YWdlcw0KL0tpZHMgWzEgMCBSIDExIDAgUiAxNCAwIFJdDQovQ291bnQgMw0KL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0NCj4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFs b2cNCi9QYWdlcyAxMCAwIFINCj4+DQplbmRvYmoNCjIwIDAgb2JqDQo8PA0KL0NyZWF0aW9u RGF0ZSAoRDoxOTEwMTAzMTUwOTQ2MzApDQovUHJvZHVjZXIgKFwzNzZcMzc3XDAwMEFcMDAw Y1wwMDByXDAwMG9cMDAwYlwwMDBhXDAwMHRcMDAwIFwwMDBEXDAwMGlcMDAwc1wwMDB0XDAw MGlcMDAwbFwwMDBsXDAwMGVcMDAwclwwMDAgXDAwMDNcMDAwLlwwMDAwXDAwMDFcMDAwIFww MDBmXDAwMG9cMDAwclwwMDAgXDAwMFdcMDAwaVwwMDBuXDAwMGRcMDAwb1wwMDB3XDAwMHMp DQovQ3JlYXRvciAoV2luZG93cyBOVCA0LjApDQovVGl0bGUgKE1pY3Jvc29mdCBXb3JkIC0g cm9hbWluLXNvZnR3YXJlLWFncmVlbWVudC5kb2MpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDIx DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDg4MzEgMDAwMDAgbg0KMDAwMDAwMDAxNyAw MDAwMCBuDQowMDAwMDAzMjc3IDAwMDAwIG4NCjAwMDAwMDcwNjcgMDAwMDAgbg0KMDAwMDAw NzE1NyAwMDAwMCBuDQowMDAwMDA3MjY1IDAwMDAwIG4NCjAwMDAwMDczNTQgMDAwMDAgbg0K MDAwMDAwNzQ2MSAwMDAwMCBuDQowMDAwMDA2OTg4IDAwMDAwIG4NCjAwMDAwMDkxMDQgMDAw MDAgbg0KMDAwMDAwODkyMCAwMDAwMCBuDQowMDAwMDAzNDI2IDAwMDAwIG4NCjAwMDAwMDU5 NTcgMDAwMDAgbg0KMDAwMDAwOTAxMiAwMDAwMCBuDQowMDAwMDA2MDYzIDAwMDAwIG4NCjAw MDAwMDY3NDkgMDAwMDAgbg0KMDAwMDAwNjg1NSAwMDAwMCBuDQowMDAwMDA3NTUyIDAwMDAw IG4NCjAwMDAwMDkyMDggMDAwMDAgbg0KMDAwMDAwOTI2NSAwMDAwMCBuDQp0cmFpbGVyDQo8 PA0KL1NpemUgMjENCi9Sb290IDE5IDAgUg0KL0luZm8gMjAgMCBSDQovSUQgWzw2OWZjNTRl ZmJhODgzZDlmM2RlZWU0MDZkYWM2MTUwYz48NjlmYzU0ZWZiYTg4M2Q5ZjNkZWVlNDA2ZGFj NjE1MGM+XQ0KPj4NCnN0YXJ0eHJlZg0KOTYwMg0KJSVFT0YNCg== --------------E684FDC47625E9532D6CB6C7-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 15:29:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07617 for ; Thu, 15 Mar 2001 15:29:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18052; Thu, 15 Mar 2001 12:29:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29503; Thu, 15 Mar 2001 12:29:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKRCIm006293 for ; Thu, 15 Mar 2001 12:27:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FKRBrA006292 for mobile-ip-dist; Thu, 15 Mar 2001 12:27:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKR6Im006285 for ; Thu, 15 Mar 2001 12:27:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07701 for ; Thu, 15 Mar 2001 15:27:05 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA29072 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 15:27:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FEhGIm005200 for ; Thu, 15 Mar 2001 06:43:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02379 for ; Thu, 15 Mar 2001 06:43:16 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06706 for ; Thu, 15 Mar 2001 06:43:15 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2FEgSg29658 for ; Thu, 15 Mar 2001 08:43:08 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 15 Mar 2001 08:42:26 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 15 Mar 2001 08:42:26 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0321367F@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 Date: Thu, 15 Mar 2001 08:42:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Michael, >I understand that, but this draft in particular is >positing a completely different way to perform >signaled QoS admission control which has global >implications: CN's and interior routers would need >to implement this as well. > >As you may know, I've spent a fair amount of time >trying to figure out what the implications of our >current signaled QoS admission control scheme -- >RSVP -- are with MIP and I can tell you as a very >quick summary that positing a completely different >signaling scheme is *far* too premature. I am aware of your work in this area, but I am not so sure if the scope of the discussion in the time slot is premature. >It would >be much, much better to analyze what the current >state of affairs is and compare that to MIP >requirements before we decide whether a specific >solution is in order. In fact, even if it is, I >cannot imagine that the MIP WG is the right place >to pursue this. > Why is the MIP WG not the place to work on QoS aspects that are related to mobility, especially from a Mobile IP perspective? Where else in the IETF would you believe this work needs to be done? >I have volunteered to discuss my analysis (draft- >thomas-seamoby-rsvp-analysis-00) and will do so >again at this point, but even if you don't take me >up on this, I cannot see what will be productive >about discussing this draft for the second IETF >in a row: all of the same arguments of scope >and wholesale reinvention apply. > I believe the authors of the chaskar I-D have addressed some of the concerns that you have raised on the mailing list. We welcome your input and discussion on the issues. I do not believe there is any "wholesale reinvention" being proposed in the chaskar draft. It is specifically targeted for Mobile IPv6 and is addressing a specific problem. > Mike > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 15:41:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07834 for ; Thu, 15 Mar 2001 15:41:38 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28671; Thu, 15 Mar 2001 12:41:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18298; Thu, 15 Mar 2001 12:41:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKZOIm006391 for ; Thu, 15 Mar 2001 12:35:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FKZNwE006390 for mobile-ip-dist; Thu, 15 Mar 2001 12:35:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKZCIm006383 for ; Thu, 15 Mar 2001 12:35:12 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09521 for ; Thu, 15 Mar 2001 15:35:11 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA29392 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 15:35:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FF02Im005235 for ; Thu, 15 Mar 2001 07:00:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06550 for ; Thu, 15 Mar 2001 07:00:02 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01184 for ; Thu, 15 Mar 2001 07:00:01 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 15 Mar 2001 08:53:54 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 08:58:57 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E430185511C@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 08:58:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD60.71F71DE0" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AD60.71F71DE0 Content-Type: text/plain; charset="iso-8859-1" Hesham and Charlie, I'm not too worried about the security association issue with anycast. I think anycast is extremely useful and is here to stay. It is part of IPv6 - might as well take advantage of it. I believe the SA establishment and scaling problem for MIP, in general, has scaling and speed issues. It would actually probably be more productive for us to focus on that issue than heirarchical models. It seems people have focused so far on "database in the sky" solutions with AAA protocols to this. I have an alternate idea which I would like to bring up again. Why don't we use a hop by hop option to alert mobile-aware routers to the binding updates. For instance, a mobile could send a binding update to a CN and it would be intercepted by the 1st hop router in the visited domain. If the visited domain wanted to support hierarchical, other routers along the natural routing path to the CN would be configured to care as well at whatever topological tier the provider deemed necessary. These hirearchical routers could install a per-host route in the binding cache to achieve route both optimized hierarchical signaling and traffic flow. These heirarchical routers could rebuild the binding update with a tiered address and use the domains keys i.e. the keys that routers already use to trust each other for the AH. Routers in the visited and in other domains that are not configured to care about mobility binding simply forward the packet towards the CN's address I.e. they are not configured to "recognize" the particular function. Only when the binding update exits a domain into another domain i.e. the keys change, the border router again intercepts and recomputes the binding update using the keys appropriate for the particular border. This process is continued until the binding update arrives at either the CN itself or a last hop router in the event they want route optimized location privacy. If the BU is sent to the CN, it is assumed that that CN has some security association with the subnet where it resides and it trusts the keys of that subnet. Perhaps the CN can simply trust the subnet routers without an SA - just as it currently does for ICMP singaling. The advantage of this method are: - It re-uses the existing binding update i.e. we don't burn more air bandwidth. We leverage the existing binding updates. - It provides the most route optimal form of hierarchical mobility. - It re-uses the existing security associations that SHOULD exist between domains, internal routers and hosts. - If one heirarchical router dies other communications and hierarchical bindings for other communications that mobile is engaged in continue un-affected. - It does not interfere with the natural routing policy of the domains. - It seems to match up well and re-uses the same mechanisms used to monitor bandwidth and signal CoS. The disadvantages that I see is: - It makes some of the intermediary routers do extra signaling; however if you really understand what will have to happen for real time communications such as DSCP schema's changing between administrative domains, you will see that this work will be occuring anyway. Why send more than one packet to get the job done? - I agree it is not needed for best effort unless the excuse it to solve the security association problems. Another approach might be to send binding updates to the visited subnet anycast addresses and chain the message up the network i.e. MN subnet to site, site to site, site to CN subnet and then to CN. Is this clear? It seems to me that doing something like this would resolve many issues. One thing I really can't understand with both of your proposed hierarchical solutions is why you want to send more than one binding update. This burns the air resources. The whole idea for doing heirarchical was to reduce signaling latency for cellular. These networks are the only networks that I am aware of that someone might be moving so fast as to warrant a heirarchical scheme. The solutions seem to conflict with requirements. The last thing I would like to say that it seems we are spending way to much time on something that provides so little gain. Light travels very fast. Thanks, Glenn Glenn -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, March 14, 2001 5:38 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Comments on Regional Registration Hello Hesham, We want to get the routing part figured out, and I believe we have a pretty good handle on it. Setting up security will allow a mobile node to provide authentication data that can be checked by one of the anycast group members. I know several ways to do that. It will be more productive to start on that task once two other things are out of the way: - Fixing the authentication mechanism for base Mobile IPv6 - Getting the routing part figured out. If you wish to disqualify all anycast-based solutions because there are no standards for establishing security between a node and the members of an anycast group, then I would just prefer to say that we believe the problem is wholly solvable for the particular anycast group we have designed. We don't intend to get in the business of solving it for the general case. Regards, Charlie P. "Hesham Soliman (ERA)" wrote: > Hello Charlie, > > > > > > GM> I agree, I support anycast too. To vilify a solution which employs > > > it as magic was wrong and I apologize. > > > > No need for apology, but I wanted to point out that this particular > > use of anycast is easy to implement, assuming that one's IPv6 > > implementation supports anycast at all. > > > => I'm a bit confused by this statement. How can it be easy > to implement a BU to an anycast address ? > BUs have to be secured with AH, so how can you setup this > security association when there are no standards defined > to do so ? > > Regards, > Hesham ------_=_NextPart_001_01C0AD60.71F71DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: Comments on Regional Registration

Hesham and Charlie,

I'm not too worried about the security association = issue with anycast. I think anycast is extremely useful and is here to = stay. It is part of IPv6 - might as well take advantage of it. =

I believe the SA establishment and scaling problem = for MIP, in general, has scaling and speed issues. It would actually = probably be more productive for us to focus on that issue than = heirarchical models. It seems people have focused so far on = "database in the sky" solutions with AAA protocols to = this.

I have an alternate idea which I would like to bring = up again.

Why don't we use a hop by hop option to alert = mobile-aware routers to the binding updates. For instance, a mobile = could send a binding update to a CN and it would be intercepted by the = 1st hop router in the visited domain.

If the visited domain wanted to support hierarchical, = other routers along the natural routing path to the CN would be = configured to care as well at whatever topological tier the provider = deemed necessary. These hirearchical routers could install a per-host = route in the binding cache to achieve route both optimized hierarchical = signaling and traffic flow.

These heirarchical routers could rebuild the binding = update with a tiered address and use the domains keys i.e. the keys = that routers already use to trust each other for the AH. Routers in the = visited and in other domains that are not configured to care about = mobility binding simply forward the packet towards the CN's address = I.e. they are not configured to "recognize" the particular = function.

Only when the binding update exits a domain into = another domain i.e. the keys change, the border router again intercepts = and recomputes the binding update using the keys appropriate for the = particular border.

This process is continued until the binding update = arrives at either the CN itself or a last hop router in the event they = want route optimized location privacy. If the BU is sent to the CN, it = is assumed that that CN has some security association with the subnet = where it resides and it trusts the keys of that subnet. Perhaps the CN = can simply trust the subnet routers without an SA - just as it = currently does for ICMP singaling.

The advantage of this method are:

- It re-uses the existing binding update i.e. we = don't burn more air bandwidth. We leverage the existing binding = updates.

- It provides the most route optimal form of = hierarchical mobility.
- It re-uses the existing security associations that = SHOULD exist between domains, internal routers and hosts.
- If one heirarchical router dies other = communications and hierarchical bindings for other communications that = mobile is engaged in continue un-affected.

- It does not interfere with the natural routing = policy of the domains.
- It seems to match up well and re-uses the same = mechanisms used to monitor bandwidth and signal CoS.

The disadvantages that I see is:

- It makes some of the intermediary routers do extra = signaling; however if you really understand what will have to happen = for real time communications such as DSCP schema's changing between = administrative domains, you will see that this work will be occuring = anyway. Why send more than one packet to get the job done?

- I agree it is not needed for best effort unless the = excuse it to solve the security association problems.

Another approach might be to send binding updates to = the visited subnet anycast addresses and chain the message up the = network i.e. MN subnet to site, site to site, site to CN subnet and = then to CN.

Is this clear? It seems to me that doing something = like this would resolve many issues.

One thing I really can't understand with both of your = proposed hierarchical solutions is why you want to send more than one = binding update. This burns the air resources. The whole idea for doing = heirarchical was to reduce signaling latency for cellular. These = networks are the only networks that I am aware of that someone might be = moving so fast as to warrant a heirarchical scheme. The solutions seem = to conflict with requirements.

The last thing I would like to say that it seems we = are spending way to much time on something that provides so little = gain. Light travels very fast.

Thanks,

Glenn




Glenn

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Wednesday, March 14, 2001 5:38 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Re: Comments on Regional = Registration


Hello Hesham,

We want to get the routing part figured out, and I = believe
we have a pretty good handle on it.

Setting up security will allow a mobile node to = provide
authentication data that can be checked by one of = the
anycast group members.  I know several ways to = do that.
It will be more productive to start on that task = once two
other things are out of the way:
- Fixing the authentication mechanism for base = Mobile IPv6
- Getting the routing part figured out.

If you wish to disqualify all anycast-based solutions = because
there are no standards for establishing security = between a
node and the members of an anycast group, then I = would
just prefer to say that we believe the problem is = wholly
solvable for the particular anycast group we have = designed.
We don't intend to get in the business of solving it = for the
general case.

Regards,
Charlie P.



"Hesham Soliman (ERA)" wrote:

>         = Hello Charlie,
>
> >
> > > GM> I agree, I support anycast = too. To vilify a solution which employs
> > > it as magic was wrong and I = apologize.
> >
> > No need for apology, but I wanted to point = out that this particular
> > use of anycast is easy to implement, = assuming that one's IPv6
> > implementation supports anycast at = all.
> >
>         = =3D> I'm a bit confused by this statement. How can it be easy
>         = to implement a BU to an anycast address ?
>         = BUs have to be secured with AH, so how can you setup this
>         = security association when there are no standards defined
>         = to do so ?
>
>         = Regards,
>         = Hesham

------_=_NextPart_001_01C0AD60.71F71DE0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 16:42:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08757 for ; Thu, 15 Mar 2001 16:42:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20588; Thu, 15 Mar 2001 13:42:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19918; Thu, 15 Mar 2001 13:42:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLeaIm006650 for ; Thu, 15 Mar 2001 13:40:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FLeaDf006649 for mobile-ip-dist; Thu, 15 Mar 2001 13:40:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLeVIm006642 for ; Thu, 15 Mar 2001 13:40:32 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00557 for ; Thu, 15 Mar 2001 16:40:30 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00701 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 16:40:34 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FFEbIm005252 for ; Thu, 15 Mar 2001 07:14:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09127 for ; Thu, 15 Mar 2001 07:14:37 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13226 for ; Thu, 15 Mar 2001 07:14:37 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 15 Mar 2001 09:08:02 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 09:07:56 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301855143@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6 Date: Thu, 15 Mar 2001 09:07:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD61.B562D500" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AD61.B562D500 Content-Type: text/plain; charset="iso-8859-1" I had the same comment about the location privacy. One could say it provides a little better location privacy but that's about it. They might know the city or building that your in as apposed to a room. -----Original Message----- From: Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk] Sent: Wednesday, March 14, 2001 7:12 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Some questions on Hierarchical MIPv6 Hi all, I would appreiciate if the HMIP authors could shed some light in some statements in the hmipv6-02 draft that got out recently. In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP. The question is which one the home address or the onlink (LCoA)? If a MAP is serving as a mobile AR you enforce that it must advertise its and all MAP options available. Does that imply that the 'preference' is specific here? Further (page 20, top statement) you state that this would allow the MN to obtain a new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA). The reason I ask here is because you state that in the extended mode the MN is bound to use the mobile AR/MAP IP address. Also you state that the MN should send a BU to the (further ???) MAP to bind its Home Addr with the MR's CoA. Can you explain why you need to do that? Do you mean by further, a MAP higher (upstream) in the routing hierarchy? How can you possibly have location privacy if the upstream packets have as their source address the MNs LCoA. If you do not have the LCoA as the source address, then start praying over egress filtering. If you have load balancing effected which RCoA do you send back to the HA? Regs. Theo UCL / Mobile systems ------_=_NextPart_001_01C0AD61.B562D500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Some questions on Hierarchical MIPv6

I had the same comment about the location privacy. = One could say it provides a little better location privacy but that's = about it. They might know the city or building that your in as apposed = to a room.

-----Original Message-----
From: Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk= ]
Sent: Wednesday, March 14, 2001 7:12 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Some questions on Hierarchical = MIPv6


Hi all,

   I would appreiciate if the HMIP authors = could shed some light in some statements
in the hmipv6-02 draft that got out recently.


In extended mode you state that the MN should use as = CoA (ACoA) the IP of the MAP.
The question is which one the home address or the = onlink (LCoA)?


If a MAP is serving as a mobile AR you enforce that = it must advertise its and all
MAP options available. Does that imply that the = 'preference' is specific here?

Further (page 20, top statement) you state that this = would allow the MN to obtain a
new topologically correct RCoA. Do you really mean = RCoA or CoA (i.e. LCoA). The
reason I ask here is because you state that in the = extended mode the MN is bound to
use the mobile AR/MAP IP address.

Also you state that the MN should send a BU to the = (further ???) MAP to bind its
Home Addr with the MR's CoA. Can you explain why you = need to do that? Do you mean
by further, a MAP higher (upstream) in the routing = hierarchy?

How can you possibly have location privacy if the = upstream packets have as their
source address the MNs LCoA. If you do not have the = LCoA as the source address,
then start praying over egress filtering.

If you have load balancing effected which RCoA do you = send back to the HA?


Regs.


Theo

UCL / Mobile systems



------_=_NextPart_001_01C0AD61.B562D500-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 16:46:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08829 for ; Thu, 15 Mar 2001 16:46:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00289; Thu, 15 Mar 2001 13:46:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19779; Thu, 15 Mar 2001 13:46:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLisIm006712 for ; Thu, 15 Mar 2001 13:44:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FLis3J006711 for mobile-ip-dist; Thu, 15 Mar 2001 13:44:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLiiIm006704 for ; Thu, 15 Mar 2001 13:44:44 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01247 for ; Thu, 15 Mar 2001 16:44:43 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA00784 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 16:44:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FGBPIm005311 for ; Thu, 15 Mar 2001 08:11:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26065 for ; Thu, 15 Mar 2001 08:11:25 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05210 for ; Thu, 15 Mar 2001 08:11:24 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2FGBMC24629 for ; Thu, 15 Mar 2001 17:11:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 15 17:13:05 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 17:07:21 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC78@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 17:09:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Frank, > > => I'm not at all trying to discredit anycastl. I'm just > > wondering how you could use it in light of the current > > standards. You still didn't tell me what the solution > > is. > > Proposing a solution for setting up an SA with an > > anycast group would be a great proposal, but > > I don't think we need several standards to solve > > this particular problem. We already have a solution > > and I'm starting to question the need for alternatives > > if nothing is raised against HMIPv6. Especally if > > the alternative is a lot less robust and overrides > > the use of standard routing between the anchor point > > and the MN. > > > > actually that there are different proposals on the way to set up Security > Associations and to authenticate the BU using AH in Appendix B of the draft. > => Yes I saw that, but this is hardly a standard or an accepted method, I don't think we can base it on the appendix surely. Even if we can, my main point is why are we adding all this complication to achieve the same effect that HMIPv6 does ? I haven't heard an answer till now. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:01:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09080 for ; Thu, 15 Mar 2001 17:01:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29792; Thu, 15 Mar 2001 14:01:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07695; Thu, 15 Mar 2001 14:00:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLxZIm006816 for ; Thu, 15 Mar 2001 13:59:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FLxYw5006815 for mobile-ip-dist; Thu, 15 Mar 2001 13:59:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FLxTIm006808 for ; Thu, 15 Mar 2001 13:59:30 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25452 for ; Thu, 15 Mar 2001 16:59:28 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA01089 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 16:59:33 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FGHYIm005340 for ; Thu, 15 Mar 2001 08:17:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19885 for ; Thu, 15 Mar 2001 08:17:34 -0800 (PST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21671 for ; Thu, 15 Mar 2001 09:17:33 -0700 (MST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 15 Mar 2001 10:12:17 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 10:17:21 -0600 Message-ID: <9A9367D1556AD21182C40000F80930AB025E56B0@crchy28b.us.nortel.com> From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Charles.Perkins@nokia.com Subject: RE: [mobile-ip] An analysis of the fastv6 draft. Date: Thu, 15 Mar 2001 10:17:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD6B.67EB8C90" X-Orig: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AD6B.67EB8C90 Content-Type: text/plain; charset="iso-8859-1" Hi Rajeev, Thanks for your useful comments. according to my knowledge the design team will discuss similar issues to the issues you raised in our meeting at IETF. Thx MK -----Original Message----- From: rajeev.koodli@nokia.com [mailto:rajeev.koodli@nokia.com] Sent: Tuesday, March 13, 2001 6:41 PM To: mobile-ip@sunroof.eng.sun.com Cc: rajeev.koodli@nokia.com; Charles.Perkins@nokia.com Subject: [mobile-ip] An analysis of the fastv6 draft. > Hello George, and fellow MIPv6 folks, > > I have done a simple analysis of the design team's fastv6 draft. I may > have missed something in the draft. If so, I would be happy to know it. I > would appreciate your comments. > > Regards, > > -Rajeev > > > > <> > > > - Rajeev.Koodli@nokia.com > > Nokia Research Center > 313 Fairchild Drive > Mountain View, CA 94043 > +1 650 625 2359 > > ------_=_NextPart_001_01C0AD6B.67EB8C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] An analysis of the fastv6 draft.

Hi Rajeev,

Thanks for your useful comments. according to my = knowledge the design team will discuss similar issues to the issues you = raised in our meeting at IETF.

Thx

MK

-----Original Message-----
From: rajeev.koodli@nokia.com [mailto:rajeev.koodli@nokia.com]
Sent: Tuesday, March 13, 2001 6:41 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: rajeev.koodli@nokia.com; = Charles.Perkins@nokia.com
Subject: [mobile-ip] An analysis of the fastv6 = draft.




> Hello George, and fellow MIPv6 folks,
>
> I have done a simple analysis of the design = team's fastv6 draft. I may
> have missed something in the draft. If so, I = would be happy to know it. I
> would appreciate your comments.
>
> Regards,
>
> -Rajeev
>
>
>
>  <<fastv6-comments.txt>> =
>
>
> - Rajeev.Koodli@nokia.com
>
> Nokia Research Center
> 313 Fairchild Drive
> Mountain View, CA 94043
> +1 650 625 2359
>
>

------_=_NextPart_001_01C0AD6B.67EB8C90-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:05:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09202 for ; Thu, 15 Mar 2001 17:05:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19835; Thu, 15 Mar 2001 14:05:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23559; Thu, 15 Mar 2001 14:05:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FM3gIm006893 for ; Thu, 15 Mar 2001 14:03:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FM3fnb006892 for mobile-ip-dist; Thu, 15 Mar 2001 14:03:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FM3aIm006885 for ; Thu, 15 Mar 2001 14:03:37 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26170 for ; Thu, 15 Mar 2001 17:03:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01225 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:03:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHSnIm005473 for ; Thu, 15 Mar 2001 09:28:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29169 for ; Thu, 15 Mar 2001 09:28:45 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAB00795 for ; Thu, 15 Mar 2001 09:28:43 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2FHSgd08500 for ; Thu, 15 Mar 2001 18:28:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 15 18:27:30 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 18:28:42 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6 Date: Thu, 15 Mar 2001 18:28:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Theo, Sorry if another one of the authors already answered this but it's hard to know, given the list's current state. If someone else answered then hopefully the answers are the same :) Please see my response below Regards, Hesham > I would appreiciate if the HMIP authors could shed some light in some statements > in the hmipv6-02 draft that got out recently. > > > In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP. > The question is which one the home address or the onlink (LCoA)? > => Is there an "ACoA" in the draft ? If so it's a typo. I don't really understand your question. In extended mode the mobile node uses the MAP's advertised address as an alternate-CoA, oh I see what you meant by ACOA ! So I still don't get your last statement. The source address in the IP packets is the LCoA. The address shown to the appliccations is the Home Address. The address that the CN/HA has in their binding cache is the alternate-CoA (MAP's address). Have I confused you more ? > If a MAP is serving as a mobile AR you enforce that it must advertise its and all > MAP options available. Does that imply that the 'preference' is specific here? > => The preference is either configured in the MAP or a default behaviour that varies with loading ...etc. Each MAP can have its own preference value independantly from other MAPs > Further (page 20, top statement) you state that this would allow the MN to obtain a > new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA). > => We mean RCoA. The RCoA is the address provided by the MAP, regardless of which mode it operates in. So for Basic mode the RCoA is the address that the MN forms on the MAP's subnet. In extended mode the RCoA is the MAP's IP address. > The > reason I ask here is because you state that in the extended mode the MN is bound to > use the mobile AR/MAP IP address. > => Yes, this is to make sure it receives packets. > Also you state that the MN should send a BU to the (further ???) MAP to bind its > Home Addr with the MR's CoA. > > > Can you explain why you need to do that? Do you mean > => For the same reason you need HMIPv6 at all. Reduce signalling and help speed up the handover by updating a node close to the MN. > by further, a MAP higher (upstream) in the routing hierarchy? > => Yes. > How can you possibly have location privacy if the upstream packets have as their > source address the MNs LCoA. > => Which mode are you referring to now ? We don't claim location privacy for Extended mode, but for Basic mode you can use the RCoA as a source address. That's how you get it. > If you do not have the LCoA as the source address, > then start praying over egress filtering. > => If I pray, I usually pray for better things ;) MANY networks don't use it. Anyhow we've dicovered that there is a need for the network to inform the MN whether the use of RCoA is possible or not. We added that in the draft and Claude will post that on the INRIA web page soon. > If you have load balancing effected which RCoA do you send back to the HA? > => Load balancing is done by the MAP, you only need to send one RCoA to the HA. Did you mean something else ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:13:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09269 for ; Thu, 15 Mar 2001 17:13:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05429; Thu, 15 Mar 2001 14:12:40 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25186; Thu, 15 Mar 2001 14:11:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMAFIm006997 for ; Thu, 15 Mar 2001 14:10:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMAEGL006996 for mobile-ip-dist; Thu, 15 Mar 2001 14:10:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMA9Im006989 for ; Thu, 15 Mar 2001 14:10:10 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27218 for ; Thu, 15 Mar 2001 17:10:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01385 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:10:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHTUIm005485 for ; Thu, 15 Mar 2001 09:29:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29313 for ; Thu, 15 Mar 2001 09:29:15 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14963 for ; Thu, 15 Mar 2001 10:29:14 -0700 (MST) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA21455; Thu, 15 Mar 2001 09:29:12 -0800 (PST) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA22423; Thu, 15 Mar 2001 12:29:05 -0500 (EST) Date: Thu, 15 Mar 2001 12:29:05 -0500 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Cc: Madhavi W Subbarao Subject: [mobile-ip] Draft NAI/multiple static IP Message-ID: <20010315122905.A22409@cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Z5djTAD1cGYuMQKO" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --Z5djTAD1cGYuMQKO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, We submitted a draft detailing functionality for support of a single NAI and multiple static IP flows. For some reason, no announcement yet, so here's the link http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-multipleip-00.txt Thanks! -Madhavi --Z5djTAD1cGYuMQKO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-subbarao-mobileip-multipleip-00.txt" INTERNET DRAFT Kent Leung Category: Individual submission Cisco Systems Title: draft-subbarao-mobileip-multipleip-00.txt Madhavi Subbarao Expires Septemer 2001 Cisco Systems Mobile IP Working Group Mobile IP NAI with Multiple Static IP Address Flows draft-subbarao-mobileip-multipleip-00.txt Status of this Memo This document is an Internet Draft and is in full compliance with all provisions of Section 10 of RFC2026. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A Network Access Identifier can be added to a Mobile IP Registration Request to identify a user. Users may want to open several simultaneous sessions using the same NAI from the same or different devices with a unique IP address for each session. The functionality defined in this draft can be used to allow multiple static IP address flows using the same NAI. 1. Introduction A Mobile IP Registration Request may carry a Network Access Identifier (NAI) [1,2] that serves to identify the user requesting access to the network. The NAI is used to also identify the necessary security assocation with the Home Agent (HA) or AAA server. With the abundance of mobile devices, a given user may want to open multiple, simultaneous Mobile IP sessions/services from the same or different devices. Currently, an NAI can only support a single Mobile IP flow. In this draft, we specify the functionality to allow for multiple static IP address flows using the same NAI. A mobility binding is then identified by the combination of NAI and MN home IP address. The functionality specified herein defines the behavior to support multiple static IP address flows using the same NAI in a wireless network deployment using Mobile IP, e.g., in a cdma2000 network [3]. 2. Mobile Node Considerations In order to support multiple IP address flows for an NAI, the Mobile Node (MN) and HA (or Home AAA server) MUST be preconfigured with valid static home IP addresses that the MN may use to register with the HA. The MN SHOULD send a Registration Request (RRQ) with its NAI and one of these valid static home IP addresses to the HA. Upon receipt of a Registration Reply (RPY), MN MUST use the home IP address returned by the HA for any subsequent RRQs pertaining to that session. If there is an error in the RPY, the MN MUST proceed as outlined in [4]. 3. Foreign Agent Considerations If an FA receives an RRQ from an MN with an NAI and an MN home address, the FA SHOULD index its pending registration records using the combination of NAI/MN home address. Upon receipt of an RPY from an HA, the FA SHOULD search its pending registration table based on NAI/MN home address pair. If it does not find an entry in this way, it SHOULD search the table based on the NAI and low-order 32 bits of the Identifier field in the RPY (this provides backward compatibility for dynamic address allocation using NAI and also if another authorized MN home address is returned by the HA). 4. Home Agent Considerations If an HA receives an RRQ with an NAI Extension and MN home address, the HA MUST first authenticate the RRQ as usual [1,3]. The HA MUST then check the validity of the MN home address against the preconfigured home IP addresses for the MN. The HA MAY authorize the MN home addresses against addresses configured via AAA or a local pool. If the MN home address included in the RRQ is not an authorized home address for the MN, the HA MUST reject the RRQ with error code 129 (administratively prohibited) as given in [4]. If the MN home address is authorized but already being used, and another valid home address for the MN is available, the HA MUST either return this address in its RPY or reject the RRQ with error code 130 (insufficient resources) as given by [4]. If another valid home address for the MN is not available, the HA MUST reject the RRQ with error code 130 (insufficient resources) as given by [4]. If an HA receives a re-registration from an MN, the HA MUST authorize the MN address as above and check that the MN address is the same address as in the existing mobility binding. 5. IANA Considerations This draft does not directly affect IANA. 6. Security Considerations Mobile IP registration messages are authenticated, and the authentication verified by the recipient. The static home addresses used by an MN are authorized by the HA as a valid home address for the MN. 7. IPv6 Considerations As with the NAI extension for Mobile IP [1], support for multiple static IP flows with NAI in IPv6 is outside the scope of this document. Any of the methods suggested there for creating an attendant function in the visited network could also make use of the functionality described in this draft to support multiple, static IP address flows/sessions. 8. Acknowledgements The authors would like to thank Roy Jose and Anand Sundaresh Natarajan for their insightful comments on the functionality specified in this draft. 9. References [1] P. Calhoun and C. Perkins, Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, Internet Engineering Task Force, March 2000. [2] B. Aboba and M. Beadles, The Network Access Identifier. RFC 2486, Internet Engineering Task Force, January 1999. [3] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000. [4] C. Perkins, IP Mobility Support for IPv4, revised, Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip-rfc2002-bis-01.txt, Work in progress, January 2000. Author's Addresses Questions about this memo can be directed to: Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA email: kleung@cisco.com phone: +1 408 526 5030 fax: +1 408 526 4952 Madhavi Subbarao Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA email: msubbara@cisco.com phone: +1 919 392 8387 Expires September 2001 --Z5djTAD1cGYuMQKO-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:19:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09308 for ; Thu, 15 Mar 2001 17:19:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03955; Thu, 15 Mar 2001 14:18:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29433; Thu, 15 Mar 2001 14:18:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMHIIm007063 for ; Thu, 15 Mar 2001 14:17:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMHIT1007062 for mobile-ip-dist; Thu, 15 Mar 2001 14:17:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMHCIm007053 for ; Thu, 15 Mar 2001 14:17:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06532 for ; Thu, 15 Mar 2001 17:17:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01526 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:17:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FHi4Im005519 for ; Thu, 15 Mar 2001 09:44:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03149 for ; Thu, 15 Mar 2001 09:44:04 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19224 for ; Thu, 15 Mar 2001 09:44:04 -0800 (PST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA09576; Thu, 15 Mar 2001 12:44:03 -0500 (EST) Message-ID: <3AB0FF62.592DA0A1@cs.columbia.edu> Date: Thu, 15 Mar 2001 12:44:02 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Dave Oran , rcoltun@redback.com Subject: Re: [mobile-ip] Question to Chairs re: QoS References: <15024.9028.54884.980740@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit It would probably be more helpful if that discussion would also first take place in the next-generation signaling BOF at the IETF meeting. There is a special list for the discussion of signaling issues in a broader context, not just MIP. See http://lists.cs.columbia.edu/mailman/listinfo/siglite (This activity is coordinated with the respective ADs, although they are obviously not responsible for the opinions presented on the mailing list...) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:32:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09460 for ; Thu, 15 Mar 2001 17:32:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17225; Thu, 15 Mar 2001 14:32:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14923; Thu, 15 Mar 2001 14:32:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMUBIm007137 for ; Thu, 15 Mar 2001 14:30:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMUBBh007136 for mobile-ip-dist; Thu, 15 Mar 2001 14:30:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMU6Im007129 for ; Thu, 15 Mar 2001 14:30:06 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00609 for ; Thu, 15 Mar 2001 17:30:03 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01777 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:30:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FI35Im005670 for ; Thu, 15 Mar 2001 10:03:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20007 for ; Thu, 15 Mar 2001 10:03:04 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08099 for ; Thu, 15 Mar 2001 10:03:04 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18679; Thu, 15 Mar 2001 10:03:22 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACI13011; Thu, 15 Mar 2001 10:02:59 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA23301; Thu, 15 Mar 2001 10:02:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.979.524757.614264@thomasm-u1.cisco.com> Date: Thu, 15 Mar 2001 10:02:59 -0800 (PST) To: Cc: mobile-ip@sunroof.eng.sun.com, mat@cisco.com Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0321367F@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B0321367F@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com writes: > Why is the MIP WG not the place to work on QoS aspects that are > related to mobility, especially from a Mobile IP perspective? Where > else in the IETF would you believe this work needs to be done? Because it is not just related to MIP! All of the routers and correspondent nodes would need to implement this scheme as well. Also: it is *far* too premature to throw in the towel on RSVP. > >I have volunteered to discuss my analysis (draft- > >thomas-seamoby-rsvp-analysis-00) and will do so > >again at this point, but even if you don't take me > >up on this, I cannot see what will be productive > >about discussing this draft for the second IETF > >in a row: all of the same arguments of scope > >and wholesale reinvention apply. > > > > I believe the authors of the chaskar I-D have addressed some of the > concerns that you have raised on the mailing list. We welcome your > input and discussion on the issues. > I do not believe there is any "wholesale reinvention" being proposed > in the chaskar draft. It is specifically targeted for Mobile IPv6 and > is addressing a specific problem. As far as I can tell, there are a huge number of things that are not addressed by the draft which are extremely important to both fixed and mobile IP. In order to support them would certainly require a fair if not huge amount of reinvention. Also: anything that claims "situation X is different, therefore..." should always be viewed with a great deal of skepticism. IETF protocols are usually a lot more general purpose than people give them credit for. That's why I think that the right thing for the next IETF is to actually start gathering requirements and analysing the current state of affairs with current protocols. Solution space presentations are, IMO, a waste of time. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:36:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09557 for ; Thu, 15 Mar 2001 17:36:45 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18294; Thu, 15 Mar 2001 14:36:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16311; Thu, 15 Mar 2001 14:36:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMZRIm007229 for ; Thu, 15 Mar 2001 14:35:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMZQgu007228 for mobile-ip-dist; Thu, 15 Mar 2001 14:35:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMZMIm007221 for ; Thu, 15 Mar 2001 14:35:22 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10039 for ; Thu, 15 Mar 2001 17:35:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01878 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:35:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FIsPIm005836 for ; Thu, 15 Mar 2001 10:54:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03102 for ; Thu, 15 Mar 2001 10:54:25 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11973 for ; Thu, 15 Mar 2001 11:54:23 -0700 (MST) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA24686; Thu, 15 Mar 2001 10:54:41 -0800 (PST) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22577; Thu, 15 Mar 2001 13:54:14 -0500 (EST) Date: Thu, 15 Mar 2001 13:54:13 -0500 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Cc: Waseem Siddiqi Subject: [mobile-ip] Re: mobile-ip] Mobile IP on Windows ? Message-ID: <20010315135413.A22573@cisco.com> References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010314192547.B18619@mymlan.lifix.fi> <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com>; from wsiddiqi@cisco.com on Wed, Mar 14, 2001 at 01:47:07PM -0800 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Waseem, MIPv4 implementation on Windows: Ecutel IKV NetSeal - not sure if it's available yet Birdstep - coming soon IPUnplugged - coming soon -Madhavi On Wed, Mar 14, 2001 at 01:47:07PM -0800, Waseem Siddiqi wrote: > hi, > > anyone know of a working MIPv4 implementation on Windows ? > Microsoft is only working on MIPv6 and I know NUS has an alpha version of > their MIPv4 that > they have stopped working on. > > thanks > waseem From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:40:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09625 for ; Thu, 15 Mar 2001 17:40:24 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25570; Thu, 15 Mar 2001 14:40:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17101; Thu, 15 Mar 2001 14:40:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMcnIm007294 for ; Thu, 15 Mar 2001 14:38:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMcnLx007293 for mobile-ip-dist; Thu, 15 Mar 2001 14:38:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMciIm007286 for ; Thu, 15 Mar 2001 14:38:45 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10659 for ; Thu, 15 Mar 2001 17:38:45 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA01954 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:38:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FJZlIm006039 for ; Thu, 15 Mar 2001 11:35:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02783 for ; Thu, 15 Mar 2001 11:35:46 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07576 for ; Thu, 15 Mar 2001 11:35:45 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2FJZid07032 for ; Thu, 15 Mar 2001 20:35:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 15 20:37:29 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 20:31:44 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Thu, 15 Mar 2001 20:35:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Jari, > > You're absolutely right. That's exactly what we have been avoiding > > in the HMIPv6 work. There is no need for a non-robust solution > > that intrduces a tree of single points of failures. As you said > > network administrators can force routes to introduce this effect > > if they want their networks to be less robust for other reasons. > > Or regreg6 configurator can freely decide on the number of hierarchy > levels according to his needs, including having one only. And, I > do not believe it impossible to have dynamic configuration option > for regreg6, it is something extra to natural routing, but doable. > => Great, but that makes it like HMIPv6, so where is the advantage ? apart from a different name :) > In fact, having some redundancy in mobility binding state in the > hierarchy may help reconstructing the state once a regional router > goes down. Once a MAP goes down, you'll need some effort to set > up those forwarding entries to the tunnels for mobile nodes under it. > => What happens when a GMA goes down ? A GMA is very similar to an Extended mode MAP, so I don't see the redundancy argument valid. BTW, you claim redundancy in the hierarchy when using Regional, how does that happen ? Anycast (if it works) does not give you redundancy since the BU will be received by _one_ router. Furthermore, what is the point in providing a redundant hierarchy if the GMA is a single point of failure ? > Simply moving the regional CoAs to anothe box is not enough. > => Why ? > In a > scalable solution, I do not believe timeout and full re-registration > in every case for every mobile node is all that can be done, either. > => You don't need re-registration in the basic mode case. The connections will remain unscathed. That is provided we do have a redundancy protocol. > > So far I haven't heard *any* reason for it [multiple levels of hierarchy]. > > Consider the following: Some users of a localized mobility scheme > consider bandwidth of the last mile a very precious resource. > They may also envision that the number of mobile nodes can be > very large. In fact, so large that one MAP box is not enough to > handle the signaling load of a visite domain. > => We can support several MAPs in the visited domain. Does the current HMIPv6 draft restrict that ? If so please let us know where, because it shouldn't. > Suppose the last mile is so precious that we can't use but one > RCoA/MAP option on the router advertisement. How would the > load balancing with MAP work? > => I don't see that BW argument as valid at all. You can have more than one option in the RA. RAs are not meant to be sent very frequently in HMIPv6, please refer to the Fast Handoffs draft where RAs are sent when the MN is about to move. Load balancing still works regardless of how many options are advertised. It is done from the same MAP. Or are you referring to load sharing between MAPs ? > If we can distribute load to more than one box by > maintaining e.g. one level of lower routers, locality of movement > naturally brings location update signaling load down to other > boxes from a GMA. When simultaneously increasing the number of > mobile nodes, I believe the signaling difference becomes > significant. > => I don't see any difference here. In fact, restricting the solution to one GMA in reg registration is very unscalable and requires a big expensive router with extra cost for reliability. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 17:56:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09881 for ; Thu, 15 Mar 2001 17:56:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26088; Thu, 15 Mar 2001 14:54:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06938; Thu, 15 Mar 2001 14:54:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMqkIm007421 for ; Thu, 15 Mar 2001 14:52:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMqkSM007420 for mobile-ip-dist; Thu, 15 Mar 2001 14:52:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMqfIm007413 for ; Thu, 15 Mar 2001 14:52:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04019 for ; Thu, 15 Mar 2001 17:52:41 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA02231 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:52:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FJmiIm006096 for ; Thu, 15 Mar 2001 11:48:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18018 for ; Thu, 15 Mar 2001 11:48:43 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21427 for ; Thu, 15 Mar 2001 11:48:42 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2FJmfC23684 for ; Thu, 15 Mar 2001 20:48:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 15 20:50:25 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 20:48:40 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC7E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Thu, 15 Mar 2001 20:48:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sorry to jump in as you were addressing Glenn, but I have to correct some misunderstandings about HMIPv6. > > Hello, > > > > I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. > > Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings > we introduce state used in a similar way as state used for maintaining > plain next hop forwarding. > => The next hop forwarding in the MAP depends on the routing protocols in the domain. The next hop forwarding in Regional is forced (like a static route). There is a big difference. You might ague that reg6 is part of MIP, hence can be classified as a routing protocol, but I would say that any routing protocol that reserves a "circuit-like" path in the IP network is not acceptable. > I read your use of term connection-oriented to > mean the use of mobility bindings for forwarding instead of exclusively relying on host/network/default routes. Introducing robustness > in this form of forwarding is a problem both HMIP and regreg6 face. > In fact, even basic Mobile IPv6 while forwarding packets via the > home agent has this feature. > => The robustness in terms of introducing a single point of failure may be similar, but adding a less robust path to the MN from the GMA is not acceptable, and clearly this is not just my opinion. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:00:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09974 for ; Thu, 15 Mar 2001 18:00:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14710; Thu, 15 Mar 2001 14:59:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07895; Thu, 15 Mar 2001 14:59:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMwBIm007491 for ; Thu, 15 Mar 2001 14:58:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FMwBeW007490 for mobile-ip-dist; Thu, 15 Mar 2001 14:58:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMw6Im007483 for ; Thu, 15 Mar 2001 14:58:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13760 for ; Thu, 15 Mar 2001 17:58:07 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA02340 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:58:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FK7RIm006197 for ; Thu, 15 Mar 2001 12:07:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10915 for ; Thu, 15 Mar 2001 12:07:27 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26056 for ; Thu, 15 Mar 2001 12:07:26 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2FK7NC26180 for ; Thu, 15 Mar 2001 21:07:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 15 21:09:07 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 21:03:23 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC81@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 21:07:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > > - Getting the routing part figured out. > > > > > => I don't understand what needs to be solved on the > > routing aspect of the problem ? Do you not like > > the routing provided by HMIPv6 ? If so why ? > > I think it's important to support more than one level of > regionalized care-of address, at least for the organization > of mobility management we have in mind for "All-IP" > networks. > => Ok, could you please give a reason for this ? How does All-IP come into this ? > I also like that anycast addressing allows the mobile node > to accomplish the regional binding update without having > to know about the topology of the visited domain. > => Knowing a unicast address does not imply knowledge of the topology. The MN knows the HA's address, does that imply that it is aware of the topology of the home network ? Anyway, we keep missing the point that the current reg6 draft does not work. We seem to miss that you can't setup an SA with an anycast address, but obviously this is not the only concern I have about the draft. > > => I'm not at all trying to discredit anycastl. I'm just > > wondering how you could use it in light of the current > > standards. You still didn't tell me what the solution > > is. > > Proposing a solution for setting up an SA with an > > anycast group would be a great proposal, but > > I don't think we need several standards to solve > > this particular problem. We already have a solution > > and I'm starting to question the need for alternatives > > if nothing is raised against HMIPv6. Especally if > > the alternative is a lot less robust and overrides > > the use of standard routing between the anchor point > > and the MN. > > Your statement is near tautological. Of course, we'd also > like to arrive at a robust protocol that uses as much > standard routing as is possible. > => So what is wrong with the current proposal ? > We also wish to allow > betterm localization of binding updates than HMIPv6 could > provide. That can translate into better scalability for the > foreseeable future. > => This statement is a bit vague. I'd also like to have a better solution than HMIPv6 or MIPv6 for that matter. Not because I think they're bad but because better is always good. The question is where is that better proposal ? and why is it better ? Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:05:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10043 for ; Thu, 15 Mar 2001 18:05:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19942; Thu, 15 Mar 2001 15:04:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09194; Thu, 15 Mar 2001 15:04:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FN3DIm007562 for ; Thu, 15 Mar 2001 15:03:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FN3DbK007561 for mobile-ip-dist; Thu, 15 Mar 2001 15:03:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FN37Im007554 for ; Thu, 15 Mar 2001 15:03:08 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14465 for ; Thu, 15 Mar 2001 18:03:04 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02439 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 18:03:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKTOIm006298 for ; Thu, 15 Mar 2001 12:29:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02856 for ; Thu, 15 Mar 2001 12:29:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02032 for ; Thu, 15 Mar 2001 12:29:19 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA05790 for ; Thu, 15 Mar 2001 12:29:18 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2FKTFb12142 for ; Thu, 15 Mar 2001 12:29:15 -0800 X-mProtect: Thu, 15 Mar 2001 12:29:15 -0800 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk") by darkstar.iprg.nokia.com(WTS.12.69) smtpd2CHv5c; Thu, 15 Mar 2001 12:29:06 PST Message-ID: <3AB12616.EC969825@cs.ucl.ac.uk> Date: Thu, 15 Mar 2001 12:29:10 -0800 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Request for comments on some work on proactive handovers in IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I forgot to say the scheme really pushes for UDP flows....basically what all the guys have been talking about real-time interactive multimedia... For TCP I have another strand of that.... :)))) And by the way bother to throw some stones at it apart from lauging.. Thanks Theo From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:08:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10095 for ; Thu, 15 Mar 2001 18:08:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23154; Thu, 15 Mar 2001 15:08:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23567; Thu, 15 Mar 2001 15:07:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FN6bIm007602 for ; Thu, 15 Mar 2001 15:06:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FN6biP007601 for mobile-ip-dist; Thu, 15 Mar 2001 15:06:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FN6PIm007588 for ; Thu, 15 Mar 2001 15:06:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09614 for ; Thu, 15 Mar 2001 15:06:22 -0800 (PST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08358 for ; Thu, 15 Mar 2001 15:06:07 -0800 (PST) Received: from shannon.research.telcordia.com (shannon [128.96.73.2]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f2FN61O24175 for ; Thu, 15 Mar 2001 18:06:01 -0500 (EST) Received: from macre2 (wmacre-pc.research.telcordia.com [128.96.72.225]) by shannon.research.telcordia.com (8.8.8/8.8.8) with SMTP id RAA25032 for ; Thu, 15 Mar 2001 17:56:11 -0500 (EST) Message-ID: <02f201c0ada3$1ef7e190$e1486080@cc.telcordia.com> From: "William R. Macre" To: References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010313224837.21080.qmail@web3102.mail.yahoo.com> <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com> <3AB081BB.E750868D@fokus.gmd.de> Subject: Re: [mobile-ip] Mobile IP on Windows ? Date: Thu, 15 Mar 2001 17:56:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm monitoring the messages on the MobileIP e-mail list and came across this request for MIP running on Windows. We are doing some research in 3GPP networking and would also be interested in this software. One question I have is " Is this software available as developers source for free or license(for fee)?" Bill Macre: ----- Original Message ----- From: "Reinhard Ruppelt" To: Sent: Thursday, March 15, 2001 3:47 AM Subject: Re: [mobile-ip] Mobile IP on Windows ? > Waseem Siddiqi wrote: > > > hi, > > > > anyone know of a working MIPv4 implementation on Windows ? > > Microsoft is only working on MIPv6 and I know NUS has an alpha version of > > their MIPv4 that > > they have stopped working on. > > > > thanks > > waseem > > We have one. Currently our W-NT Mobile IP code is subject to a revision. > Additionally > we are now implementing IPsec security features. Soon the resulting new > version will substitute the current one and be subject to marketing. > Please feel free to download the current version from > https://www.mobile-ip.de/~andrei/roamin/ (user: roamin, password: > oma6kech). > We would appreciate very much if you could give us information of the > planned deployment scenario and some feedback on your experiences. > Best regards, > Reinhard Ruppelt > > PS > A W-98 version is also available > > -- > GMD FOKUS / MOBIS > German National Research Center for Information Technology > - Institute for Open Communication Systems - > Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany > Voice: +49 30 3463-7249, Fax: -8249 > Email: Reinhard.Ruppelt@gmd.de > WWW: www.fokus.gmd.de/usr/reinhard.ruppelt/ > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:15:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10175 for ; Thu, 15 Mar 2001 18:15:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05671; Thu, 15 Mar 2001 15:14:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09477; Thu, 15 Mar 2001 15:13:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNBtIm007669 for ; Thu, 15 Mar 2001 15:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FNBtGH007668 for mobile-ip-dist; Thu, 15 Mar 2001 15:11:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNBoIm007661 for ; Thu, 15 Mar 2001 15:11:50 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06846 for ; Thu, 15 Mar 2001 18:11:47 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02612 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 18:11:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FKomIm006578 for ; Thu, 15 Mar 2001 12:50:48 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04066; Thu, 15 Mar 2001 12:50:46 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA14297; Thu, 15 Mar 2001 12:50:43 -0800 (PST) Date: Thu, 15 Mar 2001 12:50:42 -0800 (PST) From: Patrice Calhoun Subject: RE: [mobile-ip] Final Agenda for Mobile IP WG meeting at IETF50 To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, mankin@east.isi.edu In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B0321367F@daeis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >It would > >be much, much better to analyze what the current > >state of affairs is and compare that to MIP > >requirements before we decide whether a specific > >solution is in order. In fact, even if it is, I > >cannot imagine that the MIP WG is the right place > >to pursue this. > > > > Why is the MIP WG not the place to work on QoS aspects that are > related to mobility, especially from a Mobile IP perspective? Where > else in the IETF would you believe this work needs to be done? NSIS perhaps? Or maybe a new Qos for Wireless BOF? PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:22:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10262 for ; Thu, 15 Mar 2001 18:22:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05001; Thu, 15 Mar 2001 15:21:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12684; Thu, 15 Mar 2001 15:20:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNJJIm007709 for ; Thu, 15 Mar 2001 15:19:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FNJJR9007708 for mobile-ip-dist; Thu, 15 Mar 2001 15:19:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNJAIm007701 for ; Thu, 15 Mar 2001 15:19:11 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26085 for ; Thu, 15 Mar 2001 15:19:11 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA05734 for ; Thu, 15 Mar 2001 15:19:11 -0800 (PST) Message-Id: <200103152319.PAA05734@heliopolis.Eng.Sun.COM> Date: Thu, 15 Mar 2001 15:19:11 -0800 (PST) From: James Kempf Subject: [mobile-ip] Simplified Hierarchical MIPv6 (was...) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TjdRE5UOKDlyZlxvX1EOzQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, I don't want to get into a long discussion over this, since I've got a lot of other stuff to do before I leave for the Mini-Apple on Sun., but the fact remains that both hierarchical proposals introduce extra signalling and also some extra tunneling overhead over the air. Air resources are scarce if the network operator needs to pay for them, and so reducing air time is a significant plus. I think that Glenn's proposal deserves a serious look. It may turn out to be technically infeasible in the end but as has been pointed out, IPv6 is significantly more malleable at this point than IPv4 so there's no reason not to look for a simpler solution. If it turns out not to work, then we can return to one of the existing proposals. And there may be other reasons (like providing a local home address for homeless clients, as the MAP can) to use one of the existing solutions. I suppose a good set of requirements would have helped to avoid these problems. jak >X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f >From: "Hesham Soliman (ERA)" >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt >Date: Thu, 15 Mar 2001 20:48:40 +0100 >MIME-Version: 1.0 >List-Archive: >List-Owner: >List-Subscribe: >List-Unsubscribe: Sorry to jump in as you were addressing Glenn, but I have to correct some misunderstandings about HMIPv6. > >> > Hello, >> > >> > I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility. >> >> Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings >> we introduce state used in a similar way as state used for maintaining >> plain next hop forwarding. >> > => The next hop forwarding in the MAP depends on the routing > protocols in the domain. The next hop forwarding in Regional > is forced (like a static route). There is a big difference. > You might ague that reg6 is part of MIP, hence can be > classified as a routing protocol, but I would say that > any routing protocol that reserves a "circuit-like" path > in the IP network is not acceptable. > >> I read your use of term connection-oriented to >> mean the use of mobility bindings for forwarding instead of exclusively relying on host/network/default routes. Introducing robustness >> in this form of forwarding is a problem both HMIP and regreg6 face. >> In fact, even basic Mobile IPv6 while forwarding packets via the >> home agent has this feature. >> > => The robustness in terms of introducing a single point > of failure may be similar, but adding a less robust path > to the MN from the GMA is not acceptable, and clearly > this is not just my opinion. > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:23:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10273 for ; Thu, 15 Mar 2001 18:23:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05233; Thu, 15 Mar 2001 15:21:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12755; Thu, 15 Mar 2001 15:21:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNJlIm007719 for ; Thu, 15 Mar 2001 15:19:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FNJk6a007718 for mobile-ip-dist; Thu, 15 Mar 2001 15:19:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNJeIm007711 for ; Thu, 15 Mar 2001 15:19:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07887 for ; Thu, 15 Mar 2001 18:19:41 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02768 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 18:19:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FL2dIm006600 for ; Thu, 15 Mar 2001 13:02:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23074 for ; Thu, 15 Mar 2001 13:02:38 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18929 for ; Thu, 15 Mar 2001 13:02:37 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2FL2ad18141 for ; Thu, 15 Mar 2001 22:02:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 15 22:02:35 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 21:58:35 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC84@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 22:02:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Glenn, Before I start commenting on your proposal, I think there are some questions that need to be answered. Why do we need a multilevel static hierarchy of mobility aware routers ? This is a mystery to me. The argument of delays if the MAP is too far simply doesn't hold. If I have an 80ms delay over the air interface and the MAP is another 4 ms away, I think such delay is insignificant. The other question is, do we want to associate the implementation of this protocol with an imaginary protocol that generates an SA between the MN and the domain and distributes the key to all mobility aware routers ? The idea of generating such keys between two nodes is great and we have presented it in San Diego, but I don't think it should be a requirement for this to be used. Do we want to have a tree-based hierarchy full of single points of failure ? I don't want any of the above, but I'd like to see what others think. As you said Light travels fast and I like to Keep it simple, so unless there are strong and well thought requirements for the multi-level hierarchy, I think it should be dropped. I hope you don't take this as a negative response to your proposal, but I like to do things for a reason. The reasons and requirements here are not stated. Regards, Hesham PS: The regional draft for V4, basically says that f the MN has a colocated CoA , then it just registers with the GFA. Sounds familiar ! Just something to think about. > -----Original Message----- > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] > Sent: Friday, 16 March 2001 1:59 > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > Hesham and Charlie, > > I'm not too worried about the security association issue with anycast. I think anycast is extremely useful and is here to stay. It is part of IPv6 - might as well take advantage of it. > > I believe the SA establishment and scaling problem for MIP, in general, has scaling and speed issues. It would actually probably be more productive for us to focus on that issue than heirarchical models. It seems people have focused so far on "database in the sky" solutions with AAA protocols to this. > > I have an alternate idea which I would like to bring up again. > > Why don't we use a hop by hop option to alert mobile-aware routers to the binding updates. For instance, a mobile could send a binding update to a CN and it would be intercepted by the 1st hop router in the visited domain. > > If the visited domain wanted to support hierarchical, other routers along the natural routing path to the CN would be configured to care as well at whatever topological tier the provider deemed necessary. These hirearchical routers could install a per-host route in the binding cache to achieve route both optimized hierarchical signaling and traffic flow. > > These heirarchical routers could rebuild the binding update with a tiered address and use the domains keys i.e. the keys that routers already use to trust each other for the AH. Routers in the visited and in other domains that are not configured to care about mobility binding simply forward the packet towards the CN's address I.e. they are not configured to "recognize" the particular function. > > Only when the binding update exits a domain into another domain i.e. the keys change, the border router again intercepts and recomputes the binding update using the keys appropriate for the particular border. > > This process is continued until the binding update arrives at either the CN itself or a last hop router in the event they want route optimized location privacy. If the BU is sent to the CN, it is assumed that that CN has some security association with the subnet where it resides and it trusts the keys of that subnet. Perhaps the CN can simply trust the subnet routers without an SA - just as it currently does for ICMP singaling.> > > The advantage of this method are: > > - It re-uses the existing binding update i.e. we don't burn more air bandwidth. We leverage the existing binding updates. > > - It provides the most route optimal form of hierarchical mobility. > - It re-uses the existing security associations that SHOULD exist between domains, internal routers and hosts.> > - If one heirarchical router dies other communications and hierarchical bindings for other communications that mobile is engaged in continue un-affected. > > - It does not interfere with the natural routing policy of the domains. > - It seems to match up well and re-uses the same mechanisms used to monitor bandwidth and signal CoS. > > The disadvantages that I see is: > > - It makes some of the intermediary routers do extra signaling; however if you really understand what will have to happen for real time communications such as DSCP schema's changing between administrative domains, you will see that this work will be occuring anyway. Why send more than one packet to get the job done? > > - I agree it is not needed for best effort unless the excuse it to solve the security association problems. > > Another approach might be to send binding updates to the visited subnet anycast addresses and chain the message up the network i.e. MN subnet to site, site to site, site to CN subnet and then to CN. > > Is this clear? It seems to me that doing something like this would resolve many issues. > > One thing I really can't understand with both of your proposed hierarchical solutions is why you want to send more than one binding update. This burns the air resources. The whole idea for doing heirarchical was to reduce signaling latency for cellular. These networks are the only networks that I am aware of that someone might be moving so fast as to warrant a heirarchical scheme. The solutions seem to conflict with requirements. > > The last thing I would like to say that it seems we are spending way to much time on something that provides so little gain. Light travels very fast. > > Thanks, > > Glenn > > > > > Glenn > > -----Original Message----- > From: Charlie Perkins [ ] > Sent: Wednesday, March 14, 2001 5:38 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: Comments on Regional Registration > > > Hello Hesham, > > We want to get the routing part figured out, and I believe > we have a pretty good handle on it. > > Setting up security will allow a mobile node to provide > authentication data that can be checked by one of the > anycast group members. I know several ways to do that. > It will be more productive to start on that task once two > other things are out of the way: > - Fixing the authentication mechanism for base Mobile IPv6 > - Getting the routing part figured out. > > If you wish to disqualify all anycast-based solutions because > there are no standards for establishing security between a > node and the members of an anycast group, then I would > just prefer to say that we believe the problem is wholly > solvable for the particular anycast group we have designed. > We don't intend to get in the business of solving it for the > general case. > > Regards, > Charlie P. > > > > "Hesham Soliman (ERA)" wrote: > > > Hello Charlie, > > > > > > > > > GM> I agree, I support anycast too. To vilify a solution which employs > > > > it as magic was wrong and I apologize. > > > > > > No need for apology, but I wanted to point out that this particular > > > use of anycast is easy to implement, assuming that one's IPv6 > > > implementation supports anycast at all. > > > > > => I'm a bit confused by this statement. How can it be easy > > to implement a BU to an anycast address ? > > BUs have to be secured with AH, so how can you setup this > > security association when there are no standards defined > > to do so ? > > > > Regards, > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 18:50:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10510 for ; Thu, 15 Mar 2001 18:50:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29027; Thu, 15 Mar 2001 15:48:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16671; Thu, 15 Mar 2001 15:48:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNkWIm007840 for ; Thu, 15 Mar 2001 15:46:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2FNkWVv007839 for mobile-ip-dist; Thu, 15 Mar 2001 15:46:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FNkNIm007832 for ; Thu, 15 Mar 2001 15:46:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01882 for ; Thu, 15 Mar 2001 15:46:23 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08171 for ; Thu, 15 Mar 2001 15:46:21 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2FNkFd09544 for ; Fri, 16 Mar 2001 00:46:15 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 16 00:46:15 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 00:46:14 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC88@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Request for comments on some work on proactive ha ndovers in IPv6 Date: Fri, 16 Mar 2001 00:46:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I forgot to say the scheme really pushes for UDP flows....basically what > all the guys have been talking about real-time interactive multimedia... > => Why do you say that ? There are three different methods identified in the draft, per-connection, per-flow and per packet. The first two are applicable to any flow/connecton. The third (if needed at all) is not good for TCP. > For TCP I have another strand of that.... :)))) > > And by the way bother to throw some stones at it apart from lauging.. > => I don't get hte point of these two sentences. I hope there are some technical arguments that are hidden behind them. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:08:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10711 for ; Thu, 15 Mar 2001 19:08:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16427; Thu, 15 Mar 2001 16:07:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24073; Thu, 15 Mar 2001 16:07:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G05LIm007902 for ; Thu, 15 Mar 2001 16:05:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G05Kd4007901 for mobile-ip-dist; Thu, 15 Mar 2001 16:05:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G05EIm007894 for ; Thu, 15 Mar 2001 16:05:15 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13323 for ; Thu, 15 Mar 2001 19:05:11 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA03797 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 19:05:17 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FM8JIm006965 for ; Thu, 15 Mar 2001 14:08:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24329 for ; Thu, 15 Mar 2001 14:08:18 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22545 for ; Thu, 15 Mar 2001 14:08:17 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2FM89g11705 for ; Thu, 15 Mar 2001 16:08:19 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 15 Mar 2001 16:08:07 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 15 Mar 2001 16:08:07 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC3DF@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 16:08:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Heshman, It seems that in the HMIPv6 draft, you suggest to distribute the session keys either using IKE or AAA servers and to authenticate the BUs. The same solution can apply to Regional Registration: we suggest to use AAA servers, so I don't think that it is more complex. The only difference when using anycast address is in anti replay attacks: We suggest to use nonces instead of the sequence number defined in AH. Franck -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: 15 March, 2001 10:10 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > => I'm not at all trying to discredit anycastl. I'm just > > wondering how you could use it in light of the current > > standards. You still didn't tell me what the solution > > is. > > Proposing a solution for setting up an SA with an > > anycast group would be a great proposal, but > > I don't think we need several standards to solve > > this particular problem. We already have a solution > > and I'm starting to question the need for alternatives > > if nothing is raised against HMIPv6. Especally if > > the alternative is a lot less robust and overrides > > the use of standard routing between the anchor point > > and the MN. > > > > actually that there are different proposals on the way to set up Security > Associations and to authenticate the BU using AH in Appendix B of the draft. > => Yes I saw that, but this is hardly a standard or an accepted method, I don't think we can base it on the appendix surely. Even if we can, my main point is why are we adding all this complication to achieve the same effect that HMIPv6 does ? I haven't heard an answer till now. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:09:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10761 for ; Thu, 15 Mar 2001 19:09:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16989; Thu, 15 Mar 2001 16:08:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21281; Thu, 15 Mar 2001 16:07:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G05vIm007912 for ; Thu, 15 Mar 2001 16:05:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G05vCN007911 for mobile-ip-dist; Thu, 15 Mar 2001 16:05:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G05eIm007904 for ; Thu, 15 Mar 2001 16:05:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22969 for ; Thu, 15 Mar 2001 16:05:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06192 for ; Thu, 15 Mar 2001 16:05:40 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA28779 for ; Thu, 15 Mar 2001 16:05:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G05cn13382 for ; Thu, 15 Mar 2001 16:05:38 -0800 X-mProtect: Thu, 15 Mar 2001 16:05:38 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdkybzYc; Thu, 15 Mar 2001 16:05:27 PST Message-ID: <3AB158C8.D83F376B@iprg.nokia.com> Date: Thu, 15 Mar 2001 16:05:28 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Comments on Regional Registration References: <034BEFD03799D411A59F00508BDF7546013DBC81@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, > > I think it's important to support more than one level of > > regionalized care-of address, at least for the organization > > of mobility management we have in mind for "All-IP" > > networks. > > > => Ok, could you please give a reason for this ? > How does All-IP come into this ? Do you _really_ not at all understand the need for multiple levels of hierarchy? Unfortunately, I'm out of time today, but I'll try to catch up with you next week. > > I also like that anycast addressing allows the mobile node > > to accomplish the regional binding update without having > > to know about the topology of the visited domain. > > > => Knowing a unicast address does not imply knowledge > of the topology. The MN knows the HA's address, > does that imply that it is aware of the topology of > the home network ? One could go around a visited network listening to the advertisements and get some pretty good ideas about the topology. > Anyway, we keep missing the point that the current > reg6 draft does not work. We seem to miss that > you can't setup an SA with an anycast address, > but obviously this is not the only concern I have about the > draft. I see that you don't like our draft, but saying that it doesn't work isn't very constructive. Especially in view of recent exchanges regarding your re-re-iterated concerns. > > Your statement is near tautological. Of course, we'd also > > like to arrive at a robust protocol that uses as much > > standard routing as is possible. > > > => So what is wrong with the current proposal ? When I have more time, I'll try to tabulate a list for easy reference. However, in the meantime, I'd have to refer you to previous mail postings. Please note that I'm not very comfortable carrying out this sort of mail exchange in the first place. > > We also wish to allow > > betterm localization of binding updates than HMIPv6 could > > provide. That can translate into better scalability for the > > foreseeable future. > > > => This statement is a bit vague. I'd also like to have > a better solution than HMIPv6 or MIPv6 for that matter. > Not because I think they're bad but because better is always > good. The question is where is that better proposal ? > and why is it better ? If we didn't think that our regional registration was better at least in certain respects, we wouldn't be bringing it up. As it is, we'll try to make refinements and comparisons as time goes on. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:12:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10813 for ; Thu, 15 Mar 2001 19:12:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16990; Thu, 15 Mar 2001 16:08:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21273; Thu, 15 Mar 2001 16:07:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G057Im007892 for ; Thu, 15 Mar 2001 16:05:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0569o007891 for mobile-ip-dist; Thu, 15 Mar 2001 16:05:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G04vIm007882 for ; Thu, 15 Mar 2001 16:04:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23539 for ; Thu, 15 Mar 2001 16:04:58 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14046 for ; Thu, 15 Mar 2001 16:04:56 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2G04tC26196 for ; Fri, 16 Mar 2001 01:04:55 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 16 01:04:55 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 01:00:55 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC89@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...) Date: Fri, 16 Mar 2001 01:04:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > I don't want to get into a long discussion over this, since I've > got a lot of other stuff to do before I leave for the Mini-Apple > on Sun., but the fact remains that both hierarchical proposals introduce > extra signalling and also some extra tunneling overhead over the air. > Air resources are scarce if the network operator needs to pay for them, > and so reducing air time is a significant plus. > => Sure air resources are scarce and expensive, especially in many cellular systems where they cost billions. BUT, even one IPv6 header is too expensive, especially for real time services. So what does every IP based cellular system do, they use Header compression. It can handle tunnelling. There are several other protocols in MIP and outside that require tunnelling to the host, so why is this a special case ? > I think that Glenn's proposal deserves a serious look. > => Of course. every proposal does, but we need to see a justification/requirements for proposals. > If it > turns out not to work, then we can return to one of the existing > proposals. And there may be other reasons (like providing a local home address > for homeless clients, as the MAP can) to use one of the existing > solutions. > => Agreed. > I suppose a good set of requirements would have helped to avoid these > problems. > => Agreed. We've included our requirements in the draft and in all our IETF presentations and I encourage others to do the same. What I do discourage (and it's clearly not my decision) is not highlighting what's missing in an existing WG draft. All I want to see is a valid requirement that we have missed or a fundamental problem with the proposal. We normally respond by adding the missing bits as we've shown in previous revisions. Is this so hard to get ? I hope not.Otherwise the discussions are subjective and not very fruitful. Regards, Hesham > >X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to > owner-mobile-ip@sunroof.eng.sun.com using -f > >From: "Hesham Soliman (ERA)" > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt > >Date: Thu, 15 Mar 2001 20:48:40 +0100 > >MIME-Version: 1.0 > >List-Archive: > >List-Owner: > >List-Subscribe: > >List-Unsubscribe: > Sorry to jump in > as you were addressing Glenn, but I have to correct some misunderstandings > about HMIPv6. > > > >> > Hello, > >> > > >> > I still do not understand why the ability to place something at an > arbitrary point justifies destroying the connectionless nature of a IP or even > IP mobility. > >> > >> Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings > >> we introduce state used in a similar way as state used for maintaining > >> plain next hop forwarding. > >> > > => The next hop forwarding in the MAP depends on the routing > > protocols in the domain. The next hop forwarding in Regional > > is forced (like a static route). There is a big difference. > > You might ague that reg6 is part of MIP, hence can be > > classified as a routing protocol, but I would say that > > any routing protocol that reserves a "circuit-like" path > > in the IP network is not acceptable. > > > >> I read your use of term connection-oriented to > >> mean the use of mobility bindings for forwarding instead of exclusively > relying on host/network/default routes. Introducing robustness > >> in this form of forwarding is a problem both HMIP and regreg6 face. > >> In fact, even basic Mobile IPv6 while forwarding packets via the > >> home agent has this feature. > >> > > => The robustness in terms of introducing a single point > > of failure may be similar, but adding a less robust path > > to the MN from the GMA is not acceptable, and clearly > > this is not just my opinion. > > > > Regards, > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:12:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10824 for ; Thu, 15 Mar 2001 19:12:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28740; Thu, 15 Mar 2001 16:11:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24234; Thu, 15 Mar 2001 16:11:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ABIm008007 for ; Thu, 15 Mar 2001 16:10:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0AAXF008006 for mobile-ip-dist; Thu, 15 Mar 2001 16:10:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0A1Im007999 for ; Thu, 15 Mar 2001 16:10:01 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13731 for ; Thu, 15 Mar 2001 19:10:01 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA03901 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 19:10:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2FMYYIm007208 for ; Thu, 15 Mar 2001 14:34:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15602 for ; Thu, 15 Mar 2001 14:34:21 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24814 for ; Thu, 15 Mar 2001 14:34:19 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2FMYIC13419 for ; Thu, 15 Mar 2001 23:34:18 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 15 23:33:05 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 23:34:17 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC87@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6 Date: Thu, 15 Mar 2001 23:34:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I had the same comment about the location privacy. One could say it provides a little better location privacy but that's about it. They might know the city or building that your in as apposed to a room. > => True. But the same goes for any IP adderss in the hierarchical IPv6 world. Right ? Hesham > -----Original Message----- > From: Theo Pagtzis [ ] > Sent: Wednesday, March 14, 2001 7:12 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Some questions on Hierarchical MIPv6 > > > Hi all, > > I would appreiciate if the HMIP authors could shed some light in some statements > in the hmipv6-02 draft that got out recently. > > > In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP. > The question is which one the home address or the onlink (LCoA)? > > > If a MAP is serving as a mobile AR you enforce that it must advertise its and all > MAP options available. Does that imply that the 'preference' is specific here? > > Further (page 20, top statement) you state that this would allow the MN to obtain a > new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA). The > reason I ask here is because you state that in the extended mode the MN is bound to > use the mobile AR/MAP IP address. > > Also you state that the MN should send a BU to the (further ???) MAP to bind its > Home Addr with the MR's CoA. Can you explain why you need to do that? Do you mean > by further, a MAP higher (upstream) in the routing hierarchy? > > How can you possibly have location privacy if the upstream packets have as their > source address the MNs LCoA. If you do not have the LCoA as the source address, > then start praying over egress filtering. > > If you have load balancing effected which RCoA do you send back to the HA? > > > Regs. > > > Theo > > UCL / Mobile systems > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:21:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10914 for ; Thu, 15 Mar 2001 19:21:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01727; Thu, 15 Mar 2001 16:19:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23787; Thu, 15 Mar 2001 16:19:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0GFIm008085 for ; Thu, 15 Mar 2001 16:16:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0GFR9008084 for mobile-ip-dist; Thu, 15 Mar 2001 16:16:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0G6Im008077 for ; Thu, 15 Mar 2001 16:16:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25060 for ; Thu, 15 Mar 2001 16:16:06 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05560 for ; Thu, 15 Mar 2001 16:15:56 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2G0Fld13927 for ; Fri, 16 Mar 2001 01:15:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 16 01:17:32 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 01:15:46 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8A@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Fri, 16 Mar 2001 01:15:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > It seems that in the HMIPv6 draft, you suggest to distribute the session > keys either using IKE or AAA servers and to authenticate the BUs. The same > solution can apply to Regional Registration: we suggest to use AAA servers, > so I don't think that it is more complex. > => Please read your statement above carefully. You just said HMIPv6 works with either IKE or AAA, but regional only works with AAA. I think that's a significant difference. BTW the HMIPv6 draft only talks about AAA in terms of context transfer, not for SA establishment. We presented another draft for that purpose and we certainly do NOT want to restrict the use of HMIPv6 to the AAA SA generation scenario. > The only difference when using anycast address is in anti replay attacks: We > suggest to use nonces instead of the sequence number defined in AH. > => Can you use IKE for a key exchange with an anycast address ??? Thanks, Hesham > -----Original Message----- > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 15 March, 2001 10:10 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > > > > => I'm not at all trying to discredit anycastl. I'm just > > > wondering how you could use it in light of the current > > > standards. You still didn't tell me what the solution > > > is. > > > Proposing a solution for setting up an SA with an > > > anycast group would be a great proposal, but > > > I don't think we need several standards to solve > > > this particular problem. We already have a solution > > > and I'm starting to question the need for alternatives > > > if nothing is raised against HMIPv6. Especally if > > > the alternative is a lot less robust and overrides > > > the use of standard routing between the anchor point > > > and the MN. > > > > > > > actually that there are different proposals on the way to set up Security > > Associations and to authenticate the BU using AH in Appendix B of the > draft. > > > => Yes I saw that, but this is hardly a standard or an accepted > method, I don't think we can base it on the appendix surely. > Even if we can, my main point is why are we adding all this > complication to achieve the same effect that HMIPv6 does ? > I haven't heard an answer till now. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:26:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10987 for ; Thu, 15 Mar 2001 19:26:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03912; Thu, 15 Mar 2001 16:24:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10480; Thu, 15 Mar 2001 16:24:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0NTIm008128 for ; Thu, 15 Mar 2001 16:23:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0NS8G008127 for mobile-ip-dist; Thu, 15 Mar 2001 16:23:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0NJIm008120 for ; Thu, 15 Mar 2001 16:23:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24553 for ; Thu, 15 Mar 2001 16:23:20 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20330 for ; Thu, 15 Mar 2001 16:23:19 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2G0NHd14972 for ; Fri, 16 Mar 2001 01:23:17 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 16 01:25:02 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 01:23:16 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Fri, 16 Mar 2001 01:23:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > > I think it's important to support more than one level of > > > regionalized care-of address, at least for the organization > > > of mobility management we have in mind for "All-IP" > > > networks. > > > > > => Ok, could you please give a reason for this ? > > How does All-IP come into this ? > > Do you _really_ not at all understand the need for multiple > levels of hierarchy? > => Yes. I'm sorry if this is a trivial question but I honestly don't see why it's needed and would appreciate an explanation. > Unfortunately, I'm out of time today, > but I'll try to catch up with you next week. > => OK. > > > I also like that anycast addressing allows the mobile node > > > to accomplish the regional binding update without having > > > to know about the topology of the visited domain. > > > > > => Knowing a unicast address does not imply knowledge > > of the topology. The MN knows the HA's address, > > does that imply that it is aware of the topology of > > the home network ? > > One could go around a visited network listening to the > advertisements and get some pretty good ideas about the topology. > => You could also do a trace route and get a good idea about the topology. > > Anyway, we keep missing the point that the current > > reg6 draft does not work. We seem to miss that > > you can't setup an SA with an anycast address, > > but obviously this is not the only concern I have about the > > draft. > > I see that you don't like our draft, but saying that it > doesn't work isn't very constructive. Especially in view > of recent exchanges regarding your re-re-iterated concerns. > => I am referring to the standard Key Exchange mechanisms available, like IKE. I hope this is more contructive. > > > Your statement is near tautological. Of course, we'd also > > > like to arrive at a robust protocol that uses as much > > > standard routing as is possible. > > > > > => So what is wrong with the current proposal ? > > When I have more time, I'll try to tabulate a list for easy > reference. However, in the meantime, I'd have to refer you > to previous mail postings. > => I'll look forward to your comparison. > Please note that I'm not very > comfortable carrying out this sort of mail exchange in the > first place. > => My aim is to keep a technical discussion going. It might be difficult to get this sort of discussion in 7 minutes during the meeting. I thought this discussion would be encouraged. > > > We also wish to allow > > > betterm localization of binding updates than HMIPv6 could > > > provide. That can translate into better scalability for the > > > foreseeable future. > > > > > => This statement is a bit vague. I'd also like to have > > a better solution than HMIPv6 or MIPv6 for that matter. > > Not because I think they're bad but because better is always > > good. The question is where is that better proposal ? > > and why is it better ? > > If we didn't think that our regional registration was better at > least in certain respects, we wouldn't be bringing it up. > As it is, we'll try to make refinements and comparisons as > time goes on. > => Looking forward to the outcome. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:27:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11011 for ; Thu, 15 Mar 2001 19:27:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03113; Thu, 15 Mar 2001 16:26:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10940; Thu, 15 Mar 2001 16:26:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0PDIm008146 for ; Thu, 15 Mar 2001 16:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0PCVE008141 for mobile-ip-dist; Thu, 15 Mar 2001 16:25:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0P0Im008130 for ; Thu, 15 Mar 2001 16:25:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27090 for ; Thu, 15 Mar 2001 16:25:00 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15452 for ; Thu, 15 Mar 2001 16:24:59 -0800 (PST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 15 Mar 2001 18:22:54 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 18:22:51 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA73C@crchy271.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6 Date: Thu, 15 Mar 2001 18:22:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ADAF.365B5090" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ADAF.365B5090 Content-Type: text/plain; charset="iso-8859-1" Yes - there is no accepted or even tabled proposal yet for route optimal location privacy. I believe it is a requirement even MIP should strive for as we move forward. => True. But the same goes for any IP adderss in the hierarchical IPv6 world. Right ? Hesham ------_=_NextPart_001_01C0ADAF.365B5090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Some questions on Hierarchical MIPv6

Yes - there is no accepted or even tabled proposal = yet for route optimal location privacy. I believe it is a requirement = even MIP should strive for as we move forward.



 
        =3D> = True. But the same goes for any IP adderss in the hierarchical
        IPv6 = world. Right ?

        Hesham

------_=_NextPart_001_01C0ADAF.365B5090-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:37:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11170 for ; Thu, 15 Mar 2001 19:37:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09097; Thu, 15 Mar 2001 16:36:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29475; Thu, 15 Mar 2001 16:36:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ZOIm008226 for ; Thu, 15 Mar 2001 16:35:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0ZNVv008225 for mobile-ip-dist; Thu, 15 Mar 2001 16:35:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ZEIm008218 for ; Thu, 15 Mar 2001 16:35:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29163 for ; Thu, 15 Mar 2001 16:35:15 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24752 for ; Thu, 15 Mar 2001 16:35:15 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA01982 for ; Thu, 15 Mar 2001 16:34:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACI23442; Thu, 15 Mar 2001 16:35:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA23352; Thu, 15 Mar 2001 16:35:14 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.24514.216641.218362@thomasm-u1.cisco.com> Date: Thu, 15 Mar 2001 16:35:14 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBC8A@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF7546013DBC8A@esealnt448.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think that Hesham brings up a really good point here. Where it is feasible, *all* of these scenarios should allow whatever key distribution protocol -- IKE, Kerberos, etc -- is right for the deployment. Explicitly joining MIP and AAA at the hip -- which seems to be the overall direction of this WG -- makes me *seriously* queasy. If there were an area where people should be scared about declaring a single -- or even prefered -- method, key distribution would probably be one of them. Also: the general expectation of a AAA infrastructure seems highly suspect to me. There is no *requirement* in IP for AAA. It -- like just about every other IETF protocol -- is and should remain severeable from the base MIP protocol. If keying with AAA is allowed, at the very least the door MUST be open in all cases for other key distribution schemes including sneakernet. Mike Hesham Soliman (ERA) writes: > > > It seems that in the HMIPv6 draft, you suggest to distribute the session > > keys either using IKE or AAA servers and to authenticate the BUs. The same > > solution can apply to Regional Registration: we suggest to use AAA servers, > > so I don't think that it is more complex. > > > => Please read your statement above carefully. You just said HMIPv6 > works with either IKE or AAA, but regional only works with AAA. > I think that's a significant difference. > BTW the HMIPv6 draft only talks about AAA in terms of context > transfer, not for SA establishment. We presented another > draft for that purpose and we certainly do NOT want to restrict > the use of HMIPv6 to the AAA SA generation scenario. > > > The only difference when using anycast address is in anti replay attacks: We > > suggest to use nonces instead of the sequence number defined in AH. > > > => Can you use IKE for a key exchange with an anycast address ??? > > Thanks, > Hesham > > > > -----Original Message----- > > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: 15 March, 2001 10:10 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > > > > > > > => I'm not at all trying to discredit anycastl. I'm just > > > > wondering how you could use it in light of the current > > > > standards. You still didn't tell me what the solution > > > > is. > > > > Proposing a solution for setting up an SA with an > > > > anycast group would be a great proposal, but > > > > I don't think we need several standards to solve > > > > this particular problem. We already have a solution > > > > and I'm starting to question the need for alternatives > > > > if nothing is raised against HMIPv6. Especally if > > > > the alternative is a lot less robust and overrides > > > > the use of standard routing between the anchor point > > > > and the MN. > > > > > > > > > > actually that there are different proposals on the way to set up Security > > > Associations and to authenticate the BU using AH in Appendix B of the > > draft. > > > > > => Yes I saw that, but this is hardly a standard or an accepted > > method, I don't think we can base it on the appendix surely. > > Even if we can, my main point is why are we adding all this > > complication to achieve the same effect that HMIPv6 does ? > > I haven't heard an answer till now. > > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:43:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11237 for ; Thu, 15 Mar 2001 19:43:00 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17173; Thu, 15 Mar 2001 16:42:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00432; Thu, 15 Mar 2001 16:42:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0elIm008278 for ; Thu, 15 Mar 2001 16:40:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0ekKH008277 for mobile-ip-dist; Thu, 15 Mar 2001 16:40:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ecIm008270 for ; Thu, 15 Mar 2001 16:40:38 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27567 for ; Thu, 15 Mar 2001 16:40:38 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA07905 for ; Thu, 15 Mar 2001 16:40:38 -0800 (PST) Message-Id: <200103160040.QAA07905@heliopolis.Eng.Sun.COM> Date: Thu, 15 Mar 2001 16:40:38 -0800 (PST) From: James Kempf Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vzedxBR7c6koD2k42z1UjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, >> I don't want to get into a long discussion over this, since I've >> got a lot of other stuff to do before I leave for the Mini-Apple >> on Sun., but the fact remains that both hierarchical proposals introduce >> extra signalling and also some extra tunneling overhead over the air. >> Air resources are scarce if the network operator needs to pay for them, >> and so reducing air time is a significant plus. >> > => Sure air resources are scarce and expensive, especially > in many cellular systems where they cost billions. > BUT, even one IPv6 header is too expensive, especially for real > time services. So what does every IP based cellular system > do, they use Header compression. It can handle tunnelling. > But I've heard that moving tunneling state during a handoff is problematic, and that it might take some number of messages to reestablish. This would essentially negate the low latency work currently going on. I am as wary of making tunnelling the easy answer for eliminating all header overhead as you are of using an anycast address. > There are several other protocols in MIP and outside that > require tunnelling to the host, so why is this a special case ? It's not a special case, and I don't like requiring the mobile to handle tunneling in those cases either. >>> I suppose a good set of requirements would have helped to avoid these >> problems. >> > => Agreed. We've included our requirements in the draft > and in all our IETF presentations and I encourage > others to do the same. > What I do discourage (and it's clearly not my decision) > is not highlighting what's missing in an existing WG > draft. All I want to see is a valid requirement that we have > missed or a fundamental problem with the proposal. > We normally respond by adding the missing bits > as we've shown in previous revisions. > > Is this so hard to get ? I hope not.Otherwise the > discussions are subjective and not very fruitful. > We would like to see elimination of *all* tunnelling overhead over the air (and that includes HA overhead folks) if possible. For example, by stripping it on at the last hop router, where it is no longer needed. Barring that, we would like to see an analysis that indicates header compression will work to eliminate tunnelling overhead, and that it can be moved quickly enough during handover that it will not negate the gains of the low latency handover protocol. I do not get the feeling from the Seamoby context transfer problem statement draft that this is possible. These are our requirements. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:46:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11288 for ; Thu, 15 Mar 2001 19:46:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19286; Thu, 15 Mar 2001 16:44:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00883; Thu, 15 Mar 2001 16:44:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ggIm008308 for ; Thu, 15 Mar 2001 16:42:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0gfWs008307 for mobile-ip-dist; Thu, 15 Mar 2001 16:42:41 -0800 (PST) Date: Thu, 15 Mar 2001 16:42:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0gVIm008300 for ; Thu, 15 Mar 2001 16:42:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27950 for ; Thu, 15 Mar 2001 16:42:31 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13725 for ; Thu, 15 Mar 2001 17:42:29 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2G0gSC01501 for ; Fri, 16 Mar 2001 01:42:28 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 16 01:42:27 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 01:42:27 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Yes - there is no accepted or even tabled proposal yet for route optimal location privacy. I believe it is a requirement even MIP should strive for as we move forward. => I agree. The problem is that your IP address is the one piece of information needed to route packets to you. So if you want to hide your true location by telling the CN to send packets to another IP address, then you need to compromise between location privacy and optimal routing. One extreme would be to always use your Home Address, however the optimisation of the route will depend on how far you are from the HA. However you could argue that even if you do not send BUs to the CN to achieve location privacy, the CN can still know your real address from the source address on your packets. Even if you hide that (like in the case of reverse tunnelling from the FA in MIPv4) a CN who wants to find your location can do a trace route and find you ! Unless you disable the application in your HA of course. So, I agree it's a hard problem. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:51:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11331 for ; Thu, 15 Mar 2001 19:51:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14650; Thu, 15 Mar 2001 16:50:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01992; Thu, 15 Mar 2001 16:50:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0nCIm008388 for ; Thu, 15 Mar 2001 16:49:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0nChj008387 for mobile-ip-dist; Thu, 15 Mar 2001 16:49:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0muIm008363 for ; Thu, 15 Mar 2001 16:48:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29041 for ; Thu, 15 Mar 2001 16:48:57 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23560 for ; Thu, 15 Mar 2001 16:48:56 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2G0onw27988 for ; Thu, 15 Mar 2001 18:50:49 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 15 Mar 2001 18:48:54 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 15 Mar 2001 18:48:54 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC3E2@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Thu, 15 Mar 2001 18:48:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: IKE requires too many messages to be exchanged so that may be not be the most optimized solution to set up the security associations between the MN and Mobility agents: IPsec WG is already designing a new protocol "Son of IKE". In addition, IKE requires either PKI or a pre shared secret between the two entities that are setting up the SA ! Do you believe that PKI will be ready soon ? As for the pre-shared secret between the MN and Mobility agents, do you think that such solutions is really scalable ? For those reasons, we suggest to use AAA servers. -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] Sent: 15 March, 2001 6:16 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Re: Comments on Regional Registration > It seems that in the HMIPv6 draft, you suggest to distribute the session > keys either using IKE or AAA servers and to authenticate the BUs. The same > solution can apply to Regional Registration: we suggest to use AAA servers, > so I don't think that it is more complex. > => Please read your statement above carefully. You just said HMIPv6 works with either IKE or AAA, but regional only works with AAA. I think that's a significant difference. BTW the HMIPv6 draft only talks about AAA in terms of context transfer, not for SA establishment. We presented another draft for that purpose and we certainly do NOT want to restrict the use of HMIPv6 to the AAA SA generation scenario. > The only difference when using anycast address is in anti replay attacks: We > suggest to use nonces instead of the sequence number defined in AH. > => Can you use IKE for a key exchange with an anycast address ??? Thanks, Hesham > -----Original Message----- > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 15 March, 2001 10:10 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > > > > => I'm not at all trying to discredit anycastl. I'm just > > > wondering how you could use it in light of the current > > > standards. You still didn't tell me what the solution > > > is. > > > Proposing a solution for setting up an SA with an > > > anycast group would be a great proposal, but > > > I don't think we need several standards to solve > > > this particular problem. We already have a solution > > > and I'm starting to question the need for alternatives > > > if nothing is raised against HMIPv6. Especally if > > > the alternative is a lot less robust and overrides > > > the use of standard routing between the anchor point > > > and the MN. > > > > > > > actually that there are different proposals on the way to set up Security > > Associations and to authenticate the BU using AH in Appendix B of the > draft. > > > => Yes I saw that, but this is hardly a standard or an accepted > method, I don't think we can base it on the appendix surely. > Even if we can, my main point is why are we adding all this > complication to achieve the same effect that HMIPv6 does ? > I haven't heard an answer till now. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 19:58:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11412 for ; Thu, 15 Mar 2001 19:58:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17507; Thu, 15 Mar 2001 16:58:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17916; Thu, 15 Mar 2001 16:58:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0usIm008463 for ; Thu, 15 Mar 2001 16:56:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G0usi7008462 for mobile-ip-dist; Thu, 15 Mar 2001 16:56:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G0ujIm008455 for ; Thu, 15 Mar 2001 16:56:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17649 for ; Thu, 15 Mar 2001 16:56:45 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02363 for ; Thu, 15 Mar 2001 16:56:44 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2G0uhC03475 for ; Fri, 16 Mar 2001 01:56:43 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 16 01:56:43 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 01:52:43 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...) Date: Fri, 16 Mar 2001 01:56:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > We would like to see elimination of *all* tunnelling overhead over > the air (and that includes HA overhead folks) if possible. For example, > by stripping it on at the last hop router, where it is no longer > needed. > > Barring that, we would like to see an analysis that indicates header > compression will work to eliminate tunnelling overhead, and that > it can be moved quickly enough during handover that it will not > negate the gains of the low latency handover protocol. > => I am not an expert on header compression by any means but based on my several discussions with some experts in the area, I was told that ROHC will handle tunnelling and Extension headers at no extra cost over the air. So if this true,I wonder if tunnelling is a problem. > I do not > get the feeling from the Seamoby context transfer problem statement > draft that this is possible. > => I haven't looked into it in detail, have you heard of some reasons ? Perhaps this context transfer discussion needs to be taken to the seamoby list, but I'm wondering what the negative impacts are if we do not transfer the context for header compression. In the worste case scenario I am told that maybe 2 or 3 packets will be sent with a full header. But that doesn't mean loss of service, just a short period of inefficiency over the air. Is that true ? Does anynoe know more about this ? Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 20:06:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11527 for ; Thu, 15 Mar 2001 20:06:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20554; Thu, 15 Mar 2001 17:05:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05491; Thu, 15 Mar 2001 17:05:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G14GIm008546 for ; Thu, 15 Mar 2001 17:04:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G14FVl008545 for mobile-ip-dist; Thu, 15 Mar 2001 17:04:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G146Im008538 for ; Thu, 15 Mar 2001 17:04:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05199 for ; Thu, 15 Mar 2001 17:04:07 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08546 for ; Thu, 15 Mar 2001 17:04:05 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2G144d21165 for ; Fri, 16 Mar 2001 02:04:04 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 16 02:04:04 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 02:04:03 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC8E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Comments on Regional Registration Date: Fri, 16 Mar 2001 02:04:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > IKE requires too many messages to be exchanged so that may be not be the > most optimized solution to set up the security associations between the MN > and Mobility agents: IPsec WG is already designing a new protocol "Son of > IKE". > In addition, IKE requires either PKI or a pre shared secret between the two > entities that are setting up the SA ! > => That's all fair and I presented the exact same arguments in San Diego, but I don't think this is a reason to mandate AAA _only_ solutions. You also didn't mention that IKE is a more secure mechnism than the AAA one. So it' not all gloomy with IKE. Nothing comes for free, and if people want to use MIPv6 with IKE then I don't think we should have a standard that stops them from doing so. That would be a mistake IMO. > Do you believe that PKI will be ready soon ? > => Some people already have Public Keys, not widely deployed yes, but we shouldn't stop them from using it. > As for the pre-shared secret between the MN and Mobility agents, do you > think that such solutions is really scalable ? > => No. > For those reasons, we suggest to use AAA servers. > => I hope I made myself clear above, I also like AAA, Kerberos and other mechanisms and I'm not trying to say they're bad, but tying a standard to AAA only is not a good idea IMO. Hesham > -----Original Message----- > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: 15 March, 2001 6:16 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > > > > It seems that in the HMIPv6 draft, you suggest to distribute the session > > keys either using IKE or AAA servers and to authenticate the BUs. The same > > solution can apply to Regional Registration: we suggest to use AAA > servers, > > so I don't think that it is more complex. > > > => Please read your statement above carefully. You just said HMIPv6 > works with either IKE or AAA, but regional only works with AAA. > I think that's a significant difference. > BTW the HMIPv6 draft only talks about AAA in terms of context > transfer, not for SA establishment. We presented another > draft for that purpose and we certainly do NOT want to restrict > the use of HMIPv6 to the AAA SA generation scenario. > > > The only difference when using anycast address is in anti replay attacks: > We > > suggest to use nonces instead of the sequence number defined in AH. > > > => Can you use IKE for a key exchange with an anycast address ??? > > Thanks, > Hesham > > > > -----Original Message----- > > From: ext Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > > Sent: 15 March, 2001 10:10 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Re: Comments on Regional Registration > > > > > > > > => I'm not at all trying to discredit anycastl. I'm just > > > > wondering how you could use it in light of the current > > > > standards. You still didn't tell me what the solution > > > > is. > > > > Proposing a solution for setting up an SA with an > > > > anycast group would be a great proposal, but > > > > I don't think we need several standards to solve > > > > this particular problem. We already have a solution > > > > and I'm starting to question the need for alternatives > > > > if nothing is raised against HMIPv6. Especally if > > > > the alternative is a lot less robust and overrides > > > > the use of standard routing between the anchor point > > > > and the MN. > > > > > > > > > > actually that there are different proposals on the way to set up > Security > > > Associations and to authenticate the BU using AH in Appendix B of the > > draft. > > > > > => Yes I saw that, but this is hardly a standard or an accepted > > method, I don't think we can base it on the appendix surely. > > Even if we can, my main point is why are we adding all this > > > complication to achieve the same effect that HMIPv6 does ? > > I haven't heard an answer till now. > > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 20:10:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11567 for ; Thu, 15 Mar 2001 20:10:31 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14099; Thu, 15 Mar 2001 17:09:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05882; Thu, 15 Mar 2001 17:09:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G181Im008586 for ; Thu, 15 Mar 2001 17:08:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G1816O008585 for mobile-ip-dist; Thu, 15 Mar 2001 17:08:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G17qIm008578 for ; Thu, 15 Mar 2001 17:07:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05904 for ; Thu, 15 Mar 2001 17:07:52 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06435 for ; Thu, 15 Mar 2001 17:07:52 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA14436 for ; Thu, 15 Mar 2001 17:07:52 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACI24116; Thu, 15 Mar 2001 17:07:50 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA23359; Thu, 15 Mar 2001 17:07:50 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.26470.377047.623161@thomasm-u1.cisco.com> Date: Thu, 15 Mar 2001 17:07:50 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Comments on Regional Registration In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC3E2@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B028DC3E2@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Franck.Le@nokia.com writes: > IKE requires too many messages to be exchanged so that may be not be the > most optimized solution to set up the security associations between the MN > and Mobility agents: IPsec WG is already designing a new protocol "Son of > IKE". IPsec WG is doing no such thing. They are *thinking* about Son of IKE, but nothing is definite now. Also: a categorical "too many messages" is a tautology. Whether the number of messages is excessive is highly dependent on where, when and how often. In particular, if SA *establishment* is not in a critical path for handoffs, its doubtful that "too many" applies. > In addition, IKE requires either PKI or a pre shared secret between the two > entities that are setting up the SA ! > Do you believe that PKI will be ready soon ? You really only get into trouble when you start positing global PKI's. Crypto using PKI's which do not have global implications are currently shipping. > As for the pre-shared secret between the MN and Mobility agents, do you > think that such solutions is really scalable ? > For those reasons, we suggest to use AAA servers. AAA is *not* the only other choice. In fact, using AAA for key distribution isn't even standard (yes, Pat, I mean that. a draft is not a standard and this area could and should change considerably before DIAMETER is baked). The current IETF protocol for symmetric key distribution is Kerberos. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 20:14:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11644 for ; Thu, 15 Mar 2001 20:14:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23973; Thu, 15 Mar 2001 17:13:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06658; Thu, 15 Mar 2001 17:13:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1CEIm008621 for ; Thu, 15 Mar 2001 17:12:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G1CDYY008620 for mobile-ip-dist; Thu, 15 Mar 2001 17:12:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1C5Im008613 for ; Thu, 15 Mar 2001 17:12:05 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06583 for ; Thu, 15 Mar 2001 17:12:05 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA08550 for ; Thu, 15 Mar 2001 17:12:05 -0800 (PST) Message-Id: <200103160112.RAA08550@heliopolis.Eng.Sun.COM> Date: Thu, 15 Mar 2001 17:12:05 -0800 (PST) From: James Kempf Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...) To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GI6Vrnuoto8p2CKVjN8AuQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, >> We would like to see elimination of *all* tunnelling overhead over >> the air (and that includes HA overhead folks) if possible. For example, >> by stripping it on at the last hop router, where it is no longer >> needed. >> >> Barring that, we would like to see an analysis that indicates header >> compression will work to eliminate tunnelling overhead, and that >> it can be moved quickly enough during handover that it will not >> negate the gains of the low latency handover protocol. >> > => I am not an expert on header compression by any means > but based on my several discussions with some experts in > the area, I was told that ROHC will handle tunnelling > and Extension headers at no extra cost over the air. > > So if this true,I wonder if tunnelling is a problem. > Right, the issue isn't whether compression will handle them, it is the overhead in reestablishing the state after handover. >> I do not >> get the feeling from the Seamoby context transfer problem statement >> draft that this is possible. >> > => I haven't looked into it in detail, have you > heard of some reasons ? > Perhaps this context transfer discussion needs to be > taken to the seamoby list, but I'm wondering what > the negative impacts are if we do not transfer the > context for header compression. In the worste > case scenario I am told that maybe 2 or 3 packets > will be sent with a full header. But that doesn't > mean loss of service, just a short period of inefficiency > over the air. Is that true ? Does anynoe know more about > this ? > I have heard more than 2 or 3 packets, but I do not know for sure. Perhaps we can bring this up during the Seamoby meeting next week. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 20:25:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11811 for ; Thu, 15 Mar 2001 20:25:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28127; Thu, 15 Mar 2001 17:23:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05530; Thu, 15 Mar 2001 17:22:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1KsIm008711 for ; Thu, 15 Mar 2001 17:20:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G1KrXw008710 for mobile-ip-dist; Thu, 15 Mar 2001 17:20:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G1KjIm008703 for ; Thu, 15 Mar 2001 17:20:45 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2G1JWI22060 for mobile-ip@sunroof.eng.sun.com; Thu, 15 Mar 2001 17:19:32 -0800 (PST) From: Mohan Parthasarathy Message-Id: <200103160119.f2G1JWI22060@locked.eng.sun.com> Subject: Re: [mobile-ip] Re: Comments on Regional Registration In-Reply-To: <15025.26470.377047.623161@thomasm-u1.cisco.com> from Michael Thomas at "Mar 15, 2001 05:07:50 pm" To: mobile-ip@sunroof.eng.sun.com Date: Thu, 15 Mar 2001 17:19:32 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Franck.Le@nokia.com writes: > > IKE requires too many messages to be exchanged so that may be not be the > > most optimized solution to set up the security associations between the MN > > and Mobility agents: IPsec WG is already designing a new protocol "Son of > > IKE". > > IPsec WG is doing no such thing. They are *thinking* about > Son of IKE, but nothing is definite now. > > Also: a categorical "too many messages" is a > tautology. Whether the number of messages is > excessive is highly dependent on where, > when and how often. In particular, if SA > *establishment* is not in a critical path > for handoffs, its doubtful that "too many" > applies. > Agreed. Hopefully, you should not be negotiating SAs that often. In fast handoffs, you may typically want to forward packets from the previous care of address as mentioned in the MIipv6 draft (i have not read the fast handoff draft). This makes you send a binding update to the previous router. If this needs to be protected using IPsec, you have to negotiate SAs as you move and also it is during the fast handoff. May be we can use a different scheme in this case. -mohan > > In addition, IKE requires either PKI or a pre shared secret between the two > > entities that are setting up the SA ! > > Do you believe that PKI will be ready soon ? > > You really only get into trouble when you start positing > global PKI's. Crypto using PKI's which do not > have global implications are currently shipping. > > > As for the pre-shared secret between the MN and Mobility agents, do you > > think that such solutions is really scalable ? > > For those reasons, we suggest to use AAA servers. > > AAA is *not* the only other choice. In fact, > using AAA for key distribution isn't even > standard (yes, Pat, I mean that. a draft is > not a standard and this area could and should > change considerably before DIAMETER is > baked). The current IETF protocol for > symmetric key distribution is Kerberos. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 22:05:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13420 for ; Thu, 15 Mar 2001 22:05:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29267; Thu, 15 Mar 2001 19:03:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08015; Thu, 15 Mar 2001 19:03:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G31kIm008879 for ; Thu, 15 Mar 2001 19:01:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G31jk7008878 for mobile-ip-dist; Thu, 15 Mar 2001 19:01:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G31UIm008871 for ; Thu, 15 Mar 2001 19:01:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07853 for ; Thu, 15 Mar 2001 19:01:25 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14803 for ; Thu, 15 Mar 2001 20:01:24 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA12676 for ; Thu, 15 Mar 2001 19:01:24 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G31NV12537 for ; Thu, 15 Mar 2001 19:01:23 -0800 X-mProtect: Thu, 15 Mar 2001 19:01:23 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdG1nVny; Thu, 15 Mar 2001 19:01:17 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA14790 for ; Thu, 15 Mar 2001 19:01:17 -0800 (PST) Message-ID: <3AB181FD.B78FA93F@iprg.nokia.com> Date: Thu, 15 Mar 2001 19:01:17 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <034BEFD03799D411A59F00508BDF7546013DBC7E@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > > Once we introduce an intermediary point (HA/RMA/MAP) with mobility > > bindings > > we introduce state used in a similar way as state used for maintaining > > plain next hop forwarding. > > > => The next hop forwarding in the MAP depends on the routing > protocols in the domain. The next hop forwarding in Regional > is forced (like a static route). There is a big difference. > You might ague that reg6 is part of MIP, hence can be > classified as a routing protocol, but I would say that > any routing protocol that reserves a "circuit-like" path > in the IP network is not acceptable. It is to be noted that in our current version you can use regular tunneling or host-based routing (depending on whether you have next-hop as regreg-aware router) as well so there is no difference other than having more than one possible levels of binding-based forwarding points. Regional forwarding is an optimization not in the base draft. The protocol itself considers the basic signaling of using a hierarchy, forming the hierarchy dynamically and maintaining it in a way that a router failure can be bypassed is a matter for a dynamic configuration protocol for the hierarchy. You said you are working on such a thing for making MAPs not a single point of failure. Is there some fundamental reason why such a protocol is possible only for one level of hierarchy? > > I read your use of term connection-oriented to > > mean the use of mobility bindings for forwarding instead of exclusively relying on host/network/default routes. Introducing robustness > > in this form of forwarding is a problem both HMIP and regreg6 face. > > In fact, even basic Mobile IPv6 while forwarding packets via the > > home agent has this feature. > > > => The robustness in terms of introducing a single point > of failure may be similar, but adding a less robust path > to the MN from the GMA is not acceptable, and clearly > this is not just my opinion. The robustness is a function dependent on possiblity to have a configuration protocol. Your extended mode with mobile routers in some situations uses more than one layer of MAPs. Why then is that acceptable? > Regards, > Hesham Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 22:18:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13504 for ; Thu, 15 Mar 2001 22:18:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03357; Thu, 15 Mar 2001 19:17:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22248; Thu, 15 Mar 2001 19:17:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3F3Im008932 for ; Thu, 15 Mar 2001 19:15:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G3F3G0008931 for mobile-ip-dist; Thu, 15 Mar 2001 19:15:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3ErIm008924 for ; Thu, 15 Mar 2001 19:14:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21895 for ; Thu, 15 Mar 2001 19:14:53 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10548 for ; Thu, 15 Mar 2001 19:14:52 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA13621 for ; Thu, 15 Mar 2001 19:14:52 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G3EnT22056 for ; Thu, 15 Mar 2001 19:14:49 -0800 X-mProtect: Thu, 15 Mar 2001 19:14:49 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdLFVgIQ; Thu, 15 Mar 2001 19:14:41 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA14803 for ; Thu, 15 Mar 2001 19:14:44 -0800 (PST) Message-ID: <3AB18524.BEBBD800@iprg.nokia.com> Date: Thu, 15 Mar 2001 19:14:44 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simplified Hierarchical MIPv6 (was...) References: <034BEFD03799D411A59F00508BDF7546013DBC89@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > > I don't want to get into a long discussion over this, since I've > > got a lot of other stuff to do before I leave for the Mini-Apple > > on Sun., but the fact remains that both hierarchical proposals introduce > > extra signalling and also some extra tunneling overhead over the air. > > Air resources are scarce if the network operator needs to pay for them, > > and so reducing air time is a significant plus. > > > => Sure air resources are scarce and expensive, especially > in many cellular systems where they cost billions. > BUT, even one IPv6 header is too expensive, especially for real > time services. So what does every IP based cellular system > do, they use Header compression. It can handle tunnelling. There are some reasons why we can do better by considering last hop resource usage on the network layer than delegating it to the header compression, which is a link-layer optimization. To my knowledge, header compression is application specific. You need to set up the context to use it and that depends on what application you are running. Setting it up for voice is different from e.g. for video. What if you have application for which you do not have a method? If you can strip tunneling by a simple application-independent IP forwarding trick, then why not? Also, why should we mandate support for header compression to have efficient bandwidth usage? I do not think we should ignore WLAN-like interfaces, either, where header-compression is not included. This is because if we care about scalability we have also the dimension of multiple mobile nodes. Even though your bandwidth may be 11Mbps, that does not mean it cannot be crowded by simply having a big enough number of mobile nodes. I believe we provide an alternative design where these issues are considered at least to some degree, and as options not mandated by the base design. Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 22:42:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14703 for ; Thu, 15 Mar 2001 22:42:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02133; Thu, 15 Mar 2001 19:40:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25546; Thu, 15 Mar 2001 19:40:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3cYIm008989 for ; Thu, 15 Mar 2001 19:38:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G3cX5O008988 for mobile-ip-dist; Thu, 15 Mar 2001 19:38:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3cOIm008981 for ; Thu, 15 Mar 2001 19:38:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01352 for ; Thu, 15 Mar 2001 19:38:24 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10586 for ; Thu, 15 Mar 2001 20:38:23 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2G3cLC27383 for ; Fri, 16 Mar 2001 04:38:21 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 16 04:38:20 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 04:40:06 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC91@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Fri, 16 Mar 2001 04:38:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > Once we introduce an intermediary point (HA/RMA/MAP) with mobility > > > bindings > > > we introduce state used in a similar way as state used for maintaining > > > plain next hop forwarding. > > > > > => The next hop forwarding in the MAP depends on the routing > > protocols in the domain. The next hop forwarding in Regional > > is forced (like a static route). There is a big difference. > > You might ague that reg6 is part of MIP, hence can be > > classified as a routing protocol, but I would say that > > any routing protocol that reserves a "circuit-like" path > > in the IP network is not acceptable. > > It is to be noted that in our current version you can use regular > tunneling or host-based routing (depending on whether you have > next-hop as regreg-aware router) as well so there is no difference > other than having more than one possible levels of binding-based > forwarding points. Regional forwarding is an optimization not > in the base draft. > => So in the case where you use tunnelling you basically have HMIPv6 in Extended mode. Correct ? I don't have a problem with this and it is already supported. My criticism was tageting the other case. > The protocol itself considers the basic signaling of using a > hierarchy, forming the hierarchy dynamically and maintaining it > in a way that a router failure can be bypassed is a matter for > a dynamic configuration protocol for the hierarchy. You said you > are working on such a thing for making MAPs not a single point of > failure. Is there some fundamental reason why such a protocol > is possible only for one level of hierarchy? > => It is not really easy to do it for an extended mode MAP, which is what you base your draft on. However, as HW designers say, it's just SW and everything is possible, but that's not my point. My point is that the multi-level hierarchy is not justified. Even if we somehow develop a redundancy solution, this will add significant cost and I can't see why it's needed. So what's the justification for the additional cost and overriding the routing protocols ? > > > I read your use of term connection-oriented to > > > mean the use of mobility bindings for forwarding instead of exclusively relying on host/network/default routes. Introducing robustness > > > in this form of forwarding is a problem both HMIP and regreg6 face. > > > In fact, even basic Mobile IPv6 while forwarding packets via the > > > home agent has this feature. > > > > > => The robustness in terms of introducing a single point > > of failure may be similar, but adding a less robust path > > to the MN from the GMA is not acceptable, and clearly > > this is not just my opinion. > > The robustness is a function dependent on possiblity to have a > configuration protocol. Your extended mode with mobile routers > in some situations uses more than one layer of MAPs. Why then is > that acceptable? > => It does not require any special routing between the MR and the upstream MAP. Normal routing protocols can be used. It is also needed to support route optimisation for nodes connected to the MR. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 22:49:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14772 for ; Thu, 15 Mar 2001 22:49:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11330; Thu, 15 Mar 2001 19:46:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29867; Thu, 15 Mar 2001 19:46:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3jXIm009029 for ; Thu, 15 Mar 2001 19:45:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G3jWBg009028 for mobile-ip-dist; Thu, 15 Mar 2001 19:45:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3jNIm009021 for ; Thu, 15 Mar 2001 19:45:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02155 for ; Thu, 15 Mar 2001 19:45:23 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15764 for ; Thu, 15 Mar 2001 20:45:22 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2G3jKd15535 for ; Fri, 16 Mar 2001 04:45:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 16 04:45:25 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 04:47:05 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC92@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...) Date: Fri, 16 Mar 2001 04:45:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > I don't want to get into a long discussion over this, since I've > > > got a lot of other stuff to do before I leave for the Mini-Apple > > > on Sun., but the fact remains that both hierarchical proposals introduce > > > extra signalling and also some extra tunneling overhead over the air. > > > Air resources are scarce if the network operator needs to pay for them, > > > and so reducing air time is a significant plus. > > > > > => Sure air resources are scarce and expensive, especially > > in many cellular systems where they cost billions. > > BUT, even one IPv6 header is too expensive, especially for real > > time services. So what does every IP based cellular system > > do, they use Header compression. It can handle tunnelling. > > There are some reasons why we can do better by considering last hop > resource usage on the network layer than delegating it to the header > compression, which is a link-layer optimization. To my knowledge, > header compression is application specific. You need to set up the > context to use it and that depends on what application you are > running. Setting it up for voice is different from e.g. for video. > What if you have application for which you do not have a method? > => Like what ? As far as I know neither the application nor the IP stack needs to be aware of Header compression. Perhaps what you're referring to is the setup of special radio bearers for special applications. But I don't see the relevance to header compression. Can you give an example ? > If you can strip tunneling by a simple application-independent > IP forwarding trick, then why not? Also, why should we mandate > support for header compression to have efficient bandwidth usage? > => We're not mandating anything, it's already in every low/scarce BW link. This is not something we're adding. > I do not think we should ignore WLAN-like interfaces, either, where > header-compression is not included. > => Nothing stops it from being included. Header compression was included by designers of sytems/links that saw the need for it, like dialup lines and cellular networks. There is nothing in the spec (to my knowledge) that stops other systems from using it. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 22:51:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14809 for ; Thu, 15 Mar 2001 22:51:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11666; Thu, 15 Mar 2001 19:47:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26700; Thu, 15 Mar 2001 19:47:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3k7Im009039 for ; Thu, 15 Mar 2001 19:46:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G3k6Mj009038 for mobile-ip-dist; Thu, 15 Mar 2001 19:46:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G3jpIm009031 for ; Thu, 15 Mar 2001 19:45:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26460 for ; Thu, 15 Mar 2001 19:45:50 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04963 for ; Thu, 15 Mar 2001 19:45:50 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA15368 for ; Thu, 15 Mar 2001 19:45:50 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G3joR13449 for ; Thu, 15 Mar 2001 19:45:50 -0800 X-mProtect: Thu, 15 Mar 2001 19:45:50 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdDtywgt; Thu, 15 Mar 2001 19:45:45 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA14833 for ; Thu, 15 Mar 2001 19:45:45 -0800 (PST) Message-ID: <3AB18C69.D8255305@iprg.nokia.com> Date: Thu, 15 Mar 2001 19:45:45 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Comments on Regional Registration References: <034BEFD03799D411A59F00508BDF7546013DBC8A@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, > > > > Proposing a solution for setting up an SA with an > > > > anycast group would be a great proposal, but > > > > I don't think we need several standards to solve > > > > this particular problem. We already have a solution > > > > and I'm starting to question the need for alternatives > > > > if nothing is raised against HMIPv6. Especally if > > > > the alternative is a lot less robust and overrides > > > > the use of standard routing between the anchor point > > > > and the MN. I believe we are not overriding standard routing in the base draft. Regional forwarding is only optional, you can also use regular tunneling or host-based routing (if on-link). Using more than one layer has the same principle of binding-driven forwarding that is the case with MAP usually with one layer, or sometimes with more than one layer (extended mode, mobile routers). HMIP does not do everything possible to preserve last hop bandiwdth usage efficiency and scalability. > > > > > > actually that there are different proposals on the way to set up > > > Security > > > Associations and to authenticate the BU using AH in Appendix B of the > > draft. > > > > > => Yes I saw that, but this is hardly a standard or an accepted > > method, I don't think we can base it on the appendix surely. > > Even if we can, my main point is why are we adding all this > > complication to achieve the same effect that HMIPv6 does ? > > I haven't heard an answer till now. There is more text because alternative modes are provided. In fact, there can be a mode where IKE is used, you do not then use anycast. However, as heard from some authoritative parties, PKI is not ubiqutous anytime soon and simply using IPSec is not going to solve the authorization problem. Considering AAA is therefore needed and doing it in a more verbose way than HMIP is not necessarily regreg6-specific complexity. Remember the AAAL functionality tends to be at the edge, HMIP also has some "complication" when this is specified in detail. Still about the motivation you repeatedly tell us is missing: Having localized mobility is supposed to be optimization in the first place. Why not then try to do it to the fullest, solve the basic problem of reducing signaling load (there I agree one level is enough to have the fixed CoA), _and_ localizing the location update to the maximum. There we can use multiple levels to bring responder closer to the mobile node than where the fixed address resides. If we have mobile routers, what if they use costly links when forming the hierarchy, is it not feasible to consider that we could have localized signaling below that? > > Hesham Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 23:31:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15369 for ; Thu, 15 Mar 2001 23:31:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22611; Thu, 15 Mar 2001 20:30:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07896; Thu, 15 Mar 2001 20:29:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G4SfIm009156 for ; Thu, 15 Mar 2001 20:28:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G4SeoV009155 for mobile-ip-dist; Thu, 15 Mar 2001 20:28:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G4SVIm009148 for ; Thu, 15 Mar 2001 20:28:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18295 for ; Thu, 15 Mar 2001 20:28:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20655 for ; Thu, 15 Mar 2001 20:28:31 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA18392 for ; Thu, 15 Mar 2001 20:28:31 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G4SRn13440 for ; Thu, 15 Mar 2001 20:28:27 -0800 X-mProtect: Thu, 15 Mar 2001 20:28:27 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdnemAWy; Thu, 15 Mar 2001 20:28:19 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id UAA14870 for ; Thu, 15 Mar 2001 20:28:22 -0800 (PST) Message-ID: <3AB19666.A3D0BEA1@iprg.nokia.com> Date: Thu, 15 Mar 2001 20:28:22 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <034BEFD03799D411A59F00508BDF7546013DBC91@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > It is to be noted that in our current version you can use regular > > tunneling or host-based routing (depending on whether you have > > next-hop as regreg-aware router) as well so there is no difference > > other than having more than one possible levels of binding-based > > forwarding points. Regional forwarding is an optimization not > > in the base draft. > > > => So in the case where you use tunnelling you basically > have HMIPv6 in Extended mode. Correct ? No, the signaling and localizing location update is different. The load balancing is different. You base it all on cooperation of the mobile node, we let the network do it automated by the crossover functionality. > I don't have a problem with this and it is already supported. > My criticism was tageting the other case. > > > The protocol itself considers the basic signaling of using a > > hierarchy, forming the hierarchy dynamically and maintaining it > > in a way that a router failure can be bypassed is a matter for > > a dynamic configuration protocol for the hierarchy. You said you > > are working on such a thing for making MAPs not a single point of > > failure. Is there some fundamental reason why such a protocol > > is possible only for one level of hierarchy? > > > => It is not really easy to do it for an extended mode > MAP, which is what you base your draft on. I do not believe it is trivial for one level either. > So what's the justification for the additional cost > and overriding the routing protocols ? Better optimization of last hop bandwidth usage, network-controlled load balancing (your scheme has hop count and priority in a MAP option, these trust MN does something it may not be designed to do and require more than one MAP options to make a choice even possible). > > The robustness is a function dependent on possiblity to have a > > configuration protocol. Your extended mode with mobile routers > > in some situations uses more than one layer of MAPs. Why then is > > that acceptable? > > > => It does not require any special routing between > the MR and the upstream MAP. Normal routing protocols > can be used. Having nested mobile routers will bring multiple layers of MAP-based forwarding. > Regards, > Hesham Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 15 23:59:33 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15836 for ; Thu, 15 Mar 2001 23:59:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08036; Thu, 15 Mar 2001 20:58:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09545; Thu, 15 Mar 2001 20:57:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G4uHIm009225 for ; Thu, 15 Mar 2001 20:56:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G4uGXC009224 for mobile-ip-dist; Thu, 15 Mar 2001 20:56:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G4u7Im009217 for ; Thu, 15 Mar 2001 20:56:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09366 for ; Thu, 15 Mar 2001 20:56:07 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06161 for ; Thu, 15 Mar 2001 20:56:06 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2G4u4d28711 for ; Fri, 16 Mar 2001 05:56:05 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 16 05:57:49 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 05:52:04 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC96@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt Date: Fri, 16 Mar 2001 05:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > The protocol itself considers the basic signaling of using a > > > hierarchy, forming the hierarchy dynamically and maintaining it > > > in a way that a router failure can be bypassed is a matter for > > > a dynamic configuration protocol for the hierarchy. You said you > > > are working on such a thing for making MAPs not a single point of > > > failure. Is there some fundamental reason why such a protocol > > > is possible only for one level of hierarchy? > > > > > => It is not really easy to do it for an extended mode > > MAP, which is what you base your draft on. > > I do not believe it is trivial for one level either. > => You've missed my point, the number of levels is not relevant, it is difficult for the Extended mode. We believe it is easy to do it for basic mode. Your proposal relies on using the GMA's address which is the same address management as the MAP in Extended mode. > > So what's the justification for the additional cost > > and overriding the routing protocols ? > > Better optimization of last hop bandwidth usage, network-controlled > load balancing (your scheme has hop count and priority in a MAP > option, these trust MN does something it may not be designed to > do and require more than one MAP options to make a choice even > possible). > => Are you referring to the MAP option ? I hope this is not the BW argument. This argument is not valid IMO. RAs are designed to have several options regardless of the use of MIP. I hope we can agree on that. Now regarding the parameters in the MAP option, I don't see what the MN would have difficulty with. If the MN supports HMIPv6 then it MUST understand the option. If it does something wrong, like choosing a MAP with a 255 preference (indicating that it should not be used), the MAP will simply reject the BU. What's the problem with that ? > > > The robustness is a function dependent on possiblity to have a > > > configuration protocol. Your extended mode with mobile routers > > > in some situations uses more than one layer of MAPs. Why then is > > > that acceptable? > > > > > => It does not require any special routing between > > the MR and the upstream MAP. Normal routing protocols > > can be used. > > Having nested mobile routers will bring multiple layers of > MAP-based forwarding. > =>. No. The MNs on the Mobile networks will have a prefix that belongs to the MR. Hence the "further" MAP will tunnel to the MR, which will simply decapsulate the packets and forwad them to the MN. Is that what you mean by MAP based forwarding ? Tunnelling to the MR (MAP in this case) is the same as tunnelling to the end node. I don't see the difference, the packets can take multiple paths between the higher MAP and the MR as per standard routing. So your statement does not state what the disadvantage is with this approach. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 16 01:06:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16799 for ; Fri, 16 Mar 2001 01:06:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA24000; Thu, 15 Mar 2001 22:05:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11265; Thu, 15 Mar 2001 22:05:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G63cIm009274 for ; Thu, 15 Mar 2001 22:03:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G63b1U009273 for mobile-ip-dist; Thu, 15 Mar 2001 22:03:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G63SIm009266 for ; Thu, 15 Mar 2001 22:03:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11086 for ; Thu, 15 Mar 2001 22:03:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27981 for ; Thu, 15 Mar 2001 22:03:27 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA22075 for ; Thu, 15 Mar 2001 22:03:26 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2G63P432382 for ; Thu, 15 Mar 2001 22:03:25 -0800 X-mProtect: Thu, 15 Mar 2001 22:03:25 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(WTS.12.69) smtpdylqM5M; Thu, 15 Mar 2001 22:03:18 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id WAA14959 for ; Thu, 15 Mar 2001 22:03:19 -0800 (PST) Message-ID: <3AB1ACA7.F56B5A40@iprg.nokia.com> Date: Thu, 15 Mar 2001 22:03:19 -0800 From: "Jari T. Malinen" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt References: <034BEFD03799D411A59F00508BDF7546013DBC96@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Your proposal relies on using the GMA's address > which is the same address management as the MAP > in Extended mode. > > > > So what's the justification for the additional cost > > > and overriding the routing protocols ? I believe we are not overriding routing protocols any more than you are, once we compare with your extended mode. > > Better optimization of last hop bandwidth usage, network-controlled > > load balancing (your scheme has hop count and priority in a MAP > > option, these trust MN does something it may not be designed to > > do and require more than one MAP options to make a choice even > > possible). > > > => Are you referring to the MAP option ? > I hope this is not the BW argument. This argument is > not valid IMO. RAs are designed to have several > options regardless of the use of MIP. I hope we can agree on that. We can still try to reduce the size of the RA, i.e. number of extensions needed for a load-balancing network. > Now regarding the parameters in the MAP option, > I don't see what the MN would have difficulty with. > If the MN supports HMIPv6 then it MUST understand > the option. If it does something wrong, like choosing > a MAP with a 255 preference (indicating that it should > not be used), the MAP will simply reject the BU. > What's the problem with that ? You rely on the MN to behave correctly. Also, you do not specify the load balancing, you need external box to do that. Also, the load balancing with static values is questionable. What if you have preferences 1,2,3, and differenc hop counts, all MNs go to 1 until administrator changes the order. Also, MN only SHOULD follow this order, they thus MAY ignore it. Operator has no control in that case, he may only speculate which configuration possibility a MAP-aware MN in question has chosen, does it follow the SHOULD or does it not. If it simply denies service for those who do not follow the SHOULD, this has the effect of no operation for those MNs. Furthermore, a change of MAP means re-registration with every CN in the Internet while changing a crossover router does not. > > Having nested mobile routers will bring multiple layers of > > MAP-based forwarding. > > > =>. No. The MNs on the Mobile networks will have a prefix > that belongs to the MR. Hence the "further" MAP will > tunnel to the MR, which will simply decapsulate the > packets and forwad them to the MN. Is that what you > mean by MAP based forwarding ? Further MAP has tunneling state. If you have mobile node below the mobile router, are you not having the mobile router as a MAP ? Does the MN attached to the mobile network need to register with the lower MAP to be operational when the lower MAP is at home ? The MAP is the entry point to the mobile network and is another "single point of failure" on the path of the packet. What if you add another mobile router below the mobile router ? I suspect you also may have multiple layers. In that case, same robustness arguments apply both ways. > Tunnelling to the MR (MAP in this case) is the same > as tunnelling to the end node. I don't see the difference, > the packets can take multiple paths between the higher > MAP and the MR as per standard routing. So can a tunneled packet from GMA to the next lower RMA follow any path natural routing might use. > So your statement does not state what the disadvantage > is with this approach. Bandwidth usage, more distant target for the localized binding update. Mobile-controlled load balancing. Designers of networks may want to exercise more stringent control on how mobile nodes move in their network. Load balancing should be such that you can have the same mobile node cause location update with a new box without signaling out of the visited domain. In HMIP, when MAP is changed, MN needs to re-register with all CNs. In fact, you have a solution to newly arriving MNs, not for the population already attached. > Regards, > Hesham Best Regards, -Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 16 04:53:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01221 for ; Fri, 16 Mar 2001 04:53:11 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14184; Fri, 16 Mar 2001 01:50:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06798; Fri, 16 Mar 2001 01:50:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9nDIm009719 for ; Fri, 16 Mar 2001 01:49:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2G9nCfu009718 for mobile-ip-dist; Fri, 16 Mar 2001 01:49:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2G9n3Im009711 for ; Fri, 16 Mar 2001 01:49:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06701 for ; Fri, 16 Mar 2001 01:49:03 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20353 for ; Fri, 16 Mar 2001 01:49:02 -0800 (PST) Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id KAA13367 for ; Fri, 16 Mar 2001 10:49:01 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id KAA03531 for ; Fri, 16 Mar 2001 10:47:57 +0100 (MET) Message-ID: <3AB1E14D.E98621A2@inrialpes.fr> Date: Fri, 16 Mar 2001 10:47:57 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] -HMIPv6 draft + Privacy draft- References: <85AA7486A2C1D411BCA20000F8073E43018BA73C@crchy271.us.nortel.com> Content-Type: multipart/alternative; boundary="------------6EE98FE4DC46ED6DF88E63C4" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------6EE98FE4DC46ED6DF88E63C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, We actually have a (preliminary) draft that tries to tackle the problem of route optimal location privacy in MIPv6. The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my web site : http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt or from the IETF ID repository... Note also that we have a new version of HMIPv6 (version 3) that clarifies some aspects of HMIPv6 and highlights some of its advantages (see section 6.5 or 6.6 for example). This new version can be retrieved at: http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt comments welcome.... regards, Claude. Glenn Morrow wrote: > > > Yes - there is no accepted or even tabled proposal yet for route > optimal location privacy. I believe it is a requirement even MIP > should strive for as we move forward. > > > > => True. But the same goes for any IP adderss in the > hierarchical > IPv6 world. Right ? > > Hesham -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------6EE98FE4DC46ED6DF88E63C4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

We actually have a  (preliminary) draft that tries to tackle the problem of route optimal location privacy in MIPv6.
The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my web site : http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt or from the IETF
ID repository...

Note also that we have a new version of HMIPv6 (version 3) that clarifies some aspects of HMIPv6 and
highlights some of its advantages (see section 6.5 or 6.6 for example). This new version can be retrieved at:
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt

comments welcome....

regards,

Claude.

Glenn Morrow wrote:

 

Yes - there is no accepted or even tabled proposal yet for route optimal location privacy. I believe it is a requirement even MIP should strive for as we move forward.
 
 

        => True. But the same goes for any IP adderss in the hierarchical
        IPv6 world. Right ?

        Hesham

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------6EE98FE4DC46ED6DF88E63C4-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 16 05:05:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01280 for ; Fri, 16 Mar 2001 05:05:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20853; Fri, 16 Mar 2001 02:02:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08001; Fri, 16 Mar 2001 02:02:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GA1ZIm009754 for ; Fri, 16 Mar 2001 02:01:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GA1ZOr009753 for mobile-ip-dist; Fri, 16 Mar 2001 02:01:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GA1QIm009746 for ; Fri, 16 Mar 2001 02:01:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05648 for ; Fri, 16 Mar 2001 02:01:26 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23387 for ; Fri, 16 Mar 2001 02:01:25 -0800 (PST) Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id LAA13806 for ; Fri, 16 Mar 2001 11:01:24 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id LAA03544 for ; Fri, 16 Mar 2001 11:00:20 +0100 (MET) Message-ID: <3AB1E433.1FC11EC7@inrialpes.fr> Date: Fri, 16 Mar 2001 11:00:20 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simplified Hierarchical MIPv6 (was...) References: <200103160112.RAA08550@heliopolis.Eng.Sun.COM> Content-Type: multipart/alternative; boundary="------------7ACA6D23F70E7E4D7363445A" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------7ACA6D23F70E7E4D7363445A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Kempf wrote: > Hesham, > > >> We would like to see elimination of *all* tunnelling overhead over > >> the air (and that includes HA overhead folks) if possible. For example, > >> by stripping it on at the last hop router, where it is no longer > >> needed. > >> > >> Barring that, we would like to see an analysis that indicates header > >> compression will work to eliminate tunnelling overhead, and that > >> it can be moved quickly enough during handover that it will not > >> negate the gains of the low latency handover protocol. > >> > > => I am not an expert on header compression by any means > > but based on my several discussions with some experts in > > the area, I was told that ROHC will handle tunnelling > > and Extension headers at no extra cost over the air. > > > > So if this true,I wonder if tunnelling is a problem. > > > > Right, the issue isn't whether compression will handle them, it is the overhead > in reestablishing the state after handover. > So this is not a problem of HMIPv6...this is a more general problem? You get this problem whenever you are performing header compression... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------7ACA6D23F70E7E4D7363445A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit James Kempf wrote:
Hesham,

>> We would like to see elimination of *all* tunnelling overhead over
>> the air (and that includes HA overhead folks) if possible. For example,
>> by stripping it on at the last hop router, where it is no longer
>> needed.
>>
>> Barring that, we would like to see an analysis that indicates header
>> compression will work to eliminate tunnelling overhead, and that
>> it can be moved quickly enough during handover that it will not
>> negate the gains of the low latency handover protocol.
>>
>       => I am not an expert on header compression by any means
>       but based on my several discussions with some experts in
>       the area, I was told that ROHC will handle tunnelling
>       and Extension headers at no extra cost over the air.
>
>       So if this true,I wonder if tunnelling is a problem.
>

Right, the issue isn't whether compression will handle them, it is the overhead
in reestablishing the state after handover.
 

So this is not a problem of HMIPv6...this is a more general problem? You get this problem
whenever you are performing header compression...

regards,
Claude. 




-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------7ACA6D23F70E7E4D7363445A--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 05:24:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01462
	for ; Fri, 16 Mar 2001 05:24:05 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18625;
	Fri, 16 Mar 2001 02:22:55 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09423;
	Fri, 16 Mar 2001 02:22:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GALiIm009825
	for ; Fri, 16 Mar 2001 02:21:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GALiLl009824
	for mobile-ip-dist; Fri, 16 Mar 2001 02:21:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GALZIm009817
	for ; Fri, 16 Mar 2001 02:21:35 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03626
	for ; Fri, 16 Mar 2001 02:21:35 -0800 (PST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17568
	for ; Fri, 16 Mar 2001 02:21:34 -0800 (PST)
Received: from fokus.gmd.de (centauri [193.175.132.71])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA20362;
	Fri, 16 Mar 2001 11:21:33 +0100 (MET)
Message-ID: <3AB1E92C.FFE30D9C@fokus.gmd.de>
Date: Fri, 16 Mar 2001 11:21:32 +0100
From: Reinhard Ruppelt 
Organization: GMD FOKUS / MOBIS
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile IP on Windows ?
References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> <20010313224837.21080.qmail@web3102.mail.yahoo.com> <4.3.2.7.2.20010314134425.00b12208@pita.cisco.com> <3AB081BB.E750868D@fokus.gmd.de> <02f201c0ada3$1ef7e190$e1486080@cc.telcordia.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f2GALaIm009818
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Bill,
the RoamIn software is not (yet) available as developers source. (We consider
the release of the sources.)
Regards, Reinhard

"William R. Macre" wrote:

> I'm monitoring the messages on the MobileIP e-mail list and came across this
> request for MIP running on Windows.  We are doing some research in 3GPP
> networking and would also be interested in this software.  One question I
> have is " Is this software available as developers source for free or
> license(for fee)?"

--
GMD FOKUS / MOBIS
German National Research Center for Information Technology
- Institute for Open Communication Systems -
Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany
Voice: +49 30 3463-7249, Fax: -8249
Email: Reinhard.Ruppelt@gmd.de
WWW: www.fokus.gmd.de/usr/reinhard.ruppelt/




From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 06:43:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02124
	for ; Fri, 16 Mar 2001 06:43:11 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22344;
	Fri, 16 Mar 2001 03:36:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22080;
	Fri, 16 Mar 2001 03:36:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GBYlIm009932
	for ; Fri, 16 Mar 2001 03:34:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GBYkBE009931
	for mobile-ip-dist; Fri, 16 Mar 2001 03:34:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GBYcIm009924
	for ; Fri, 16 Mar 2001 03:34:38 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22006
	for ; Fri, 16 Mar 2001 03:34:38 -0800 (PST)
From: Phil_Neumiller@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00022
	for ; Fri, 16 Mar 2001 03:34:37 -0800 (PST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GBXAd16935
	for ; Fri, 16 Mar 2001 03:33:10 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2GBYaE02836
	for ; Fri, 16 Mar 2001 03:34:36 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256A11.003F9643 ; Fri, 16 Mar 2001 03:34:32 -0800
X-Lotus-FromDomain: 3COM
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256A11.003F9437.00@hqoutbound.ops.3com.com>
Date: Fri, 16 Mar 2001 05:33:28 -0600
Subject: [mobile-ip] Historical MIP question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


Since the micro-moblity work and the fast handover work are similar in nature
and the spaces that they will serve and live in, there have been some
disputes.  This was to be expected.  I see no reason why they can't both
peacefully co-exist along with MIP.  I see no reason why there needs to any
further hostility between them.  Onto my question.

I have been digging through the MIP archives and there is much-o stuff there
and I have been unable to piece together a problem statement for fast handoff.
Perhaps some of the MIP folk can assure me that its in there.  That is good
enough for me.

I am curious though, are their a set of formal problem statements, and
requirements that  led to the chartering of the fast handoff work in the MIP
group or is this a cruel new experiment that the IESG is trying on fledgling
mobility groups like SeaMoby to put ex-co-chairs into straight jackets
and in the desperate need of a drool bucket (to quote an  IETFr)?

Thanks,

Phil Neumiller




From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 09:03:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03825
	for ; Fri, 16 Mar 2001 09:03:15 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26446;
	Fri, 16 Mar 2001 06:01:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02340;
	Fri, 16 Mar 2001 06:01:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GE0JIm010209
	for ; Fri, 16 Mar 2001 06:00:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GE0ISY010208
	for mobile-ip-dist; Fri, 16 Mar 2001 06:00:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GE0AIm010201
	for ; Fri, 16 Mar 2001 06:00:10 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02120
	for ; Fri, 16 Mar 2001 06:00:11 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA14919
	for ; Fri, 16 Mar 2001 06:00:11 -0800 (PST)
Message-Id: <200103161400.GAA14919@heliopolis.Eng.Sun.COM>
Date: Fri, 16 Mar 2001 06:00:11 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Simplified Hierarchical MIPv6 (was...)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xjBzCO3wJH096IPuVomtDg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Claude,


>So this is not a problem of HMIPv6...this is a more general problem? You get 
this
>problem
>whenever you are performing header compression...
>

Yes, that's true. HMIP just adds extra header bits. The only additional
complication I could see is if using HMIP would somehow make
convergence of compression after handover slower, or if it would 
make it difficult or impossible to do context transfer upon handover
(if that works). Neither are proven, but they are a concern.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 09:26:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04143
	for ; Fri, 16 Mar 2001 09:26:00 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21987;
	Fri, 16 Mar 2001 06:24:42 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00372;
	Fri, 16 Mar 2001 06:24:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GENDIm010282
	for ; Fri, 16 Mar 2001 06:23:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GENDsF010281
	for mobile-ip-dist; Fri, 16 Mar 2001 06:23:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEMuIm010271
	for ; Fri, 16 Mar 2001 06:22:57 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23300
	for ; Fri, 16 Mar 2001 06:22:58 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03814
	for ; Fri, 16 Mar 2001 06:22:53 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id PAA21143
	for ; Fri, 16 Mar 2001 15:22:51 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id PAA03774
	for ; Fri, 16 Mar 2001 15:21:46 +0100 (MET)
Message-ID: <3AB2217A.2282D0FB@inrialpes.fr>
Date: Fri, 16 Mar 2001 15:21:46 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Simplified Hierarchical MIPv6 (was...)
References: <200103161400.GAA14919@heliopolis.Eng.Sun.COM>
Content-Type: multipart/alternative;
 boundary="------------5851B992B9D1064AE45C76D6"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------5851B992B9D1064AE45C76D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello,

James Kempf wrote:

> Claude,
>
> >So this is not a problem of HMIPv6...this is a more general problem? You get
> this
> >problem
> >whenever you are performing header compression...
> >
>
> Yes, that's true. HMIP just adds extra header bits. The only additional
> complication I could see is if using HMIP would somehow make
> convergence of compression after handover slower, or if it would
> make it difficult or impossible to do context transfer upon handover
> (if that works). Neither are proven, but they are a concern.
>

I don't understand why HMIP would make handover slower and/or context
transfer more difficult than MIP....
I really do not understand your concern...do you have something specific in
mind?

thanks,

Claude.


--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------5851B992B9D1064AE45C76D6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello,

James Kempf wrote:

Claude,

>So this is not a problem of HMIPv6...this is a more general problem?
You get

this

>problem

>whenever you are performing header compression...

>

Yes, that's true. HMIP just adds extra header bits. The only additional

complication I could see is if using HMIP would somehow make

convergence of compression after handover slower, or if it would

make it difficult or impossible to do context transfer upon handover

(if that works). Neither are proven, but they are a concern.

 

I don't understand why HMIP would make handover slower and/or context

transfer more difficult than MIP....

I really do not understand your concern...do you have something specific
in mind?

thanks,

Claude.

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------5851B992B9D1064AE45C76D6--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 09:44:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04379
	for ; Fri, 16 Mar 2001 09:44:24 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10374;
	Fri, 16 Mar 2001 06:41:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24171;
	Fri, 16 Mar 2001 06:41:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEb1Im010332
	for ; Fri, 16 Mar 2001 06:37:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GEb1nS010331
	for mobile-ip-dist; Fri, 16 Mar 2001 06:37:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEalIm010324
	for ; Fri, 16 Mar 2001 06:36:52 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23729
	for ; Fri, 16 Mar 2001 06:36:48 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04731
	for ; Fri, 16 Mar 2001 06:36:47 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 16 Mar 2001 08:05:51 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 08:05:48 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA836@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Fri, 16 Mar 2001 08:05:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE22.324BE690"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE22.324BE690
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks Claude,
 
I'll take a look. I am hoping others will follow suit with more candidates
as well. This location privacy thing is one of the last "what's missings". I
have to say I have found it very uncomfortable going forward on solutions to
other aspects of the problem with this issue dangling.

-----Original Message-----
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, March 16, 2001 3:48 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] -HMIPv6 draft + Privacy draft-


Hello, 

We actually have a  (preliminary) draft that tries to tackle the problem of
route optimal location privacy in MIPv6. 
The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from
my web site :
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-p
rivacy-00.txt
  or from the IETF 
ID repository... 


Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and 
highlights some of its advantages (see section 6.5 or 6.6 for example). This
new version can be retrieved at: 
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03
.txt
  


comments welcome.... 


regards, 


Claude. 


Glenn Morrow wrote: 


  

Yes - there is no accepted or even tabled proposal yet for route optimal
location privacy. I believe it is a requirement even MIP should strive for
as we move forward. 
  
  


        => True. But the same goes for any IP adderss in the hierarchical 
        IPv6 world. Right ? 


        Hesham

-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


------_=_NextPart_001_01C0AE22.324BE690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Thanks=20
Claude,


 


I'll=20
take a look. I am hoping others will follow suit with more candidates =
as well.=20
This location privacy thing is one of the last "what's missings". I =
have to say=20
I have found it very uncomfortable going forward on solutions to other =
aspects=20
of the problem with this issue dangling.



  
-----Original Message-----
From: Claude =
Castelluccia=20
  [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, =
March 16,=20
  2001 3:48 AM
To: =
mobile-ip@sunroof.eng.sun.com
Subject:=20
  [mobile-ip] -HMIPv6 draft + Privacy draft-

Hello, =

  
We actually have a  (preliminary) draft that tries to tackle =
the=20
  problem of route optimal location privacy in MIPv6. 
The draft=20
  (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my =
web site=20
  : http://www.inrialpes.fr/planete/people/ccaste=
l/draft-castelluccia-mobileip-privacy-00.txt=20
  or from the IETF 
ID repository...=20
  
Note also that we have a new version of HMIPv6 (version 3) that =
clarifies=20
  some aspects of HMIPv6 and 
highlights some of its advantages (see =
section=20
  6.5 or 6.6 for example). This new version can be retrieved at: 
http://www.inrialpes.fr/planete/people/ccastel/draft-i=
etf-mobileip-hmipv6-03.txt=20

  
comments welcome....=20
  
regards,=20
  
Claude.=20
  
Glenn Morrow wrote:=20
  
 =20
    
Yes - there is no accepted or even tabled =
proposal yet for=20
    route optimal location privacy. I believe it is a requirement even =
MIP=20
    should strive for as we move forward. 
  
 =20
    
        =3D> True. But=20
    the same goes for any IP adderss in the hierarchical=20
    
        IPv6 =
world.=20
    Right ?=20
    
        Hesham
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planet=
e/
 =20



------_=_NextPart_001_01C0AE22.324BE690--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 10:03:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04638
	for ; Fri, 16 Mar 2001 10:03:20 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02314;
	Fri, 16 Mar 2001 07:01:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26394;
	Fri, 16 Mar 2001 07:01:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEvnIm010432
	for ; Fri, 16 Mar 2001 06:57:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GEvmIA010431
	for mobile-ip-dist; Fri, 16 Mar 2001 06:57:48 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GEvVIm010424
	for ; Fri, 16 Mar 2001 06:57:36 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25699
	for ; Fri, 16 Mar 2001 06:57:31 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05663
	for ; Fri, 16 Mar 2001 06:57:27 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 16 Mar 2001 08:23:48 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 08:26:59 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA88D@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Re: Comments on Regional Registration
Date: Fri, 16 Mar 2001 08:26:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE25.271BA500"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE25.271BA500
Content-Type: text/plain;
	charset="iso-8859-1"

Hesham,

You have some good points and I will try to explore or re-use some other
mechanisms which can hopefully resolve these points. I apologize that the
suggestion was targeted to just the RR concept. I should have included more
suggestions for HMIP as well such as the one I gave the other day on how to
achieve the arbitrary point. 

This is getting ridiculous. It seems that if I make a suggestion to either I
end up irritating the other - not exactly a hospitable environment to
contribute to either.

The requirement is to make BU authorization faster, more scalable and
eliminate the need to send more than one BU over the air.

Excuse me if I extended it into the RR assumptions alone. It seems obvious
to me on how to do the same thing with HMIP.

The last point I made was definitely out of place and thank you for pointing
that out. 

In the end I do not care what we call it. Perhaps we should come up with
another acronym just to reduce the my idea vs. your idea competition. 

These discussions stink of what I call PWS (Patent War Syndrome). If that is
the case then people will likely end up promoting something that isn't the
most optimal solution as the standard or there will be multiple optional
standards which exacerbate the solution space for future issues.

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se]
Sent: Thursday, March 15, 2001 3:03 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Re: Comments on Regional Registration


Hello Glenn,

Before I start commenting on your proposal, I think there are 
some questions that need to be answered. 
Why do we need a multilevel static hierarchy of mobility
aware routers ? This is a mystery to me. The argument 
of delays if the MAP is too far simply doesn't hold. 
If I have an 80ms delay over the air interface and the MAP is 
another 4 ms away, I think such delay is insignificant. 

The other question is, do we want to associate the implementation
of this protocol with an imaginary protocol that generates 
an SA between the MN and the domain and distributes the
key to all mobility aware routers ?
The idea of generating such keys between two nodes is great
and we have presented it in San Diego, but I don't think it 
should be a requirement for this to be used. 

Do we want to have a tree-based hierarchy full of single 
points of failure ?

I don't want any of the above, but I'd like to see what others
think.

As you said Light travels fast and I like to Keep it simple, 
so unless there are strong and well thought requirements 
for the multi-level hierarchy, I think it should be dropped. 

I hope you don't take this as a negative response to your 
proposal, but I like to do things for a reason. The reasons 
and requirements here are not stated. 

Regards,
Hesham

PS: The regional draft for V4, basically says that f the MN
has a colocated CoA , then it just registers with the 
GFA. Sounds familiar ! 
Just something to think about.



> -----Original Message-----
> From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> Sent:	Friday, 16 March 2001 1:59
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	RE: [mobile-ip] Re: Comments on Regional Registration
> 
> Hesham and Charlie, 
> 
> I'm not too worried about the security association issue with anycast. I
think anycast is extremely useful and is here to stay. It is part of IPv6 -
might as well take advantage of it. 
> 
> I believe the SA establishment and scaling problem for MIP, in general,
has scaling and speed issues. It would actually probably be more productive
for us to focus on that issue than heirarchical models. It seems people have
focused so far on "database in the sky" solutions with AAA protocols to
this.
> 
> I have an alternate idea which I would like to bring up again. 
> 
> Why don't we use a hop by hop option to alert mobile-aware routers to the
binding updates. For instance, a mobile could send a binding update to a CN
and it would be intercepted by the 1st hop router in the visited domain. 
> 
> If the visited domain wanted to support hierarchical, other routers along
the natural routing path to the CN would be configured to care as well at
whatever topological tier the provider deemed necessary. These hirearchical
routers could install a per-host route in the binding cache to achieve route
both optimized hierarchical signaling and traffic flow.
> 
> These heirarchical routers could rebuild the binding update with a tiered
address and use the domains keys i.e. the keys that routers already use to
trust each other for the AH. Routers in the visited and in other domains
that are not configured to care about mobility binding simply forward the
packet towards the CN's address I.e. they are not configured to "recognize"
the particular function. 
> 
> Only when the binding update exits a domain into another domain i.e. the
keys change, the border router again intercepts and recomputes the binding
update using the keys appropriate for the particular border. 
> 
> This process is continued until the binding update arrives at either the
CN itself or a last hop router in the event they want route optimized
location privacy. If the BU is sent to the CN, it is assumed that that CN
has some security association with the subnet where it resides and it trusts
the keys of that subnet. Perhaps the CN can simply trust the subnet routers
without an SA - just as it currently does for ICMP singaling.> 
> 
> The advantage of this method are: 
> 
> - It re-uses the existing binding update i.e. we don't burn more air
bandwidth. We leverage the existing binding updates.
> 
> - It provides the most route optimal form of hierarchical mobility. 
> - It re-uses the existing security associations that SHOULD exist between
domains, internal routers and hosts.>  
> - If one heirarchical router dies other communications and hierarchical
bindings for other communications that mobile is engaged in continue
un-affected. 
> 
> - It does not interfere with the natural routing policy of the domains. 
> - It seems to match up well and re-uses the same mechanisms used to
monitor bandwidth and signal CoS. 
> 
> The disadvantages that I see is: 
> 
> - It makes some of the intermediary routers do extra signaling; however if
you really understand what will have to happen for real time communications
such as DSCP schema's changing between administrative domains, you will see
that this work will be occuring anyway. Why send more than one packet to get
the job done? 
> 
> - I agree it is not needed for best effort unless the excuse it to solve
the security association problems. 
> 
> Another approach might be to send binding updates to the visited subnet
anycast addresses and chain the message up the network i.e. MN subnet to
site, site to site, site to CN subnet and then to CN.
> 
> Is this clear? It seems to me that doing something like this would resolve
many issues. 
> 
> One thing I really can't understand with both of your proposed
hierarchical solutions is why you want to send more than one binding update.
This burns the air resources. The whole idea for doing heirarchical was to
reduce signaling latency for cellular. These networks are the only networks
that I am aware of that someone might be moving so fast as to warrant a
heirarchical scheme. The solutions seem to conflict with requirements. 
> 
> The last thing I would like to say that it seems we are spending way to
much time on something that provides so little gain. Light travels very
fast.
> 
> Thanks, 
> 
> Glenn 
> 
> 
> 
> 
> Glenn 
> 
> -----Original Message----- 
> From: Charlie Perkins [ ] 
> Sent: Wednesday, March 14, 2001 5:38 PM 
> To: mobile-ip@sunroof.eng.sun.com 
> Subject: Re: [mobile-ip] Re: Comments on Regional Registration 
> 
> 
> Hello Hesham, 
> 
> We want to get the routing part figured out, and I believe 
> we have a pretty good handle on it. 
> 
> Setting up security will allow a mobile node to provide 
> authentication data that can be checked by one of the 
> anycast group members.  I know several ways to do that. 
> It will be more productive to start on that task once two 
> other things are out of the way: 
> - Fixing the authentication mechanism for base Mobile IPv6 
> - Getting the routing part figured out. 
> 
> If you wish to disqualify all anycast-based solutions because 
> there are no standards for establishing security between a 
> node and the members of an anycast group, then I would 
> just prefer to say that we believe the problem is wholly 
> solvable for the particular anycast group we have designed. 
> We don't intend to get in the business of solving it for the 
> general case. 
> 
> Regards, 
> Charlie P. 
> 
> 
> 
> "Hesham Soliman (ERA)" wrote: 
> 
> >         Hello Charlie, 
> > 
> > > 
> > > > GM> I agree, I support anycast too. To vilify a solution which
employs 
> > > > it as magic was wrong and I apologize. 
> > > 
> > > No need for apology, but I wanted to point out that this particular 
> > > use of anycast is easy to implement, assuming that one's IPv6 
> > > implementation supports anycast at all. 
> > > 
> >         => I'm a bit confused by this statement. How can it be easy 
> >         to implement a BU to an anycast address ? 
> >         BUs have to be secured with AH, so how can you setup this 
> >         security association when there are no standards defined 
> >         to do so ? 
> > 
> >         Regards, 
> >         Hesham 
> 

------_=_NextPart_001_01C0AE25.271BA500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Re: Comments on Regional Registration




Hesham,




You have some good points and I will try to explore =
or re-use some other mechanisms which can hopefully resolve these =
points. I apologize that the suggestion was targeted to just the RR =
concept. I should have included more suggestions for HMIP as well such =
as the one I gave the other day on how to achieve the arbitrary point. =




This is getting ridiculous. It seems that if I make a =
suggestion to either I end up irritating the other - not exactly a =
hospitable environment to contribute to either.



The requirement is to make BU authorization faster, =
more scalable and eliminate the need to send more than one BU over the =
air.



Excuse me if I extended it into the RR assumptions =
alone. It seems obvious to me on how to do the same thing with =
HMIP.




The last point I made was definitely out of place and =
thank you for pointing that out. 




In the end I do not care what we call it. Perhaps we =
should come up with another acronym just to reduce the my idea vs. your =
idea competition. 



These discussions stink of what I call PWS (Patent =
War Syndrome). If that is the case then people will likely end up =
promoting something that isn't the most optimal solution as the =
standard or there will be multiple optional standards which exacerbate =
the solution space for future issues.



Glenn




-----Original Message-----

From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era=
.ericsson.se]

Sent: Thursday, March 15, 2001 3:03 PM

To: 'mobile-ip@sunroof.eng.sun.com'

Subject: RE: [mobile-ip] Re: Comments on Regional =
Registration






Hello Glenn,




Before I start commenting on your proposal, I think =
there are 

some questions that need to be answered. 

Why do we need a multilevel static hierarchy of =
mobility

aware routers ? This is a mystery to me. The =
argument 

of delays if the MAP is too far simply doesn't hold. =


If I have an 80ms delay over the air interface and =
the MAP is 

another 4 ms away, I think such delay is =
insignificant. 




The other question is, do we want to associate the =
implementation

of this protocol with an imaginary protocol that =
generates 

an SA between the MN and the domain and distributes =
the

key to all mobility aware routers ?

The idea of generating such keys between two nodes =
is great

and we have presented it in San Diego, but I don't =
think it 

should be a requirement for this to be used. 




Do we want to have a tree-based hierarchy full of =
single 

points of failure ?




I don't want any of the above, but I'd like to see =
what others

think.




As you said Light travels fast and I like to Keep it =
simple, 

so unless there are strong and well thought =
requirements 

for the multi-level hierarchy, I think it should be =
dropped. 




I hope you don't take this as a negative response to =
your 

proposal, but I like to do things for a reason. The =
reasons 

and requirements here are not stated. 




Regards,

Hesham




PS: The regional draft for V4, basically says that f =
the MN

has a colocated CoA , then it just registers with =
the 

GFA. Sounds familiar ! 

Just something to think about.








> -----Original Message-----

> From: Glenn Morrow =
[SMTP:gmorrow@nortelnetworks.com]

> Sent: Friday, 16 March 2001 1:59

> To:   =
mobile-ip@sunroof.eng.sun.com

> Subject:      RE: =
[mobile-ip] Re: Comments on Regional Registration

> 

> Hesham and Charlie, 

> 

> I'm not too worried about the security =
association issue with anycast. I think anycast is extremely useful and =
is here to stay. It is part of IPv6 - might as well take advantage of =
it. 



> 

> I believe the SA establishment and scaling =
problem for MIP, in general, has scaling and speed issues. It would =
actually probably be more productive for us to focus on that issue than =
heirarchical models. It seems people have focused so far on =
"database in the sky" solutions with AAA protocols to =
this.



> 

> I have an alternate idea which I would like to =
bring up again. 

> 

> Why don't we use a hop by hop option to alert =
mobile-aware routers to the binding updates. For instance, a mobile =
could send a binding update to a CN and it would be intercepted by the =
1st hop router in the visited domain. 



> 

> If the visited domain wanted to support =
hierarchical, other routers along the natural routing path to the CN =
would be configured to care as well at whatever topological tier the =
provider deemed necessary. These hirearchical routers could install a =
per-host route in the binding cache to achieve route both optimized =
hierarchical signaling and traffic flow.



> 

> These heirarchical routers could rebuild the =
binding update with a tiered address and use the domains keys i.e. the =
keys that routers already use to trust each other for the AH. Routers =
in the visited and in other domains that are not configured to care =
about mobility binding simply forward the packet towards the CN's =
address I.e. they are not configured to "recognize" the =
particular function. 



> 

> Only when the binding update exits a domain =
into another domain i.e. the keys change, the border router again =
intercepts and recomputes the binding update using the keys appropriate =
for the particular border. 



> 

> This process is continued until the binding =
update arrives at either the CN itself or a last hop router in the =
event they want route optimized location privacy. If the BU is sent to =
the CN, it is assumed that that CN has some security association with =
the subnet where it resides and it trusts the keys of that subnet. =
Perhaps the CN can simply trust the subnet routers without an SA - just =
as it currently does for ICMP singaling.> 



> 

> The advantage of this method are: 

> 

> - It re-uses the existing binding update i.e. =
we don't burn more air bandwidth. We leverage the existing binding =
updates.



> 

> - It provides the most route optimal form of =
hierarchical mobility. 

> - It re-uses the existing security associations =
that SHOULD exist between domains, internal routers and =
hosts.>  

> - If one heirarchical router dies other =
communications and hierarchical bindings for other communications that =
mobile is engaged in continue un-affected. 



> 

> - It does not interfere with the natural =
routing policy of the domains. 

> - It seems to match up well and re-uses the =
same mechanisms used to monitor bandwidth and signal CoS. 

> 

> The disadvantages that I see is: 

> 

> - It makes some of the intermediary routers do =
extra signaling; however if you really understand what will have to =
happen for real time communications such as DSCP schema's changing =
between administrative domains, you will see that this work will be =
occuring anyway. Why send more than one packet to get the job done? =




> 

> - I agree it is not needed for best effort =
unless the excuse it to solve the security association problems. =


> 

> Another approach might be to send binding =
updates to the visited subnet anycast addresses and chain the message =
up the network i.e. MN subnet to site, site to site, site to CN subnet =
and then to CN.



> 

> Is this clear? It seems to me that doing =
something like this would resolve many issues. 

> 

> One thing I really can't understand with both =
of your proposed hierarchical solutions is why you want to send more =
than one binding update. This burns the air resources. The whole idea =
for doing heirarchical was to reduce signaling latency for cellular. =
These networks are the only networks that I am aware of that someone =
might be moving so fast as to warrant a heirarchical scheme. The =
solutions seem to conflict with requirements. 



> 

> The last thing I would like to say that it =
seems we are spending way to much time on something that provides so =
little gain. Light travels very fast.



> 

> Thanks, 

> 

> Glenn 

> 

> 

> 

> 

> Glenn 

> 

> -----Original Message----- 

> From: Charlie Perkins [ <mailto:charliep@iprg.nokia.com>] 

> Sent: Wednesday, March 14, 2001 5:38 PM 

> To: mobile-ip@sunroof.eng.sun.com 

> Subject: Re: [mobile-ip] Re: Comments on =
Regional Registration 

> 

> 

> Hello Hesham, 

> 

> We want to get the routing part figured out, =
and I believe 

> we have a pretty good handle on it. 

> 

> Setting up security will allow a mobile node to =
provide 

> authentication data that can be checked by one =
of the 

> anycast group members.  I know several =
ways to do that. 

> It will be more productive to start on that =
task once two 

> other things are out of the way: 

> - Fixing the authentication mechanism for base =
Mobile IPv6 

> - Getting the routing part figured out. 

> 

> If you wish to disqualify all anycast-based =
solutions because 

> there are no standards for establishing =
security between a 

> node and the members of an anycast group, then =
I would 

> just prefer to say that we believe the problem =
is wholly 

> solvable for the particular anycast group we =
have designed. 

> We don't intend to get in the business of =
solving it for the 

> general case. 

> 

> Regards, 

> Charlie P. 

> 

> 

> 

> "Hesham Soliman (ERA)" wrote: 

> 

> =
>         Hello Charlie, =


> > 

> > > 

> > > > GM> I agree, I support =
anycast too. To vilify a solution which employs 

> > > > it as magic was wrong and I =
apologize. 

> > > 

> > > No need for apology, but I wanted to =
point out that this particular 

> > > use of anycast is easy to implement, =
assuming that one's IPv6 

> > > implementation supports anycast at =
all. 

> > > 

> =
>         =3D> I'm a bit =
confused by this statement. How can it be easy 

> =
>         to implement a BU =
to an anycast address ? 

> =
>         BUs have to be =
secured with AH, so how can you setup this 

> =
>         security =
association when there are no standards defined 

> =
>         to do so ? 

> > 

> =
>         Regards, 

> =
>         Hesham 

> 





------_=_NextPart_001_01C0AE25.271BA500--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 10:53:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05447
	for ; Fri, 16 Mar 2001 10:53:10 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28531;
	Fri, 16 Mar 2001 07:51:50 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15535;
	Fri, 16 Mar 2001 07:51:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GFoWIm010499
	for ; Fri, 16 Mar 2001 07:50:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GFoWEw010498
	for mobile-ip-dist; Fri, 16 Mar 2001 07:50:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GFoLIm010491
	for ; Fri, 16 Mar 2001 07:50:21 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15348
	for ; Fri, 16 Mar 2001 07:50:22 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22950
	for ; Fri, 16 Mar 2001 07:50:22 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25477
	for ; Fri, 16 Mar 2001 07:50:21 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI31856;
	Fri, 16 Mar 2001 07:50:21 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA03575; Fri, 16 Mar 2001 07:50:20 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.13884.473980.625507@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 07:50:20 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43018BA836@crchy271.us.nortel.com>
References: <85AA7486A2C1D411BCA20000F8073E43018BA836@crchy271.us.nortel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Glenn Morrow writes:
 > Thanks Claude,
 >  
 > I'll take a look. I am hoping others will follow suit with more candidates
 > as well. This location privacy thing is one of the last "what's missings". I
 > have to say I have found it very uncomfortable going forward on solutions to
 > other aspects of the problem with this issue dangling.

   Hmm. I suspect that IP location privacy is not just a MIP
   issue. It certainly comes up in VoIP-land regularly when
   wanting to provide "caller-id blocking" where you need to
   provide complete anonymity for a caller, the canonical
   example being the battered wife not wanting hubby to use
   the incoming RTP packets to guess where she is. For SIP,
   the general consensus was to just build a SIP anonymizer
   out of a back to back UA, but that is hardly a general 
   purpose mechanism.

   I believe that there have been BOF's in the past about
   location (SPACIAL, I think), though I didn't attend. The
   topic does, however, keep coming up. I really wonder whether:

   a) this really belongs in MIP WG on the one hand
   b) whether MIP may provide a good foundation to
      solve the general problem on the other hand

		Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 11:13:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05958
	for ; Fri, 16 Mar 2001 11:13:00 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20056;
	Fri, 16 Mar 2001 08:11:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07358;
	Fri, 16 Mar 2001 08:10:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GG9GIm010541
	for ; Fri, 16 Mar 2001 08:09:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GG9Fc4010540
	for mobile-ip-dist; Fri, 16 Mar 2001 08:09:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GG97Im010533
	for ; Fri, 16 Mar 2001 08:09:07 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06962
	for ; Fri, 16 Mar 2001 08:09:07 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08790
	for ; Fri, 16 Mar 2001 08:09:06 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 16 Mar 2001 08:57:08 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 09:01:58 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA920@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 +0100
Date: Fri, 16 Mar 2001 09:01:56 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE2A.0B241F30"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE2A.0B241F30
Content-Type: text/plain;
	charset="iso-8859-1"

Hesham,

Some more excellent points. I am actually quite positive that tracert would
have to change in order to achieve the functionality. I am very open to
other suggestions.

Thanks,

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se]
Sent: Thursday, March 15, 2001 6:43 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 +0100



	Yes - there is no accepted or even tabled proposal yet for route
optimal location privacy. I believe it is a requirement even MIP should
strive for as we move forward.

	=> I agree. The problem is that your IP address is the one piece of 
	information needed to route packets to you. So if you want to 
	hide your true location by telling the CN to send packets to another
	IP address, then you need to compromise between location
	privacy and optimal routing. 

	One extreme would be to always use your Home Address, however
	the optimisation of the route will depend on how far you are from
	the HA. However you could argue that even if you do not 
	send BUs to the CN to achieve location privacy, the 
	CN can still know your real address from the source address on your 
	packets. 
	Even if you hide that (like in the case of reverse tunnelling from
the 
	FA in MIPv4) a CN who wants to find your location can do a 
	trace route and find you ! Unless you disable the application in
	your HA of course. 

	So, I agree it's a hard problem.

	  Hesham


------_=_NextPart_001_01C0AE2A.0B241F30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 +0100




Hesham,




Some more excellent points. I am actually quite =
positive that tracert would have to change in order to achieve the =
functionality. I am very open to other suggestions.



Thanks,




Glenn




-----Original Message-----

From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era=
.ericsson.se]

Sent: Thursday, March 15, 2001 6:43 PM

To: 'mobile-ip@sunroof.eng.sun.com'

Subject: [mobile-ip] Date: Fri, 16 Mar 2001 01:42:26 =
+0100








        Yes - =
there is no accepted or even tabled proposal yet for route optimal =
location privacy. I believe it is a requirement even MIP should strive =
for as we move forward.



        =3D> I =
agree. The problem is that your IP address is the one piece of 

        information needed to route packets to you. So if you want to =


        hide your =
true location by telling the CN to send packets to another

        IP =
address, then you need to compromise between location

        privacy =
and optimal routing. 




        One =
extreme would be to always use your Home Address, however

        the =
optimisation of the route will depend on how far you are from

        the HA. =
However you could argue that even if you do not 

        send BUs =
to the CN to achieve location privacy, the 

        CN can =
still know your real address from the source address on your 

        packets. =


        Even if =
you hide that (like in the case of reverse tunnelling from the 

        FA in =
MIPv4) a CN who wants to find your location can do a 

        trace =
route and find you ! Unless you disable the application in

        your HA =
of course. 




        So, I =
agree it's a hard problem.




          =
Hesham





------_=_NextPart_001_01C0AE2A.0B241F30--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 11:38:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06569
	for ; Fri, 16 Mar 2001 11:38:13 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17031;
	Fri, 16 Mar 2001 08:36:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11824;
	Fri, 16 Mar 2001 08:36:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGZKIm010701
	for ; Fri, 16 Mar 2001 08:35:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGZKd4010700
	for mobile-ip-dist; Fri, 16 Mar 2001 08:35:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGZ8Im010693
	for ; Fri, 16 Mar 2001 08:35:08 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10690
	for ; Fri, 16 Mar 2001 08:35:08 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01712
	for ; Fri, 16 Mar 2001 08:34:59 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id RAA25301
	for ; Fri, 16 Mar 2001 17:34:58 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id RAA04598
	for ; Fri, 16 Mar 2001 17:33:54 +0100 (MET)
Message-ID: <3AB24072.AFBBCCCD@inrialpes.fr>
Date: Fri, 16 Mar 2001 17:33:54 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] -HMIPv6 draft + Privacy draft-
References: <85AA7486A2C1D411BCA20000F8073E43018BA9C2@crchy271.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------82C348D6A0C4E52153271F8A"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------82C348D6A0C4E52153271F8A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Glenn Morrow wrote:

> Claude,In reference to the privacy draft , I do not see the use of it
> as you do not try to "solve the problem of privacy of a mobile node
> from it's correspondent nodes". You want to hide some information from
> other nodes such as location and true identity but by not handling the
> basic issue with the CN you have done nothing. For instance, any node
> in the world can ping the MN and obtain it's COA because it would then
> be a CN.

If you want to hide your location to your CN, you can either:
-use HMIP (in this case you only reveal your RCoA not your CoA)
- use MIP without route optimization...
-use Mixes, onion routing...
-others?

Anyways you are right, we are not solving this problem in this draft, we
are solving the following one:

-A MN trusts its CN (because they are both belonging to the same
company)
and is willing to reveal its CoA, however it does not want anybody else
(for example its
competitor) in the network to know where it is currently located....

This is not possible with MIPv6, this is what our draft tries to
solve...


> Why would someone bother worrying about eavesdropping and sniffing
> when one can simply ping the node after a DNS or other lookup?

as I said we make the assumption that a MN only sends BU to CNs it
trusts ....


> It seems to me that the recent anonymity extensions to stateless
> autoconfiguration will acheive the same functionality as the TMI
> concept.

not really... with the recent anonymity extensions for stateless auto.
you still reveal your network prefix, you just
use an interface identifier that is random...in our case the TMI (128
bit) is completly random....

> More later on the new HMIP proposal.

this is not a new proposal....just a new version of the old proposal...

> Thanks for the effort, though.Glenn

thanks for your comments...

>
>
>      -----Original Message-----
>      From: Morrow, Glenn [RICH2:C330:EXCH]
>      Sent: Friday, March 16, 2001 8:06 AM
>      To: mobile-ip@sunroof.eng.sun.com
>      Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
>      Thanks Claude,I'll take a look. I am hoping others will
>      follow suit with more candidates as well. This location
>      privacy thing is one of the last "what's missings". I have
>      to say I have found it very uncomfortable going forward on
>      solutions to other aspects of the problem with this issue
>      dangling.
>
>           -----Original Message-----
>           From: Claude Castelluccia
>           [mailto:claude.castelluccia@inrialpes.fr]
>           Sent: Friday, March 16, 2001 3:48 AM
>           To: mobile-ip@sunroof.eng.sun.com
>           Subject: [mobile-ip] -HMIPv6 draft + Privacy
>           draft-
>           Hello,
>
>           We actually have a  (preliminary) draft that tries
>           to tackle the problem of route optimal location
>           privacy in MIPv6.
>           The draft
>           (draft-castelluccia-mobileip-privacy-00.txt) can
>           be retrieved from my web site :
>           http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt
>           or from the IETF
>           ID repository...
>
>           Note also that we have a new version of HMIPv6
>           (version 3) that clarifies some aspects of HMIPv6
>           and
>           highlights some of its advantages (see section 6.5
>           or 6.6 for example). This new version can be
>           retrieved at:
>           http://www.in
>           ialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt
>
>           comments welcome....
>
>           regards,
>
>           Claude.
>
>           Glenn Morrow wrote:
>
>          >
>          >
>          > Yes - there is no accepted or even tabled
>          > proposal yet for route optimal location privacy.
>          > I believe it is a requirement even MIP should
>          > strive for as we move forward.
>          >
>          >
>          >
>          >         => True. But the same goes for any IP
>          > adderss in the hierarchical
>          >         IPv6 world. Right ?
>          >
>          >         Hesham
>
>           --
>
>           ----------------------------------------
>           Claude CASTELLUCCIA, INRIA Rhone-Alpes
>           ph:  +33 4.76.61.52.15 (fax: 52.52)
>           http://www.inrialpes.fr/planete/
>
>
>
--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------82C348D6A0C4E52153271F8A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Glenn Morrow wrote:

Claude,In
reference to the privacy draft , I do not see the use of it as you do not
try to "solve the problem of privacy of a mobile node from it's correspondent
nodes". You want to hide some
information from other nodes such as location and true identity but by
not handling the basic issue with the CN you have done nothing. For instance,
any node in the world can ping the MN and obtain it's COA because it would
then be a CN.

If you want to hide your location to your CN, you can either:

-use HMIP (in this case you only reveal your RCoA not your CoA)

- use MIP without route optimization...

-use Mixes, onion routing...

-others?

Anyways you are right, we are not solving this problem in this draft,
we are solving the following one:

-A MN trusts its CN (because they are both belonging to the same company)

and is willing to reveal its CoA, however it does not want anybody
else (for example its

competitor) in the network to know where it is currently located....

This is not possible with MIPv6, this is what our draft tries to solve...

 



Why
would someone bother worrying about eavesdropping and sniffing when one
can simply ping the node after a DNS or other lookup?

as I said we make the assumption that a MN only sends BU to CNs it
trusts ....

 

It
seems to me that the recent anonymity extensions to stateless autoconfiguration
will acheive the same functionality as the TMI concept.

not really... with the recent anonymity extensions for stateless auto.
you still reveal your network prefix, you just

use an interface identifier that is random...in our case the TMI (128
bit) is completly random....

More
later on the new HMIP proposal.

this is not a new proposal....just a new version of the old proposal...

Thanks
for the effort, though.Glenn

thanks for your comments...

 



-----Original
Message-----

From: Morrow, Glenn [RICH2:C330:EXCH]

Sent: Friday, March 16, 2001
8:06 AM

To: mobile-ip@sunroof.eng.sun.com

Subject: RE: [mobile-ip] -HMIPv6
draft + Privacy draft-

Thanks
Claude,I'll
take a look. I am hoping others will follow suit with more candidates as
well. This location privacy thing is one of the last "what's missings".
I have to say I have found it very uncomfortable going forward on solutions
to other aspects of the problem with this issue dangling.



-----Original
Message-----

From: Claude Castelluccia
[mailto:claude.castelluccia@inrialpes.fr]

Sent: Friday, March 16, 2001
3:48 AM

To: mobile-ip@sunroof.eng.sun.com

Subject: [mobile-ip] -HMIPv6
draft + Privacy draft-

Hello,

We actually have a  (preliminary) draft that tries to tackle the
problem of route optimal location privacy in MIPv6.

The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved
from my web site : http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt
or from the IETF

ID repository...

Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and

highlights some of its advantages (see section 6.5 or 6.6 for example).
This new version can be retrieved at:

http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt

comments welcome....

regards,

Claude.

Glenn Morrow wrote:

 

Yes - there is no accepted or even tabled proposal yet
for route optimal location privacy. I believe it is a requirement even
MIP should strive for as we move forward.

 

 

        => True. But
the same goes for any IP adderss in the hierarchical

        IPv6 world.
Right ?

        Hesham



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 







-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------82C348D6A0C4E52153271F8A--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 11:51:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06944
	for ; Fri, 16 Mar 2001 11:51:39 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26998;
	Fri, 16 Mar 2001 08:47:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07172;
	Fri, 16 Mar 2001 08:14:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGCZIm010570
	for ; Fri, 16 Mar 2001 08:12:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGCYZv010568
	for mobile-ip-dist; Fri, 16 Mar 2001 08:12:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGCPIm010561
	for ; Fri, 16 Mar 2001 08:12:26 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14684
	for ; Fri, 16 Mar 2001 08:12:26 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11882
	for ; Fri, 16 Mar 2001 08:12:19 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 16 Mar 2001 09:54:21 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 09:44:13 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BA9C2@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Fri, 16 Mar 2001 09:44:05 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE2F.EE8874B0"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE2F.EE8874B0
Content-Type: text/plain;
	charset="iso-8859-1"

Claude,
 
In reference to the privacy draft , I do not see the use of it as you do not
try to "solve the problem of privacy of a mobile node from it's
correspondent nodes". 
 
You want to hide some information from other nodes such as location and true
identity but by not handling the basic issue with the CN you have done
nothing. For instance, any node in the world can ping the MN and obtain it's
COA because it would then be a CN. 
 
Why would someone bother worrying about eavesdropping and sniffing when one
can simply ping the node after a DNS or other lookup?
 
It seems to me that the recent anonymity extensions to stateless
autoconfiguration will acheive the same functionality as the TMI concept.
 
More later on the new HMIP proposal. This will take some time.
 
Thanks for the effort, though.
 
 
Glenn
 
 

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Friday, March 16, 2001 8:06 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-


Thanks Claude,
 
I'll take a look. I am hoping others will follow suit with more candidates
as well. This location privacy thing is one of the last "what's missings". I
have to say I have found it very uncomfortable going forward on solutions to
other aspects of the problem with this issue dangling.

-----Original Message-----
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, March 16, 2001 3:48 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] -HMIPv6 draft + Privacy draft-


Hello, 

We actually have a  (preliminary) draft that tries to tackle the problem of
route optimal location privacy in MIPv6. 
The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from
my web site :
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-p
rivacy-00.txt
  or from the IETF 
ID repository... 


Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and 
highlights some of its advantages (see section 6.5 or 6.6 for example). This
new version can be retrieved at: 
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03
.txt
  


comments welcome.... 


regards, 


Claude. 


Glenn Morrow wrote: 


  

Yes - there is no accepted or even tabled proposal yet for route optimal
location privacy. I believe it is a requirement even MIP should strive for
as we move forward. 
  
  


        => True. But the same goes for any IP adderss in the hierarchical 
        IPv6 world. Right ? 


        Hesham

-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


------_=_NextPart_001_01C0AE2F.EE8874B0
Content-Type: text/html;
	charset="iso-8859-1"









Claude,


 


In 
reference to the privacy draft , I do not see the use of it as you do not try to 
"solve the problem of privacy of a mobile node from it's correspondent nodes". 



 


You 
want to hide some information from other nodes such as location and true 
identity but by not handling the basic issue with the CN you have done nothing. 
For instance, any node in the world can ping the MN and obtain it's COA because 
it would then be a CN. 


 


Why 
would someone bother worrying about eavesdropping and sniffing when one can 
simply ping the node after a DNS or other lookup?


 


It seems to me that the recent anonymity 
extensions to stateless autoconfiguration will acheive the same functionality as 
the TMI concept.


 


More 
later on the new HMIP proposal. This will take some time.


 


Thanks for the 
effort, though.


 


 


Glenn


 


 



  
-----Original Message-----
From: Morrow, Glenn 
  [RICH2:C330:EXCH] 
Sent: Friday, March 16, 2001 8:06 
  AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: 
  [mobile-ip] -HMIPv6 draft + Privacy draft-


  
Thanks Claude,

  
 

  
I'll 
  take a look. I am hoping others will follow suit with more candidates as well. 
  This location privacy thing is one of the last "what's missings". I have to 
  say I have found it very uncomfortable going forward on solutions to other 
  aspects of the problem with this issue dangling.

  

    
-----Original Message-----
From: Claude Castelluccia 
    [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, March 16, 
    2001 3:48 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: 
    [mobile-ip] -HMIPv6 draft + Privacy draft-

Hello, 
    
We actually have a  (preliminary) draft that tries to tackle the 
    problem of route optimal location privacy in MIPv6. 
The draft 
    (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my web 
    site : http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt 
    or from the IETF 
ID repository... 
    
Note also that we have a new version of HMIPv6 (version 3) that clarifies 
    some aspects of HMIPv6 and 
highlights some of its advantages (see 
    section 6.5 or 6.6 for example). This new version can be retrieved at: 
    
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt 

    
comments welcome.... 
    
regards, 
    
Claude. 
    
Glenn Morrow wrote: 
    
  
      
Yes - there is no accepted or even tabled proposal yet 
      for route optimal location privacy. I believe it is a requirement even MIP 
      should strive for as we move forward. 
  
  
      
        => True. 
      But the same goes for any IP adderss in the hierarchical 
      
        IPv6 world. 
      Right ? 
      
        Hesham
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  
  


------_=_NextPart_001_01C0AE2F.EE8874B0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 11:55:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07064
	for ; Fri, 16 Mar 2001 11:55:32 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26347;
	Fri, 16 Mar 2001 08:45:56 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12497;
	Fri, 16 Mar 2001 08:45:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGiCIm010788
	for ; Fri, 16 Mar 2001 08:44:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGiCSE010787
	for mobile-ip-dist; Fri, 16 Mar 2001 08:44:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGi3Im010780
	for ; Fri, 16 Mar 2001 08:44:03 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12231
	for ; Fri, 16 Mar 2001 08:44:04 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA17014
	for ; Fri, 16 Mar 2001 08:44:03 -0800 (PST)
Message-Id: <200103161644.IAA17014@heliopolis.Eng.Sun.COM>
Date: Fri, 16 Mar 2001 08:44:03 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] Hierarchical MIPv6 Requirements
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: iEVJp8WKPqi/aK99I+nV+A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham & Jari,

I don't want to get involved in taking sides on either of your proposals
because I see points with which I agree and disagree in both. 
While I don't want to cast any aspersions, I'm very curious to know
how one proposal was selected as a working group draft without an
agreed upon set of requirements. Much of the disagreement I've seen
in the mailing list discussion seems to be founded on some fundamental
disagreements about what the requirements should be. Given the lack of an agreed 
upon set of requirements for hierarchical MIPv6,  I think it is going to be 
difficult to resolve the differences.

In a previous email, I expressed my reservations about tunnelling 
over the radio link, and the requirement for efficient use of the
radio link.

In this email, I'd like to bring up an additional requirement. There
has been some discussion about whether or not arbitrary levels of
hierarchy are of value. We recently did a study of using HMIP for
a next generation IP based radio access network, and one of the 
issues was supporting arbitrary levels of hierarchy with minimal (ideally
no) mobile involvement. It seemed like it could be done with extended
mode, but there were other problems with extended mode that made
it less attractive. I have not looked at the most recent draft yet,
perhaps those points have been addressed.

One of our requirements is that it shall be possible to support
multiple levels of hierarchy with minimal (ideally no) mobile involvement.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 12:00:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07189
	for ; Fri, 16 Mar 2001 12:00:08 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09256;
	Fri, 16 Mar 2001 08:59:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22301;
	Fri, 16 Mar 2001 08:58:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGvcIm010865
	for ; Fri, 16 Mar 2001 08:57:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GGvcpc010864
	for mobile-ip-dist; Fri, 16 Mar 2001 08:57:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GGvTIm010857
	for ; Fri, 16 Mar 2001 08:57:29 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14575
	for ; Fri, 16 Mar 2001 08:57:29 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19308
	for ; Fri, 16 Mar 2001 08:57:22 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA26502
	for ; Fri, 16 Mar 2001 08:55:25 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GGtNA24206
	for ; Fri, 16 Mar 2001 08:55:23 -0800
X-mProtect:  Fri, 16 Mar 2001 08:55:23 -0800 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdcDrNKf; Fri, 16 Mar 2001 08:55:02 PST
Message-ID: <3AB24567.21A4B40B@iprg.nokia.com>
Date: Fri, 16 Mar 2001 08:55:03 -0800
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Re: Comments on Regional Registration
References: <85AA7486A2C1D411BCA20000F8073E43018BA88D@crchy271.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello folks,


> Glenn Morrow wrote:


> This is getting ridiculous. It seems that if I make a suggestion to either I
> end up irritating the other - not exactly a hospitable environment to
> contribute to either.

I'm not irritated by any suggestion you've made regarding HMIP.

> In the end I do not care what we call it. Perhaps we should come up with
> another acronym just to reduce the my idea vs. your idea competition.

Actually, as I have mentioned several times, I have no problem
with trying to merge.  There are several things about the existing
HMIP document that I think need serious reconsideration (e.g., load
balancing) but that's to be the subject of a different note.

> These discussions stink of what I call PWS (Patent War Syndrome). If that is
> the case then people will likely end up promoting something that isn't the
> most optimal solution as the standard or there will be multiple optional
> standards which exacerbate the solution space for future issues.

As far as I know, Nokia doesn't intend to pursue any patents on the
ideas in the Regional Registration draft.

To be clear, I do not maintain my involvement with Regional Registration
because of any NIH syndrome, and if you have found any trace of that
in my mailings to this list I would appreciate that you point it out
to me.



> From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se]


> Before I start commenting on your proposal, I think there are
> some questions that need to be answered.
> Why do we need a multilevel static hierarchy of mobility
> aware routers ?

It doesn't have to be static.  For our purposes, we only have to
know that it is multilevel.  The method of organizing the relationships
between the regional-aware routers does not have to be part of our
initial specification.

I am suggesting that for IPv6 we have to think about billions.
That means we have to be very, very careful about scalability.
I do not believe the HMIPv6 proposal is sufficiently scalable
(in the dimension of size of mobile node population).

> The other question is, do we want to associate the implementation
> of this protocol with an imaginary protocol that generates
> an SA between the MN and the domain and distributes the
> key to all mobility aware routers ?

Gee Hesham, one could easily read that as a slur.

> Do we want to have a tree-based hierarchy full of single
> points of failure ?

An anycast group is a very good mechanism by which one can
avoid such single points of failure.

> I don't want any of the above, but I'd like to see what others
> think.

Maybe you didn't exactly intend to do so, but you have come
very close to setting up straw men for others to knock over.
I do not view it as constructive.

> As you said Light travels fast and I like to Keep it simple,
> so unless there are strong and well thought requirements
> for the multi-level hierarchy, I think it should be dropped.

Light doesn't travel faster than mathematics, and I think that
the advantages for hierarchical localization of routing updates
are well accepted.


 -----Original Message-----
> > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> > Sent: Friday, 16 March 2001 1:59
> > To:   mobile-ip@sunroof.eng.sun.com
> > Subject:      RE: [mobile-ip] Re: Comments on Regional Registration
> >
> > Hesham and Charlie,
> >
> > I'm not too worried about the security association issue with anycast. I
> think anycast is extremely useful and is here to stay. It is part of IPv6 -
> might as well take advantage of it.
> 
> >
> > I believe the SA establishment and scaling problem for MIP, in general, has
> scaling and speed issues. It would actually probably be more productive for us
> to focus on that issue than heirarchical models. It seems people have focused
> so far on "database in the sky" solutions with AAA protocols to this.

I agree that key establishment issues need more work.  There will be a
lot of work on this in the immediate future.  However, the regional
stuff is too important to ignore, and deciding on a good model for
localizing binding updates is an important current discussion.


> > I have an alternate idea which I would like to bring up again.
> >
> > Why don't we use a hop by hop option to alert mobile-aware routers to the
> binding updates. For instance, a mobile could send a binding update to a CN
> and it would be intercepted by the 1st hop router in the visited domain.

Hop-by-hop options are automatically less scalable than other
possible solutions, and so I reckon we ought to use them very
carefully.  It would make sense if we could imagine requiring that
all visited-domain routers should be regional-aware.  Otherwise,
the hop-by-hop option will just look like unwanted work to a
significant fraction of the routers that process it.

I hope you'll excuse that I do not comment on the further
detailed proposal.  I think it has definite merit, and should
be carefully considered.  So far, all the security information
for Binding Updates has been engineered to be provided by the
mobile nodes.  Allowing regional routers to rebuild the
authentication is intriguing, but I think it will take a LOT
of work and discussion to see if the security model can be
made to work out well.

However, as far as I can see your approach COULD be retrofitted as
an backwards compatible upgrade to a regional approach that did not
involve rewriting authentication data.

> > Another approach might be to send binding updates to the visited subnet
> anycast addresses and chain the message up the network i.e. MN subnet to site,
> site to site, site to CN subnet and then to CN.

Hmmm!

> > One thing I really can't understand with both of your proposed hierarchical
> solutions is why you want to send more than one binding update. This burns the
> air resources. The whole idea for doing heirarchical was to reduce signaling
> latency for cellular. These networks are the only networks that I am aware of
> that someone might be moving so fast as to warrant a heirarchical scheme. The
> solutions seem to conflict with requirements.

We have suggested something similar multiple times.  I agree that it
would be nice to coalesce the signaling.  We had defined something called
a "Previous Access Router Notification" (PARN) extension that has some
of the same properties you suggest.  However, it's more important to
get the basic model right, and then apply such optimizations.  I hope
we can do so.

> > The last thing I would like to say that it seems we are spending way to much
> time on something that provides so little gain. Light travels very fast.

But packets sitting in non-local routing queues are delayed sometimes
by things that don't depend on the speed of light.  We're not dealing
with optimizing the transmission speed between the local link and the
GMA/MAP/GFA/etc.  We're trying to figure out how to cause binding
updates to be processed and forwarded by the fewest number of network
elements.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 12:07:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07334
	for ; Fri, 16 Mar 2001 12:07:03 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15856;
	Fri, 16 Mar 2001 09:05:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17399;
	Fri, 16 Mar 2001 09:05:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GH4JIm010891
	for ; Fri, 16 Mar 2001 09:04:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GH4J0F010890
	for mobile-ip-dist; Fri, 16 Mar 2001 09:04:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GH48Im010883
	for ; Fri, 16 Mar 2001 09:04:08 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by jurassic.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with SMTP id f2GH46RA385703
	for ; Fri, 16 Mar 2001 09:04:07 -0800 (PST)
Message-Id: <200103161704.f2GH46RA385703@jurassic.eng.sun.com>
Date: Fri, 16 Mar 2001 12:04:13 -0500 (EST)
From: Steven Glass - Solaris Software 
Subject: [mobile-ip] List info...
To: mobile-ip@sunroof.eng.sun.com
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc 
Content-Type: text
X-Sun-Text-Type: ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


    As you may have noticed, we've unmoderated the list.  My appologies for the 
(sometimes) several hours things sat in my inbox, but I'm glad for the 
(sometimes) several minutes some also took to "approve".
    
    Keep in mind - you MUST post/administer from a subscribed address (hopefully 
your own), and nothing over 40K!  Problems, comments, concerns, etc. to 
owner-mobile-ip@sunroof.eng.sun.com.
    
                              Cheers,
                                  Steve


From ronyoung@nortelnetworks.com  Fri Mar 16 12:51:59 2001
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07776
	for ; Fri, 16 Mar 2001 12:51:59 -0500 (EST)
Received: from zrchh190 by smtprch2.nortel.com; Fri, 16 Mar 2001 06:18:47 -0600
Received: from marvin.corpeast.baynetworks.com by zrchh190;
          Fri, 16 Mar 2001 06:15:33 -0600
Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) 
          by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP 
          id HAA00409 for ;
          Fri, 16 Mar 2001 07:00:47 -0500 (EST)
Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t;
          Fri, 16 Mar 2001 06:59:42 -0500
Received: from mailhub1.shef.ac.uk ( [143.167.1.9]) by 
          with SMTP (MailShield v1.5); Fri, 16 Mar 2001 07:01:01 -0500
Received: from broadstone.shef.ac.uk ([143.167.23.251]) by mailhub1.shef.ac.uk 
          with esmtp (Exim 3.16 #1) id 14dssm-0003ws-00 
          for mobile-ip@standards.nortelnetworks.com;
          Fri, 16 Mar 2001 11:59:00 +0000
Received: from BROADSTONE/SpoolDir by broadstone.shef.ac.uk (Mercury 1.48);
          16 Mar 01 11:59:01 +0000
Received: from SpoolDir by BROADSTONE (Mercury 1.48); 16 Mar 01 11:58:56 +0000
Received: from Tao (143.167.251.196) by broadstone.shef.ac.uk (Mercury 1.48);
          16 Mar 01 11:58:53 +0000
Date: Wed, 15 Mar 2000 12:3:41 +0000
From: Tao Huang 
Reply-To: m0th@dcs.shef.ac.uk
To: mobile-ip@marvin.corpeast.baynetworks.com
Subject: A question about DHCP for Mobile IP
X-mailer: FoxMail 3.1 [eg]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: 
X-SMTP-HELO: mailhub1.shef.ac.uk
X-SMTP-MAIL-FROM: m0th@dcs.shef.ac.uk
X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com
X-SMTP-PEER-INFO: [143.167.1.9]
X-Orig: 
X-Orig: 
X-Orig: 
Content-Transfer-Encoding: 7bit

Hello,

I have a question about the ip address of mobile node. 

If a mobile node move into a foreign network and use the foreign agent's ip address as care-of address,
should it obtain a local IP address by DHCP? 
Or when the mobile node use co-located address to register to home agent, how can the mobile node get 
a new address when moves to a new foreign network. From the book"Mobile IP", it say that mobile node can use
any mechanism to detect whether it needs to make a new point of attachment to the internet. Then what 
mechanism available? 
I remember that in win98, you had to reboot your computer after you change your IP address. How can it work 
for the mobile IP if the mobile node had to change its IP address frequently.

cheers




From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 12:58:14 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07910
	for ; Fri, 16 Mar 2001 12:58:13 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03212;
	Fri, 16 Mar 2001 09:56:26 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27590;
	Fri, 16 Mar 2001 09:55:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GHs7Im011044
	for ; Fri, 16 Mar 2001 09:54:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GHs75D011043
	for mobile-ip-dist; Fri, 16 Mar 2001 09:54:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GHrvIm011036
	for ; Fri, 16 Mar 2001 09:53:58 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25752
	for ; Fri, 16 Mar 2001 09:53:57 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07290
	for ; Fri, 16 Mar 2001 09:53:56 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02408
	for ; Fri, 16 Mar 2001 09:53:48 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GHrki32225
	for ; Fri, 16 Mar 2001 09:53:46 -0800
X-mProtect:  Fri, 16 Mar 2001 09:53:46 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdDqc9HJ; Fri, 16 Mar 2001 09:53:32 PST
Message-ID: <3AB2531E.CDEAF077@cs.ucl.ac.uk>
Date: Fri, 16 Mar 2001 09:53:34 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Request for your comments in proactive handovers work
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham/all,

The message above was in continuation of the first message I sent first.
This was:

  I am reaching out for your comments on some work that I have done
towards proactive handovers in IPv6. This can be found at

http://www.cs.ucl.ac.uk/staff/t.pagtzis/r.ps.gz

This work is toward a draft that is currently in some shape, but I would
like your comments before I would
post such draft out. This way I could have some critical considerations
about what questions remain unanswered.

 For that I reach out for your comments.

I emphasize that this report iis not complete and in some flux; however
the core idea is there. I
would appreciate any comments that you could throw at it and possible
suggestions.


Many Thanks

Theo

----- second message ----------------------------------------

   I forgot to say the scheme really pushes for UDP flows....basically
what
all the guys have been talking about real-time interactive multimedia...

For TCP I have another strand of that.... :))))

And by the way bother to throw some stones at it before lauging..
meaning read it first, throw stones then

Thanks


Theo


PS.  I apologize for the initial attachment that bounced my message and
irritated the list maintainer.. :)



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 13:09:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08074
	for ; Fri, 16 Mar 2001 13:09:55 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14472;
	Fri, 16 Mar 2001 10:08:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07725;
	Fri, 16 Mar 2001 10:08:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GI79Im011095
	for ; Fri, 16 Mar 2001 10:07:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GI78IL011094
	for mobile-ip-dist; Fri, 16 Mar 2001 10:07:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GI6xIm011087
	for ; Fri, 16 Mar 2001 10:06:59 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00541
	for ; Fri, 16 Mar 2001 10:07:00 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10583
	for ; Fri, 16 Mar 2001 10:06:59 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2GI6wd15712
	for ; Fri, 16 Mar 2001 19:06:58 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 16 19:05:42 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 16 Mar 2001 19:02:56 +0100
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
Date: Fri, 16 Mar 2001 19:06:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello James

> I don't want to get involved in taking sides on either of 
> your proposals
> because I see points with which I agree and disagree in both. 
> While I don't want to cast any aspersions, I'm very curious to know
> how one proposal was selected as a working group draft without an
> agreed upon set of requirements.

If you're looking for a formal set of requirements in draft form,
there aren't any apart from those in the individual drafts. However,
the local anchor point problem was addressed in v4 with Regional
Registrations, so the same set of supporting reasons exist in v6.
So it seems logical that a solution was proposed for v6.
If you remember there were three proposals in Pittsburgh. Some
issues, esp. security were raised about one of them (Jari's). The
remaining two (Claude's and Hesham's) had a lot of things in common and
were merged. The request to make this into a WG doc and move the HMIP
work forward was put on the list and there seemed to be no problem.
Of course any comments on HMIPv6 are still welcome. Hope this clarifies
things.

> In a previous email, I expressed my reservations about tunnelling 
> over the radio link, and the requirement for efficient use of the
> radio link.

Working for Ericsson I am of course interested in spectrum efficiency.
However it has been already pointed out that this is probably
a ROHC issue, independent of HMIP, and I believe ROHC WG is working
on this.

> In this email, I'd like to bring up an additional requirement. There
> has been some discussion about whether or not arbitrary levels of
> hierarchy are of value. We recently did a study of using HMIP for
> a next generation IP based radio access network, and one of the 
> issues was supporting arbitrary levels of hierarchy with 
> minimal (ideally
> no) mobile involvement.

Can you give reasons?
I believe that it is important for HMIPv6 not to be tailored only to
RAN issues. It should be simple and generic.

> It seemed like it could be done with extended
> mode, but there were other problems with extended mode that made
> it less attractive. I have not looked at the most recent draft yet,
> perhaps those points have been addressed.

OK.

> 
> One of our requirements is that it shall be possible to support
> multiple levels of hierarchy with minimal (ideally no) mobile 
> involvement.

This is a very specific case, so I'd be interested if you
could provide more reasons for this requirement. It's not a requirement
from RAN standards I'm involved in.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 13:34:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08333
	for ; Fri, 16 Mar 2001 13:34:50 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22056;
	Fri, 16 Mar 2001 10:30:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04033;
	Fri, 16 Mar 2001 10:30:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GISUIm011240
	for ; Fri, 16 Mar 2001 10:28:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GISTfk011239
	for mobile-ip-dist; Fri, 16 Mar 2001 10:28:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GISLIm011232
	for ; Fri, 16 Mar 2001 10:28:21 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12155
	for ; Fri, 16 Mar 2001 10:28:21 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA19411
	for ; Fri, 16 Mar 2001 10:28:21 -0800 (PST)
Message-Id: <200103161828.KAA19411@heliopolis.Eng.Sun.COM>
Date: Fri, 16 Mar 2001 10:28:21 -0800 (PST)
From: James Kempf 
Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OzQjJnNisrzsmdF1lLITCg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Karim,

Thanx for your reply.

>Working for Ericsson I am of course interested in spectrum efficiency.
>However it has been already pointed out that this is probably
>a ROHC issue, independent of HMIP, and I believe ROHC WG is working
>on this.
>

The specific issue had to do with moving header compression context,
and especially whether there is additional overhead involved in re-establishing 
header compression after handover at all or with additional tunnel headers or
header options. I think this is probably a Seamoby/Context Transfer issue.

>> In this email, I'd like to bring up an additional requirement. There
>> has been some discussion about whether or not arbitrary levels of
>> hierarchy are of value. We recently did a study of using HMIP for
>> a next generation IP based radio access network, and one of the 
>> issues was supporting arbitrary levels of hierarchy with 
>> minimal (ideally
>> no) mobile involvement.
>
>Can you give reason?

Yes. In the RAN design we are looking at, there is an upper part
on which packets are application or user packets. We would like
to use a hierarchical MIP to implement mobility (what we call
micromobility, which is different from what Seamoby calls micromobility)
across this part of the RAN. I can't say more without getting into
deeper technical details, which I would rather not at the moment.
The important point is that we would like the mobile to be aware
of just one level of hierarchy, and there will be hierarchy outside
the RAN, in the core, if the operator wants to optimize signalling,
or provide a locally assigned home address.

>I believe that it is important for HMIPv6 not to be tailored only to
>RAN issues. It should be simple and generic.
>

Agreed.


>> It seemed like it could be done with extended
>> mode, but there were other problems with extended mode that made
>> it less attractive. I have not looked at the most recent draft yet,
>> perhaps those points have been addressed.
>
>OK.
>
>> 
>> One of our requirements is that it shall be possible to support
>> multiple levels of hierarchy with minimal (ideally no) mobile 
>> involvement.
>
>This is a very specific case, so I'd be interested if you
>could provide more reasons for this requirement. It's not a requirement
>from RAN standards I'm involved in.
>

The requirements come out of the MWIF study on IP based RANs, but 
3GPP2 has begun an activity to redesign their RAN to be more compatible
with IP. So far, 3GPP hasn't been very receptive to this idea. We
would like to submit the design we've been  looking at to 3GPP2, but
we want to make sure we have a good hierarchical scheme.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 14:45:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09374
	for ; Fri, 16 Mar 2001 14:45:42 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00746;
	Fri, 16 Mar 2001 11:44:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02328;
	Fri, 16 Mar 2001 11:43:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJfUIm011414
	for ; Fri, 16 Mar 2001 11:41:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GJfT5n011413
	for mobile-ip-dist; Fri, 16 Mar 2001 11:41:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJfKIm011406
	for ; Fri, 16 Mar 2001 11:41:21 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20331
	for ; Fri, 16 Mar 2001 11:41:20 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08734
	for ; Fri, 16 Mar 2001 11:41:18 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2GJfHd01650
	for ; Fri, 16 Mar 2001 20:41:17 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 16 20:43:03 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 16 Mar 2001 20:37:16 +0100
Message-ID: 
From: "Karim El-Malki (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
Date: Fri, 16 Mar 2001 20:41:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi

> >Working for Ericsson I am of course interested in spectrum 
> efficiency.
> >However it has been already pointed out that this is probably
> >a ROHC issue, independent of HMIP, and I believe ROHC WG is working
> >on this.
> >
> 
> The specific issue had to do with moving header compression context,
> and especially whether there is additional overhead involved 
> in re-establishing 
> header compression after handover at all or with additional 
> tunnel headers or
> header options. I think this is probably a Seamoby/Context 
> Transfer issue.

I agree that it is in Seamoby's realm and if required something can
be done there to achieve CT.

> 
> >> In this email, I'd like to bring up an additional 
> requirement. There
> >> has been some discussion about whether or not arbitrary levels of
> >> hierarchy are of value. We recently did a study of using HMIP for
> >> a next generation IP based radio access network, and one of the 
> >> issues was supporting arbitrary levels of hierarchy with 
> >> minimal (ideally
> >> no) mobile involvement.
> >
> >Can you give reason?
> 
> Yes. In the RAN design we are looking at, there is an upper part
> on which packets are application or user packets. We would like
> to use a hierarchical MIP to implement mobility (what we call
> micromobility, which is different from what Seamoby calls 
> micromobility)
> across this part of the RAN. I can't say more without getting into
> deeper technical details, which I would rather not at the moment.
> The important point is that we would like the mobile to be aware
> of just one level of hierarchy, and there will be hierarchy outside
> the RAN, in the core, if the operator wants to optimize signalling,
> or provide a locally assigned home address.

From the cases I've seen, the home and care-of addresses always lie
outside the RAN. So you can be aware of just one level of hierarchy,
since the eventual radio hierarchy is invisible to the MN.
As you've pointed out it's better if we take this discussion offline
since it would need getting into more technical details.

> >> One of our requirements is that it shall be possible to support
> >> multiple levels of hierarchy with minimal (ideally no) mobile 
> >> involvement.
> >
> >This is a very specific case, so I'd be interested if you
> >could provide more reasons for this requirement. It's not a 
> requirement
> >from RAN standards I'm involved in.
> >
> 
> The requirements come out of the MWIF study on IP based RANs, but 
> 3GPP2 has begun an activity to redesign their RAN to be more 
> compatible
> with IP. So far, 3GPP hasn't been very receptive to this idea. We
> would like to submit the design we've been  looking at to 3GPP2, but
> we want to make sure we have a good hierarchical scheme.

OK, from what you're saying it doesn't seem like it is a network that
has been specified with frozen specs. I'd appreciate it if you could
point me to where I can find details. Also I don't think it would be
applicable to 3GPP.

Regards
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 14:59:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10094
	for ; Fri, 16 Mar 2001 14:59:23 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07961;
	Fri, 16 Mar 2001 11:58:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24638;
	Fri, 16 Mar 2001 11:57:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJtpIm011486
	for ; Fri, 16 Mar 2001 11:55:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GJtpuu011485
	for mobile-ip-dist; Fri, 16 Mar 2001 11:55:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJtgIm011478
	for ; Fri, 16 Mar 2001 11:55:42 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26800
	for ; Fri, 16 Mar 2001 11:55:42 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01844
	for ; Fri, 16 Mar 2001 12:55:11 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA20559
	for ; Fri, 16 Mar 2001 11:51:25 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI37479;
	Fri, 16 Mar 2001 11:51:24 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03593; Fri, 16 Mar 2001 11:51:24 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.28348.320143.439106@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 11:51:24 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit



Karim El-Malki (ERA) writes:

[]

Not to pick on Karim, but could people please
follow normal quoting conventions which leaves the
person who you are responding to in the followup
like I did here? It makes it very difficult to
figure out who people are responding to if you
don't do that.

	 thx, Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 15:04:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10200
	for ; Fri, 16 Mar 2001 15:04:05 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09701;
	Fri, 16 Mar 2001 12:01:29 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07698;
	Fri, 16 Mar 2001 11:59:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJwOIm011496
	for ; Fri, 16 Mar 2001 11:58:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GJwOL3011495
	for mobile-ip-dist; Fri, 16 Mar 2001 11:58:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GJwFIm011488
	for ; Fri, 16 Mar 2001 11:58:15 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07150
	for ; Fri, 16 Mar 2001 11:58:15 -0800 (PST)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21875
	for ; Fri, 16 Mar 2001 11:57:51 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GJvdg22141
	for ; Fri, 16 Mar 2001 13:57:50 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 16 Mar 2001 13:57:37 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 16 Mar 2001 13:57:37 -0600
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032136A4@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf@heliopolis.eng.sun.com
Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
Date: Fri, 16 Mar 2001 13:57:36 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


>Hesham & Jari,
>
>I don't want to get involved in taking sides on either of your proposals
>because I see points with which I agree and disagree in both. 
>While I don't want to cast any aspersions, I'm very curious to know
>how one proposal was selected as a working group draft without an
>agreed upon set of requirements. 

We did a WG consensus call sometime last year (need to dig the
archives for the details), before deciding on making HMIPv6 a WG
document. I wonder where were all these views and arguments when the
call was issued.

>
>		jak
>

-Basavaraj


> -----Original Message-----
> From: ext James Kempf [mailto:kempf@heliopolis.eng.sun.com]
> Sent: Friday, March 16, 2001 12:28 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
> 
> 
> Hi Karim,
> 
> Thanx for your reply.
> 
> >Working for Ericsson I am of course interested in spectrum 
> efficiency.
> >However it has been already pointed out that this is probably
> >a ROHC issue, independent of HMIP, and I believe ROHC WG is working
> >on this.
> >
> 
> The specific issue had to do with moving header compression context,
> and especially whether there is additional overhead involved 
> in re-establishing 
> header compression after handover at all or with additional 
> tunnel headers or
> header options. I think this is probably a Seamoby/Context 
> Transfer issue.
> 
> >> In this email, I'd like to bring up an additional 
> requirement. There
> >> has been some discussion about whether or not arbitrary levels of
> >> hierarchy are of value. We recently did a study of using HMIP for
> >> a next generation IP based radio access network, and one of the 
> >> issues was supporting arbitrary levels of hierarchy with 
> >> minimal (ideally
> >> no) mobile involvement.
> >
> >Can you give reason?
> 
> Yes. In the RAN design we are looking at, there is an upper part
> on which packets are application or user packets. We would like
> to use a hierarchical MIP to implement mobility (what we call
> micromobility, which is different from what Seamoby calls 
> micromobility)
> across this part of the RAN. I can't say more without getting into
> deeper technical details, which I would rather not at the moment.
> The important point is that we would like the mobile to be aware
> of just one level of hierarchy, and there will be hierarchy outside
> the RAN, in the core, if the operator wants to optimize signalling,
> or provide a locally assigned home address.
> 
> >I believe that it is important for HMIPv6 not to be tailored only to
> >RAN issues. It should be simple and generic.
> >
> 
> Agreed.
> 
> 
> >> It seemed like it could be done with extended
> >> mode, but there were other problems with extended mode that made
> >> it less attractive. I have not looked at the most recent draft yet,
> >> perhaps those points have been addressed.
> >
> >OK.
> >
> >> 
> >> One of our requirements is that it shall be possible to support
> >> multiple levels of hierarchy with minimal (ideally no) mobile 
> >> involvement.
> >
> >This is a very specific case, so I'd be interested if you
> >could provide more reasons for this requirement. It's not a 
> requirement
> >from RAN standards I'm involved in.
> >
> 
> The requirements come out of the MWIF study on IP based RANs, but 
> 3GPP2 has begun an activity to redesign their RAN to be more 
> compatible
> with IP. So far, 3GPP hasn't been very receptive to this idea. We
> would like to submit the design we've been  looking at to 3GPP2, but
> we want to make sure we have a good hierarchical scheme.
> 
> 		jak
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 15:11:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10351
	for ; Fri, 16 Mar 2001 15:11:43 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13992;
	Fri, 16 Mar 2001 12:09:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11515;
	Fri, 16 Mar 2001 12:08:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GK7CIm011571
	for ; Fri, 16 Mar 2001 12:07:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GK7CIn011570
	for mobile-ip-dist; Fri, 16 Mar 2001 12:07:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GK73Im011563
	for ; Fri, 16 Mar 2001 12:07:03 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29522
	for ; Fri, 16 Mar 2001 12:07:03 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29220
	for ; Fri, 16 Mar 2001 12:07:00 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 16 Mar 2001 10:12:55 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 10:14:15 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BAA3F@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Fri, 16 Mar 2001 10:14:12 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE34.238ADF50"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE34.238ADF50
Content-Type: text/plain;
	charset="iso-8859-1"

It does seem to me to be a node mobility problem; although, I am please that
any WG is beginning to acknowledge the issue and explore solutions to it.
Where would you like to discuss it?

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Friday, March 16, 2001 9:50 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-


Glenn Morrow writes:
 > Thanks Claude,
 >  
 > I'll take a look. I am hoping others will follow suit with more
candidates
 > as well. This location privacy thing is one of the last "what's
missings". I
 > have to say I have found it very uncomfortable going forward on solutions
to
 > other aspects of the problem with this issue dangling.

   Hmm. I suspect that IP location privacy is not just a MIP
   issue. It certainly comes up in VoIP-land regularly when
   wanting to provide "caller-id blocking" where you need to
   provide complete anonymity for a caller, the canonical
   example being the battered wife not wanting hubby to use
   the incoming RTP packets to guess where she is. For SIP,
   the general consensus was to just build a SIP anonymizer
   out of a back to back UA, but that is hardly a general 
   purpose mechanism.

   I believe that there have been BOF's in the past about
   location (SPACIAL, I think), though I didn't attend. The
   topic does, however, keep coming up. I really wonder whether:

   a) this really belongs in MIP WG on the one hand
   b) whether MIP may provide a good foundation to
      solve the general problem on the other hand

		Mike


------_=_NextPart_001_01C0AE34.238ADF50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] -HMIPv6 draft + Privacy draft-




It does seem to me to be a node mobility problem; =
although, I am please that any WG is beginning to acknowledge the issue =
and explore solutions to it. Where would you like to discuss =
it?



-----Original Message-----

From: Michael Thomas [mailto:mat@cisco.com]

Sent: Friday, March 16, 2001 9:50 AM

To: mobile-ip@sunroof.eng.sun.com

Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy =
draft-






Glenn Morrow writes:

 > Thanks Claude,

 >  

 > I'll take a look. I am hoping others will =
follow suit with more candidates

 > as well. This location privacy thing is =
one of the last "what's missings". I

 > have to say I have found it very =
uncomfortable going forward on solutions to

 > other aspects of the problem with this =
issue dangling.




   Hmm. I suspect that IP location privacy =
is not just a MIP

   issue. It certainly comes up in =
VoIP-land regularly when

   wanting to provide "caller-id =
blocking" where you need to

   provide complete anonymity for a =
caller, the canonical

   example being the battered wife not =
wanting hubby to use

   the incoming RTP packets to guess where =
she is. For SIP,

   the general consensus was to just build =
a SIP anonymizer

   out of a back to back UA, but that is =
hardly a general 

   purpose mechanism.




   I believe that there have been BOF's in =
the past about

   location (SPACIAL, I think), though I =
didn't attend. The

   topic does, however, keep coming up. I =
really wonder whether:




   a) this really belongs in MIP WG on the =
one hand

   b) whether MIP may provide a good =
foundation to

      solve the general =
problem on the other hand




        =
        Mike





------_=_NextPart_001_01C0AE34.238ADF50--


From ronyoung@nortelnetworks.com  Fri Mar 16 15:46:43 2001
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12634
	for ; Fri, 16 Mar 2001 15:46:42 -0500 (EST)
Received: from zrchh190 by smtprch2.nortel.com; Fri, 16 Mar 2001 13:48:27 -0600
Received: from marvin.corpeast.baynetworks.com by zrchh190;
          Fri, 16 Mar 2001 13:49:35 -0600
Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) 
          by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP 
          id OAA08413 for ;
          Fri, 16 Mar 2001 14:40:16 -0500 (EST)
From: pr@hichina.com
Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com;
          Fri, 16 Mar 2001 14:37:53 -0500
Received: from pylon.dongmyung-m.ed.kyongbuk.kr ( [210.96.24.60]) 
          by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5);
          Fri, 16 Mar 2001 14:39:59 -0500
Received: from localhost.localdomain (localhost [127.0.0.1]) 
          by pylon.dongmyung-m.ed.kyongbuk.kr (8.9.3/8.9.3) with ESMTP 
          id EAA17440 for ;
          Sat, 17 Mar 2001 04:29:07 +0900
Date: Sat, 17 Mar 2001 04:29:07 +0900
Message-Id: <200103161929.EAA17440@pylon.dongmyung-m.ed.kyongbuk.kr>
Subject: Re: Your prize money Dear friend,
X-SMTP-HELO: pylon.dongmyung-m.ed.kyongbuk.kr
X-SMTP-MAIL-FROM: pr@hichina.com
X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com
X-SMTP-PEER-INFO: [210.96.24.60]
X-Orig: 
To: mobile-ip@marvin.corpeast.baynetworks.com
X-Orig: 
X-Orig: 

 We have got your name from the legal sources that make
 us think you enjoy gambling.
 Please allow us to present to you our FREE online
 lottery AQUALOTTO at http://www.aqualotto.com

 I wish you the very best of luck!

 Reseller ID - http://www.aqualotto.com/index.php3?id=BY-0065
 ------------------------------------------

 This is not a SPAM. You are receiving this because you are
 on a list of email addresses that I have purchased for marketing.
 And you have opted to receive information via email.
 If you did not opt in to receive information please accept my apology.
 To be REMOVED from this list simply reply with REMOVE as the subject line.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 15:57:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12887
	for ; Fri, 16 Mar 2001 15:57:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10651;
	Fri, 16 Mar 2001 12:56:01 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09130;
	Fri, 16 Mar 2001 12:55:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GKpHIm011657
	for ; Fri, 16 Mar 2001 12:51:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GKpGdj011656
	for mobile-ip-dist; Fri, 16 Mar 2001 12:51:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GKp3Im011649
	for ; Fri, 16 Mar 2001 12:51:03 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08437
	for ; Fri, 16 Mar 2001 12:51:02 -0800 (PST)
From: Phil_Neumiller@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17031
	for ; Fri, 16 Mar 2001 13:51:00 -0700 (MST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GKnTd07560;
	Fri, 16 Mar 2001 12:49:29 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2GKotQ01993;
	Fri, 16 Mar 2001 12:50:55 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256A11.0072830F ; Fri, 16 Mar 2001 12:50:46 -0800
X-Lotus-FromDomain: 3COM
To: "HUYLEBROECK Jeremy / FTR&D" 
cc: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256A11.00727F9F.00@hqoutbound.ops.3com.com>
Date: Fri, 16 Mar 2001 14:49:16 -0600
Subject: [mobile-ip] Re: [MOBILE-IP] Who implements MIP?
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=xfRYw0adqi4lY2lOglFNAaSZAWPca1fZoDzev0gj17dxhbzpsG68lRsr"
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--0__=xfRYw0adqi4lY2lOglFNAaSZAWPca1fZoDzev0gj17dxhbzpsG68lRsr
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




Please see recent threads on SeaMoby WG on MIP implementations.
There are millions of active subscribers doing MIP handoffs on Nextel (US),
Sprint (US) and KDD (Japan) systems worldwide.  These systems do work.
The SeaMoby WG is gathering statistics on MIP implementations to justify
its own micro-mobility work's existence.  Something that the MIP WG has never
had to do surprisingly. :-) We are still collecting data and will be correcting
errors as we go along.

more comments below




Please respond to "HUYLEBROECK Jeremy / FTR&D"
      

Sent by:  "HUYLEBROECK Jeremy / FTR&D" 


I thought Nextel uses M-IP already on its network (in USA at least).
I am wrong if I say they must have MIP equipment then ?

[MOBILE-IP] Who implements MIP?


Which is really saying very little. As none of them have products out there
that works.

pdn>The above statement is false.

The closest is the 2.5G cdma2000 1xRTT systems that are currently in
commercial service in Korea (as I am sure you are aware), but even they do
not have any commercial mobile IP terminals.

pdn>The above statement is false.

It would help if (as numerous people have said) if Microsoft would get
around to really supporting Mobile IP v4 / v6 in their OS ...

pdn>I am curious about the above comment.  How would this really help MIP?
pdn>I guess I am trying to visualize the use cases that would be served that
pdn>are not served now.

Thanks,


Phil Neumiller


--0__=xfRYw0adqi4lY2lOglFNAaSZAWPca1fZoDzev0gj17dxhbzpsG68lRsr
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PUVVQy1LUiI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRFTlQ9Ik1T
IEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDUuNS4yNDQ4LjAiPg0KPFRJVExFPlJFOiBbTU9CSUxF
LUlQXSBXaG8gaW1wbGVtZW50cyBNSVA/PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48
Rk9OVCBTSVpFPTI+SSB0aG91Z2h0IE5leHRlbCB1c2VzIE0tSVAgYWxyZWFkeSBvbiBpdHMgbmV0
d29yayAoaW4gVVNBIGF0IGxlYXN0KS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkkgYW0gd3Jv
bmcgaWYgSSBzYXkgdGhleSBtdXN0IGhhdmUgTUlQIGVxdWlwbWVudCB0aGVuID88L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5KZXJlbXkgSHV5bGVicm9lY2s8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPkZyYW5jZSBUZWxlY29tIFImYW1wO0Q8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+RnJvbTogV29vanVuZSBLaW0gWzxBIEhSRUY9Im1haWx0bzp3amtpbUBzYW1zdW5nLmNvbSI+
bWFpbHRvOndqa2ltQHNhbXN1bmcuY29tPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlNl
bnQ6IFR1ZXNkYXksIEphbnVhcnkgMzAsIDIwMDEgNDo1MiBQTTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+VG86IE1PQklMRS1JUEBTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogW01PQklMRS1JUF0gV2hvIGltcGxlbWVudHMg
TUlQPzwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPldoaWNoIGlzIHJlYWxs
eSBzYXlpbmcgdmVyeSBsaXR0bGUuIEFzIG5vbmUgb2YgdGhlbSBoYXZlIHByb2R1Y3RzIG91dCB0
aGVyZSB0aGF0IHdvcmtzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZSBjbG9z
ZXN0IGlzIHRoZSAyLjVHIGNkbWEyMDAwIDF4UlRUIHN5c3RlbXMgdGhhdCBhcmUgY3VycmVudGx5
IGluIGNvbW1lcmNpYWwgc2VydmljZSBpbiBLb3JlYSAoYXMgSSBhbSBzdXJlIHlvdSBhcmUgYXdh
cmUpLCBidXQgZXZlbiB0aGV5IGRvIG5vdCBoYXZlIGFueSBjb21tZXJjaWFsIG1vYmlsZSBJUCB0
ZXJtaW5hbHMuIDwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JdCB3b3VsZCBoZWxwIGlm
IChhcyBudW1lcm91cyBwZW9wbGUgaGF2ZSBzYWlkKSBpZiBNaWNyb3NvZnQgd291bGQgZ2V0IGFy
b3VuZCB0byByZWFsbHkgc3VwcG9ydGluZyBNb2JpbGUgSVAgdjQgLyB2NiBpbiB0aGVpciBPUyAu
Li4gPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPldvb2p1bmUgS2ltLDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+U2VuaW9yIEVuZ2luZWVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5T
YW1zdW5nIEVsZWN0cm9uaWNzIEx0ZC4gPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBT
SVpFPTI+TW9zdCBvZiB0aGUgSU1ULTIwMDAgd2lyZWxlc3MgY2VsbHVsYXIgbmV0d29yayBkZXZp
Y2UgdmVuZG9ycyBkby48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5KaXdvb25nIExl
ZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug
LS0tLS0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBTdWRoYSBSYW1lc2ggJmx0O3N1
ZGhhQHJlc2VhcmNoLnRlbGNvcmRpYS5jb20mZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5U
bzogJmx0O01PQklMRS1JUEBTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NJmd0OzwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDMxLCAyMDAxIDE6NTUg
QU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1YmplY3Q6IFtNT0JJTEUtSVBdIFdobyBpbXBs
ZW1lbnRzIE1JUD88L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IEZp
cnN0IG9mIGFsbCwgSSBhbSBzb3JyeSBpZiB0aGlzIGlzIGEgcmVwZWF0IHF1ZXN0aW9uIGZvciBz
b21lL21vc3Qgb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgeW91LjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBJIGhhdmUgYmVlbiB1bmFibGUgdG8gYWNjZXNzIHRoZSBhcmNo
aXZlIG92ZXIgdGhlIHdlYiAoTWF5IGJlIHRoZSBJRUVFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IHBhZ2VzIHBvaW50IHRvIHRoZSB3cm9uZyBhZGRyZXNzISk8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IERvZXMgYW55b25l
IGtub3cgd2hvIGltcGxlbWVudCBNb2JpbGUgSVAgaW4gdGhlaXIgcHJvZHVjdHM/IE15IGd1ZXNz
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGlzIHRoYXQgdGhlIHY0IHZlcnNpb24gaXMg
aW1wbGVtZW50ZWQuIERvZXMgYW55b25lIGRvIHY2PyBJcyBhbnlvbmU8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgaW1wbGVtZW50aW5nIHRoZSByb3V0ZSBvcHRpbWl6YXRpb24gZXh0ZW5z
aW9ucz88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IFRoYW5rcyBmb3IgYWxsIHlvdXIgaGVscC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1ZGhhIFJhbWVzaDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRN
TD4NCg==

--0__=xfRYw0adqi4lY2lOglFNAaSZAWPca1fZoDzev0gj17dxhbzpsG68lRsr--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 16:32:16 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13464
	for ; Fri, 16 Mar 2001 16:32:16 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26204;
	Fri, 16 Mar 2001 13:31:12 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16158;
	Fri, 16 Mar 2001 13:30:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GLS9Im011762
	for ; Fri, 16 Mar 2001 13:28:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GLS8CW011761
	for mobile-ip-dist; Fri, 16 Mar 2001 13:28:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GLRuIm011754
	for ; Fri, 16 Mar 2001 13:27:59 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15187
	for ; Fri, 16 Mar 2001 13:27:55 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13994
	for ; Fri, 16 Mar 2001 14:27:54 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26892
	for ; Fri, 16 Mar 2001 13:27:48 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GLRj721737
	for ; Fri, 16 Mar 2001 13:27:45 -0800
X-mProtect:  Fri, 16 Mar 2001 13:27:45 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdRmx2G0; Fri, 16 Mar 2001 13:27:03 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA15984 for ; Fri, 16 Mar 2001 13:27:05 -0800 (PST)
Message-ID: <3AB28529.E94C2C64@iprg.nokia.com>
Date: Fri, 16 Mar 2001 13:27:05 -0800
From: "Jari T. Malinen" 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Hierarchical MIPv6 Requirements
References: <200103161828.KAA19411@heliopolis.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Karim, James,

A more thorough open discussion on the requirements is needed.
I believe bringing the requirements to the open in some sort of
document might clear the picture. There might have been a too
fast jump to the solution space. Requirements, comparing alternative
approaches etc. should be done a bit more widely.

> >Working for Ericsson I am of course interested in spectrum efficiency.
> >However it has been already pointed out that this is probably
> >a ROHC issue, independent of HMIP, and I believe ROHC WG is working
> >on this.

I think this should not preclude spectral efficiency requirement for L3. 
Handling HC context is heavy and looks deep to the packet to determine
the method, if one might conclude something from the big ROHC documents..

> >> In this email, I'd like to bring up an additional requirement. There
> >> has been some discussion about whether or not arbitrary levels of
> >> hierarchy are of value. We recently did a study of using HMIP for
> >> a next generation IP based radio access network, and one of the
> >> issues was supporting arbitrary levels of hierarchy with
> >> minimal (ideally
> >> no) mobile involvement.
> >
> >Can you give reason?
> 
> Yes. In the RAN design we are looking at, there is an upper part
> on which packets are application or user packets. We would like
> to use a hierarchical MIP to implement mobility (what we call
> micromobility, which is different from what Seamoby calls micromobility)
> across this part of the RAN. I can't say more without getting into
> deeper technical details, which I would rather not at the moment.
> The important point is that we would like the mobile to be aware
> of just one level of hierarchy, and there will be hierarchy outside
> the RAN, in the core, if the operator wants to optimize signalling,
> or provide a locally assigned home address.

To understand this more, it might merit a deeper technical discussion
than might be possible under a couple of e-mails or under a slot
in the IETF.

Best Regards,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 18:04:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14571
	for ; Fri, 16 Mar 2001 18:04:53 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22436;
	Fri, 16 Mar 2001 15:04:22 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05285;
	Fri, 16 Mar 2001 15:04:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GN27Im012063
	for ; Fri, 16 Mar 2001 15:02:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GN2693012062
	for mobile-ip-dist; Fri, 16 Mar 2001 15:02:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GN1vIm012055
	for ; Fri, 16 Mar 2001 15:01:58 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15408
	for ; Fri, 16 Mar 2001 15:01:58 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20639
	for ; Fri, 16 Mar 2001 15:01:54 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05541
	for ; Fri, 16 Mar 2001 15:01:53 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GN1qo16053
	for ; Fri, 16 Mar 2001 15:01:52 -0800
X-mProtect:  Fri, 16 Mar 2001 15:01:52 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdOfHvmj; Fri, 16 Mar 2001 15:01:20 PST
Message-ID: <3AB29B41.57798601@cs.ucl.ac.uk>
Date: Fri, 16 Mar 2001 15:01:21 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBC7C@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> >    I would appreiciate if the HMIP authors could shed some light in some statements
> > in the hmipv6-02 draft that got out recently.
> >
> >
> > In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP.
> > The question is which one the home address or the onlink (LCoA)?
> >
>         => Is there an "ACoA" in the draft ? If so it's a typo.
>         I don't really understand your question. In extended mode the mobile
>         node uses the MAP's advertised address as an alternate-CoA, oh I
>         see what you meant by ACOA !
>
>         So I still don't get your last statement. The source address in the
>         IP packets is the LCoA. The address shown to the appliccations
>         is the Home Address. The address that the CN/HA has in their
>         binding cache is the alternate-CoA (MAP's address).
>
>         Have I confused you more ?

Not at all, but let me rephraze. The question is which address would the MN use as its
ACoA, the _home_ address of the MAP _or_ the onlink (LCoA) of the MAP?

>
>
> > If a MAP is serving as a mobile AR you enforce that it must advertise its and all
> > MAP options available. Does that imply that the 'preference' is specific here?
> >
>         => The preference is either configured in the MAP or a default
>         behaviour that varies with loading ...etc.
>         Each MAP can have its own preference value independantly from
>         other MAPs
>

or a default behaviour that varies with loading ...etc.


This is as vague as the statement in the draft...could you elaborate please? In fact
that brings me to a whole new question
with respect to my study of your scheme.

1)There is no mention about how the preference metric is regulated and by what entities.
Is it dynamic or static?

2) Does the preference and distance metric work for different modes? Does one override
the other?

If you have a preference metric and you opt for a map with the lowest preference, then I
feel that your load balancing goes out of the window. All
MN will get the lowest preference and a single MAP is guaranteed to always pick the same
MAP. This is the one with the lowest pref.

What are the reasons imposing preference over distance?



>
> > Further (page 20, top statement) you state that this would allow the MN to obtain a
> > new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA).
> >
>         => We mean RCoA. The RCoA is the address provided by the MAP, regardless
>         of which mode it operates in. So for Basic mode the RCoA is the
>         address that the MN forms on the MAP's subnet. In extended mode
>         the RCoA is the MAP's IP address.
>

No RCoA is provided by MAP... MAP only provides a prefix and does DAD as far as I can
tell from your protocol spec. This is not the same. I think it would be correct to state
in your draft that the ACoA may take two values: an RCoA and the MAP's IP addr (I trust
LCoA). I think this is better and leaves no space for ambiguity.



>
> > The
> > reason I ask here is because you state that in the extended mode the MN is bound to
> > use the mobile AR/MAP IP address.
> >
>         => Yes, this is to make sure it receives packets.
>
> > Also you state that the MN should send a BU to the (further ???) MAP to bind its
> > Home Addr with the MR's CoA.
> >
> >
> > Can you explain why you need to do that? Do you mean
> >
>         => For the same reason you need HMIPv6 at all. Reduce signalling
>         and help speed up the handover by updating a node close
>         to the MN.
>

Objection ! Speculative...If the MR acts as the closest MAP, I fail to see why the MN
should choose the "further" (i.e. higher MAP in the routing hierarchy) so as to register
its home addr and its CoA which is the IP address of the MAP that it has registered with
(ie the closest one :)

In fact that creates exactly the pitfall that you argue against for RegReg: the creation
of a routing hierarchy (two level for a single MR). Consider:
Packets arrive to the "further" MAP; these are decapsulated and the B. Cache find that
needs to send them to the CoA for that MN which (hey...) is..the _next_ MAP (level 1
reached). This MAP will receive the packet and check the routing header to find the
final dest the MN home addr. Encapsulate and send over to MN (level 2 reached). Do you
agree?





>
> > by further, a MAP higher (upstream) in the routing hierarchy?
> >
>         => Yes.
>
> > How can you possibly have location privacy if the upstream packets have as their
> > source address the MNs LCoA.
> >
>         => Which mode are you referring to now ? We don't claim location
>         privacy for Extended mode, but for Basic mode you can use the
>         RCoA as a source address. That's how you get it.
>
> > If you do not have the LCoA as the source address,
> > then start praying over egress filtering.
> >
>         => If I pray, I usually pray for better things ;)

I am glad you do.. :)


>
>         MANY networks don't use it.

Very good assumption...tell that to the service providers, domain admins..... :))


> Anyhow we've dicovered
>         that there is a need for the network to inform the MN
>         whether the use of RCoA is possible or not.
>         We added that in the draft and Claude will post
>         that on the INRIA web page soon.
>

Fine...that however proves that you need to improve your spec further...what I am trying
to say here is that
the solution that each side proposes has got its merits, weaknesses, and may be open to
further improvement (as with anything in life :)

This is to say that RegReg can come up with another autoconfig scheme for the routing
hierarchy that decouples BU signalling and caters for
single points of failures. This can also be expressed as "we are supplying a detailed
supplement to the draft that solves this problem" which is
just as good as your statement. What we need to make sure is understand that everything
comes at a price. Complex protocol and signalling for
really awkward mobility situations that can become the norm, or protocol simplicity for
the base case and addition of optimization that again
bring complications to the signalling design...I cannot see a clear cut choice to any of
the two options.

I feel that the group would benefit infinetely if the specs merge...


>
> > If you have load balancing effected which RCoA do you send back to the HA?
> >
>         => Load balancing is done by the MAP, you only need to send
>         one RCoA to the HA. Did you mean something else ?
>

Well I cannot see the rational behind the load balancing being done by the MAP. Do you
mean that a MAP will elect another MAP to forward encapsulated flows from different CNs.
Each CN needs to have an RCoA to send packets to. Each RCoA is being created by the
MAP prefix, . If an MN needs to register with a MAP, multiple MAPs distribute the
traffic load for a single MN (and as such need to receive traffic for different RCoA),
that means to me that you need two different RCoA. Otherwise please explain to me HOW
the MAP will force CNs to send traffic to another MAP.

Many Thanks

Theo




From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 18:29:08 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14918
	for ; Fri, 16 Mar 2001 18:29:07 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27059;
	Fri, 16 Mar 2001 15:28:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10513;
	Fri, 16 Mar 2001 15:28:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNQYIm012155
	for ; Fri, 16 Mar 2001 15:26:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GNQYMV012154
	for mobile-ip-dist; Fri, 16 Mar 2001 15:26:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNQPIm012147
	for ; Fri, 16 Mar 2001 15:26:25 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAB23281
	for ; Fri, 16 Mar 2001 15:26:26 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00864
	for ; Fri, 16 Mar 2001 15:26:26 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA08845
	for ; Fri, 16 Mar 2001 15:26:25 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2GNQMq22206
	for ; Fri, 16 Mar 2001 15:26:22 -0800
X-mProtect:  Fri, 16 Mar 2001 15:26:22 -0800 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd0YyxEx; Fri, 16 Mar 2001 15:26:08 PST
Message-ID: <3AB2A153.4202E60C@iprg.nokia.com>
Date: Fri, 16 Mar 2001 15:27:15 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mobile-ip@sunroof.eng.sun.com" 
Subject: [mobile-ip] Suggested revisions to HMIPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello folks,

Here are some suggestions about possible revisions to the
HMIPv6 draft that merit consideration.

- Discussion about smooth handovers (e.g., section 10) should
  be deleted.  It is not the purpose of a document about
  localizing binding update delivery to do that.

- Load balancing should not be part of HMIPv6.  It does not
  belong, and the particular methods chosen may need to be
  refined independently of the discussion about localizing
  the delivery of binding updates.  So, for instance, the
  'L' bit should be eliminated.

  So, for instance, we may wish to have load balancing in
  domains that do not implement any regionalized bindings.
  Separation of concerns is important.

- There should be only one kind of care-of address, and it
  should belong to the node which makes the address look
  topologically correct.  Thus, a mobile node SHOULD NOT
  have an address on the MAP's subnet, unless of course
  the mobile node is running applications that appear to
  be attached to that network.

  I think this means that the "basic mode" should be
  deleted.  Even without the abovementioned considerations,
  it is an unnecessary complication to have two modes of
  care-of address management for the mobile node.

- If, as just mentioned, basic mode is deleted, then
  HMIPv6 suggests modifications to the operation of the
  home agent.  These modifications should be avoided.

- MAP advertisements should not have preference values.
  The use of preferences is very fragile in any sort of
  dynamic situation such as is described within the HMIP
  draft.

- Using router renumbering for establishing MAP discovery
  techniques is highly speculative.  Creating a new message
  type greatly diminishes the claim of re-use of existing protocols.

- The 'T' bit for the Neighbor Discovery extension is either
  confusing, or should be eliminated (or both).

- How often does the 'M' bit force the mobile node to re-register
  with its home agent?  Presumably, not every time the
  advertisement is received.

- In section 7, the HA should not be tunneling things to
  the mobile node's site-local address.

- In section 7.3, mention about policy restrictions should
  be deleted.  This would also include discussion about
  authorization.

- Contrary to the statement in section 13.1, there are
  benefits to having multiple "levels" of care-of address
  locality.

- Section 15 should be deleted.

- There should be a very clear statement, perhaps in an
  appendix, about exactly which parts of the protocol
  specification are covered by Ericsson patents.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 18:29:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14962
	for ; Fri, 16 Mar 2001 18:29:29 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27304;
	Fri, 16 Mar 2001 15:29:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23771;
	Fri, 16 Mar 2001 15:28:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNRlIm012165
	for ; Fri, 16 Mar 2001 15:27:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GNRlBZ012164
	for mobile-ip-dist; Fri, 16 Mar 2001 15:27:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNRZIm012157
	for ; Fri, 16 Mar 2001 15:27:35 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by jurassic.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with SMTP id f2GNRXRA468765;
	Fri, 16 Mar 2001 15:27:34 -0800 (PST)
Message-Id: <200103162327.f2GNRXRA468765@jurassic.eng.sun.com>
Date: Fri, 16 Mar 2001 18:27:41 -0500 (EST)
From: Steven Glass - Solaris Software 
Subject: [mobile-ip] Re: A question about DHCP for Mobile IP
To: m0th@dcs.shef.ac.uk
Cc: mobile-ip@sunroof.eng.sun.com
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_11 SunOS 5.8.1 sun4u sparc 
Content-Type: text
X-Sun-Text-Type: ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


>I have a question about the ip address of mobile node. 

    Sure - first pleast note the correct list address is 
mobile-ip@sunroof.eng.sun.com...


>If a mobile node move into a foreign network and use the foreign agent's ip 
address as care-of address,
>should it obtain a local IP address by DHCP? 

    In almost all cases it doesn't have to.  The mobile node registers the FA's 
address as its CoA so the HA has a reachable place one-hop away from the mobile 
node to send the MN's traffic.  The MN would have to get a local [DHCP] address, 
AND use the FAs address as a CoA if the MN wants access to local services as if 
it were local, but the only way it can get off the local link is via the FA (and 
hence the FA SHOULD be setting the 'R' bit).

>Or when the mobile node use co-located address to register to home agent, how 
can the mobile node get 
>a new address when moves to a new foreign network.

   The same way, it just tries to get a new address, registers it, then 
(perhaps) deregisers and "throws away" the old address.


> From the book"Mobile IP", it say that mobile node can use
>any mechanism to detect whether it needs to make a new point of attachment to 
the internet. Then what 
>mechanism available? 

    Either by listening for router or agent advertisements, or [periodically] 
soliciting for them.


>I remember that in win98, you had to reboot your computer after you change your 
IP address. How can it work 
>for the mobile IP if the mobile node had to change its IP address frequently.

    Uh - that would make life really hard, since rebooting likely also brings 
down your current connections (which is one of the reasons we want mobile-ip - 
to leave current connections *UP*), so Microsoft's going to have to fix that, 
aren't they.  Seriously, in mobile ip the home address "never" changes, so all 
that's happenning is the care-of address is changing.  Think about it as the HA 
is proxying for the MN, and the FA is loaning (sharing) its address (as a CoA) 
with the mobile node as a "last-hop" for its traffic, then simply handing it 
over.  The Colocated CoA works in exactly the same way - it's the "last-hop" on 
that link, which happens to be already "inside" the mobile node.

                              Cheers,
                                  Steve


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 18:40:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15294
	for ; Fri, 16 Mar 2001 18:40:46 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15942;
	Fri, 16 Mar 2001 15:38:55 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23845;
	Fri, 16 Mar 2001 15:38:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNbPIm012226
	for ; Fri, 16 Mar 2001 15:37:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2GNbO5r012225
	for mobile-ip-dist; Fri, 16 Mar 2001 15:37:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2GNbGIm012218
	for ; Fri, 16 Mar 2001 15:37:16 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23495
	for ; Fri, 16 Mar 2001 15:37:17 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14602
	for ; Fri, 16 Mar 2001 16:37:15 -0700 (MST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 16 Mar 2001 17:36:37 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 16 Mar 2001 17:36:11 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43018BAF3B@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Fri, 16 Mar 2001 17:36:07 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0AE71.DFE8D750"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AE71.DFE8D750
Content-Type: text/plain;
	charset="iso-8859-1"

Claude,
 
I think you might be right on the TMN . If was thinking there might be some
robustness issues with this unless the home prefix is not used - I'll take
another look and think about it a bit more.
 
BTW - I have already read Cellular IP and the HMIP proposals several times.
Everytime I have time to begin writing down and send suggestions in a clear
and hopefully un-offensive manner - a new version comes out. 
 
Thanks,
 
Glenn

-----Original Message-----
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, March 16, 2001 10:34 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] -HMIPv6 draft + Privacy draft-


Glenn Morrow wrote: 

Claude,In reference to the privacy draft , I do not see the use of it as you
do not try to "solve the problem of privacy of a mobile node from it's
correspondent nodes". You want to hide some information from other nodes
such as location and true identity but by not handling the basic issue with
the CN you have done nothing. For instance, any node in the world can ping
the MN and obtain it's COA because it would then be a CN.

If you want to hide your location to your CN, you can either: 
-use HMIP (in this case you only reveal your RCoA not your CoA) 
- use MIP without route optimization... 
-use Mixes, onion routing... 
-others? 

Anyways you are right, we are not solving this problem in this draft, we are
solving the following one: 


-A MN trusts its CN (because they are both belonging to the same company) 
and is willing to reveal its CoA, however it does not want anybody else (for
example its 
competitor) in the network to know where it is currently located.... 


This is not possible with MIPv6, this is what our draft tries to solve... 
  





Why would someone bother worrying about eavesdropping and sniffing when one
can simply ping the node after a DNS or other lookup?

as I said we make the assumption that a MN only sends BU to CNs it trusts
.... 
  

It seems to me that the recent anonymity extensions to stateless
autoconfiguration will acheive the same functionality as the TMI concept.

not really... with the recent anonymity extensions for stateless auto. you
still reveal your network prefix, you just 
use an interface identifier that is random...in our case the TMI (128 bit)
is completly random.... 

More later on the new HMIP proposal.

this is not a new proposal....just a new version of the old proposal... 

Thanks for the effort, though.Glenn

thanks for your comments... 

  

-----Original Message----- 
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Friday, March 16, 2001 8:06 AM 
To: mobile-ip@sunroof.eng.sun.com 
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Thanks Claude,I'll take a look. I am hoping others will follow suit with
more candidates as well. This location privacy thing is one of the last
"what's missings". I have to say I have found it very uncomfortable going
forward on solutions to other aspects of the problem with this issue
dangling. 

-----Original Message----- 
From: Claude Castelluccia [ mailto:claude.castelluccia@inrialpes.fr
 ] 
Sent: Friday, March 16, 2001 3:48 AM 
To: mobile-ip@sunroof.eng.sun.com 
Subject: [mobile-ip] -HMIPv6 draft + Privacy draft-
Hello, 

We actually have a  (preliminary) draft that tries to tackle the problem of
route optimal location privacy in MIPv6. 
The draft (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from
my web site :
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-p
rivacy-00.txt
  or from the IETF 
ID repository... 


Note also that we have a new version of HMIPv6 (version 3) that clarifies
some aspects of HMIPv6 and 
highlights some of its advantages (see section 6.5 or 6.6 for example). This
new version can be retrieved at: 
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03
.txt
  


comments welcome.... 


regards, 


Claude. 


Glenn Morrow wrote: 


  

Yes - there is no accepted or even tabled proposal yet for route optimal
location privacy. I believe it is a requirement even MIP should strive for
as we move forward. 
  
  


        => True. But the same goes for any IP adderss in the hierarchical 
        IPv6 world. Right ? 


        Hesham

-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
 

-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


------_=_NextPart_001_01C0AE71.DFE8D750
Content-Type: text/html;
	charset="iso-8859-1"









Claude,


 


I 
think you might be right on the TMN . If was thinking there might be 
some robustness issues with this unless the home prefix is not used - I'll take 
another look and think about it a bit more.


 


BTW - 
I have already read Cellular IP and the HMIP proposals several times. Everytime 
I have time to begin writing down and send suggestions in a clear and 
hopefully un-offensive manner - a new version comes out. 



 


Thanks,


 


Glenn



  
-----Original Message-----
From: Claude Castelluccia 
  [mailto:claude.castelluccia@inrialpes.fr]
Sent: Friday, March 16, 
  2001 10:34 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: 
  Re: [mobile-ip] -HMIPv6 draft + Privacy draft-

Glenn 
  Morrow wrote: 
  
Claude,In reference 
    to the privacy draft , I do not see the use of it as you do not try to 
    "solve the problem of privacy of a mobile node from it's correspondent 
    nodes". You want to hide some 
    information from other nodes such as location and true identity but by not 
    handling the basic issue with the CN you have done nothing. For instance, 
    any node in the world can ping the MN and obtain it's COA because it would 
    then be a CN.
If you want to hide your 
  location to your CN, you can either: 
-use HMIP (in this case you only 
  reveal your RCoA not your CoA) 
- use MIP without route optimization... 
  
-use Mixes, onion routing... 
-others? 
  
Anyways you are right, we are not solving this problem in this draft, we 
  are solving the following one: 
  
-A MN trusts its CN (because they are both belonging to the same company) 
  
and is willing to reveal its CoA, however it does not want anybody else 
  (for example its 
competitor) in the network to know where it is currently 
  located.... 
  
This is not possible with MIPv6, this is what our draft tries to solve... 
  
  
  

  
Why would someone bother worrying about eavesdropping and sniffing 
    when one can simply ping the node after a DNS or other 
    lookup?
as I said we make the 
  assumption that a MN only sends BU to CNs it trusts .... 
  
  
It seems to me that the recent 
    anonymity extensions to stateless autoconfiguration will acheive the same 
    functionality as the TMI concept.
not really... with the recent 
  anonymity extensions for stateless auto. you still reveal your network prefix, 
  you just 
use an interface identifier that is random...in our case the TMI 
  (128 bit) is completly random.... 
  
More later on the new HMIP 
    proposal.
this is not a new proposal....just 
  a new version of the old proposal... 
  
Thanks for the effort, 
    though.Glenn
thanks for your comments... 
  
  
    

      
-----Original Message----- 
From: Morrow, Glenn 
      [RICH2:C330:EXCH] 
Sent: Friday, March 16, 2001 8:06 AM 
      
To: 
      mobile-ip@sunroof.eng.sun.com 
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy 
      draft-
Thanks Claude,I'll take a 
      look. I am hoping others will follow suit with more candidates as well. 
      This location privacy thing is one of the last "what's missings". I have 
      to say I have found it very uncomfortable going forward on solutions to 
      other aspects of the problem with this issue 
      dangling. 
      

        
-----Original Message----- 
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr] 
        
Sent: Friday, March 16, 2001 
        3:48 AM 
To: 
        mobile-ip@sunroof.eng.sun.com 
Subject: [mobile-ip] -HMIPv6 draft + Privacy 
        draft-
Hello, 
        
We actually have a  (preliminary) draft that tries to tackle the 
        problem of route optimal location privacy in MIPv6. 
The draft 
        (draft-castelluccia-mobileip-privacy-00.txt) can be retrieved from my 
        web site : http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt 
        or from the IETF 
ID repository... 
        
Note also that we have a new version of HMIPv6 (version 3) that 
        clarifies some aspects of HMIPv6 and 
highlights some of its 
        advantages (see section 6.5 or 6.6 for example). This new version can be 
        retrieved at: 
http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt 

        
comments welcome.... 
        
regards, 
        
Claude. 
        
Glenn Morrow wrote: 
        
  
          
Yes - there is no accepted or even tabled proposal 
          yet for route optimal location privacy. I believe it is a requirement 
          even MIP should strive for as we move forward. 
  
          
  
          
        => 
          True. But the same goes for any IP adderss in the hierarchical 
          
        IPv6 
          world. Right ? 
          
        Hesham
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
 
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  



------_=_NextPart_001_01C0AE71.DFE8D750--


From ronyoung@nortelnetworks.com  Fri Mar 16 19:28:22 2001
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16231
	for ; Fri, 16 Mar 2001 19:28:22 -0500 (EST)
Received: from zrchh190 by smtprch2.nortel.com; Fri, 16 Mar 2001 18:14:55 -0600
Received: from marvin.corpeast.baynetworks.com by zrchh190;
          Fri, 16 Mar 2001 18:17:15 -0600
Received: from ecars003.nortelnetworks.com (zcars01t.ca.nortel.com [47.141.0.117]) 
          by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP 
          id TAA12682 for ;
          Fri, 16 Mar 2001 19:10:41 -0500 (EST)
From: thomas@etri.re.kr
Received: from ecarsbbb.nortelnetworks.com by ecars003.nortelnetworks.com;
          Fri, 16 Mar 2001 19:10:35 -0500
Received: from cms2.etri.re.kr (cms2.etri.re.kr [129.254.16.12]) 
          by ecarsbbb.nortelnetworks.com with SMTP (MailShield v1.5);
          Fri, 16 Mar 2001 19:10:33 -0500
Received: by cms2.etri.re.kr with Internet Mail Service (5.5.2653.19) 
          id ; Sat, 17 Mar 2001 09:10:23 +0900
Received: from thomas (thomas.etri.re.kr [129.254.192.103]) by cms1.etri.re.kr 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id FZ3LNAKN; Sat, 17 Mar 2001 09:11:01 +0900
Reply-To: thomas@etri.re.kr
To: MOBILE-IP@marvin.corpeast.baynetworks.com
Subject: unsubscribe mobile-ip
Date: Sat, 17 Mar 2001 09:13:16 +0900
Message-ID: <001e01c0ae77$10395d30$67c0fe81@thomas>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: 
Importance: Normal
X-SMTP-HELO: cms2.etri.re.kr
X-SMTP-MAIL-FROM: thomas@etri.re.kr
X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
X-SMTP-PEER-INFO: cms2.etri.re.kr [129.254.16.12]
X-Orig: 
X-Orig: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA16231

unsubscribe mobile-ip


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 16 21:25:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17375
	for ; Fri, 16 Mar 2001 21:25:12 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA02787;
	Fri, 16 Mar 2001 18:23:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09173;
	Fri, 16 Mar 2001 18:23:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H2LqIm012553
	for ; Fri, 16 Mar 2001 18:21:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2H2LqI7012552
	for mobile-ip-dist; Fri, 16 Mar 2001 18:21:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2H2LfIm012545
	for ; Fri, 16 Mar 2001 18:21:42 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18795
	for ; Fri, 16 Mar 2001 18:21:42 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03339
	for ; Fri, 16 Mar 2001 18:21:42 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA22578
	for ; Fri, 16 Mar 2001 18:21:42 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2H2LeB19698
	for ; Fri, 16 Mar 2001 18:21:40 -0800
X-mProtect:  Fri, 16 Mar 2001 18:21:40 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdQLki1m; Fri, 16 Mar 2001 18:21:28 PST
Message-ID: <3AB2CA29.31DFF4F5@iprg.nokia.com>
Date: Fri, 16 Mar 2001 18:21:29 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Header Compression overhead in HMIPv6
Content-Type: multipart/mixed; boundary="------------7DE145182F1CF0FB237C228A"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

--------------7DE145182F1CF0FB237C228A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello folks,

I am still catching up with all the discussions surrounding HMIPv6
tunneling and how rohc might be able to support it. 
However, I do have some experience (draft and implementation) on header
compression context relocation during handovers. So, I hope it is ok if
I could make one or two comments.

Context establishment over a low-bandwidth, long latency, error-prone
air interface is expensive. It could take many packets to reliably
establish the context that would allow transitioning to spectrally
efficient state. See the attachment for some details. Thus, there is a
trade-off between the effort needed to establish context versus how long
the flow that uses it actually lasts. In some cases, e.g., with web
traffic, the flow may last as long as only 20 packets, and one has to
weigh the benefit of establishing, maintaining and garbage collecting
context state for flows that come and go. I would think that even if
[rohc] provides mechanisms to compress/decompress tunneled packets,
there is clearly a trade-off to consider. At the very least, if a
solution requires support from [rohc] or anything else for spectral
efficiency, it has to be clearly identified and stated. 

Regards,

-Rajeev

--------------7DE145182F1CF0FB237C228A
Content-Type: message/rfc822
Content-Disposition: inline

Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20603;
	Fri, 16 Mar 2001 17:46:02 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2H1k2732414;
	Fri, 16 Mar 2001 17:46:02 -0800
Received: from mailigned.iprg.nokia.com (205.226.0.203)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd4DnaMe; Fri, 16 Mar 2001 17:45:49 PST
Received: (from root@localhost)
	by mailigned.iprg.nokia.com (8.11.0/8.11.0-WTS) id f2H2oi105623;
	Fri, 16 Mar 2001 18:50:44 -0800
Received: from c900656-a.plstn1.sfba.home.com (24.20.167.220, claiming to be "charizard.diameter.org")
	by -={Mailigned}=-(WTS.12.69) smtpdfMqroF; Fri, 16 Mar 2001 18:50:44 PST
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.11.3/8.11.3) id f2H1T3M11286
	for seamoby-list; Fri, 16 Mar 2001 17:29:03 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f2H1T1F11281
	for ; Fri, 16 Mar 2001 17:29:01 -0800
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA15668;
	Fri, 16 Mar 2001 16:37:29 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2H0bRw27638;
	Fri, 16 Mar 2001 16:37:27 -0800
X-mProtect:  Fri, 16 Mar 2001 16:37:27 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdPJB9Qw; Fri, 16 Mar 2001 16:37:19 PST
Message-ID: <3AB2B1C0.59E2B600@iprg.nokia.com>
Date: Fri, 16 Mar 2001 16:37:20 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: kempf@heliopolis.Eng.Sun.COM
CC: seamoby@diameter.org
Subject: [seamoby] [Fwd: Revised HC Relocation statement]
Content-Type: multipart/mixed; boundary="------------FF6D5DF3F54BC7E1CFBAE39"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

--------------FF6D5DF3F54BC7E1CFBAE39
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello James,

here is the posting to CT list that might be of interest to you. 

A deduction from this analysis is that header compression context
initialization is an expensive process in certain links. Thus, there is
a trade-off between the benefit it offers versus how long-lived the flow
is. If you have to do it for web traffic for example, some flow may live
as long as only 20 packets. So, you would have to weigh the overhead
versus the longevity of the flow.

Best Regards,

-Rajeev

--------------FF6D5DF3F54BC7E1CFBAE39
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <3A708D5C.33590565@iprg.nokia.com>
Date: Thu, 25 Jan 2001 12:32:28 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: seamoby_context@standards.nortelnetworks.com
CC: rajeev@iprg.nokia.com
Subject: Revised HC Relocation statement
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello folks,

following is a revised version. 

PatC, the co-chair: I wish to register a complaint that I can post
messages to this group, but I cannot see them myself! Any positive
action would be appreciated.

Regards,

-Rajeev


Header Compression (HC) Context Relocation
------------------------------------------

Compression of IP and transport layer headers is crucial over
low-bandwidth links in order to achieve efficient utilization of the
link capacity to deliver useful payload to applications. This header
compression involves maintaining state (context) information on the
network
periphery and the terminal and operating according to well-defined
protocol. When terminal mobility is involved, relocation of the
compression context(s) is needed in order to avoid surges in bandwidth
consumption associated with compression context re-establishment, which
causes interruptions to the smooth delivery real-time packets. This
overhead can be avoided, and thus the seamless operation of header
compression facilitated, by a simple transfer of context variables
from an access router's compression engine to that of the terminal's
new access router. 


The following terminology is used in describing the need for header
compression context relocation.

Full Header (FH) packet: Contains the full IP and transport protocol
headers,
plus the HC-specific fields

First Order (FO) [packet]: Contains only those fields that change from
packet to packet (e.g. RTP timestamp), and does not contain fields
that do not change at all.

Second Order (SO): Contains HC-specific header and sequence number. The
rest of the fields are constructed from the sequence number info and
the information maintained by the decompressor.

Problem Statement
-----------------
The motivation for HC context relocation is best understood by
examining the typical header compression operation.

A compressor starts by sending Full Header (FH) packets with HC-specific
headers in them and waits for few of the FHs to be reliably propagated
(e.g., ACK-based or 'n' number of headers transmitted). Note that in
bandwidth-constrained links, the link latency as well as higher error
probabilities could force the transmission of many FHs before confirming
reliable propagation of header information. Similarly, many FO packets
are sent before confirming that transition to the SO state is possible.
This process of "reference state" establishment is expensive. E.g., on a
60 ms cellular link and with 20 ms packetization for voice, it would
take 6 FHs (assuming no errors and dropped packets) to establish the FH
state
that allows transition to FO, and 6 more FOs to establish the
FH+FO reference state that allows transition to SO state. The total
overhead is thus 240 ms plus the processing overhead associated with
the header compression operation. Perhaps a value of 300 ms may be
deemed typical. Since this context establishment needs to be
done for each unidirectional packet stream, the overhead gets
worse with multiple packets streams belonging to the same mobile node
(approximately 600 ms for bidirectional voice).
When Mobile IPv6 is used with Home Address option, FH = 84 bytes
(excluding HC-specific fields) for a payload of about 20-30 bytes, and
FO could be 8 bytes. In comparison, the overhead is 1 byte when
operating in the SO state. 

The expensive overheads associated with context re-establishment can be
avoided by relocating the appropriate context between access routers.
For each type of compression mechanism used (e.g.,IPv6/UDP/RTP, IPv6
only, IPv6/TCP wtc), a Compression Profile Type (CPT) identifies the
particular type, and defines the state variables. Thus, the combination
of CPT, and the associated state variables (along with a suitable
identifier) constitutes the context for transfer purpose. This transfer
(presumably) occurs synchronously with handover signaling associated
with terminal mobility.

--------------FF6D5DF3F54BC7E1CFBAE39--


--------------7DE145182F1CF0FB237C228A--



From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 17 08:54:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06552
	for ; Sat, 17 Mar 2001 08:54:05 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10349;
	Sat, 17 Mar 2001 05:52:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05414;
	Sat, 17 Mar 2001 05:52:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HDp3Im013127
	for ; Sat, 17 Mar 2001 05:51:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HDp3AW013126
	for mobile-ip-dist; Sat, 17 Mar 2001 05:51:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HDosIm013119
	for ; Sat, 17 Mar 2001 05:50:54 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05355
	for ; Sat, 17 Mar 2001 05:50:55 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06390
	for ; Sat, 17 Mar 2001 05:50:54 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id OAA12630
	for ; Sat, 17 Mar 2001 14:50:53 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id OAA04763
	for ; Sat, 17 Mar 2001 14:49:50 +0100 (MET)
Message-ID: <3AB36B7E.5ED4D0CB@inrialpes.fr>
Date: Sat, 17 Mar 2001 14:49:50 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Suggested revisions to HMIPv6
References: <3AB2A153.4202E60C@iprg.nokia.com>
Content-Type: multipart/alternative;
 boundary="------------B7D2123BB549C3C57BF8BF36"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------B7D2123BB549C3C57BF8BF36
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello Charlie,

Charlie Perkins wrote:

> Hello folks,
>
> Here are some suggestions about possible revisions to the
> HMIPv6 draft that merit consideration.
>
> - Discussion about smooth handovers (e.g., section 10) should
>   be deleted.  It is not the purpose of a document about
>   localizing binding update delivery to do that.
>

I don't understand why? Why don't you need to worry about smooth
handovers between MAPs? We actually usually standard MIP mechanisms..
this section just clarifies how to use it in the context of HMIPv6....
we should
keep it...

>
> - Load balancing should not be part of HMIPv6.  It does not
>   belong, and the particular methods chosen may need to be
>   refined independently of the discussion about localizing
>   the delivery of binding updates.  So, for instance, the
>   'L' bit should be eliminated.
>
>   So, for instance, we may wish to have load balancing in
>   domains that do not implement any regionalized bindings.
>   Separation of concerns is important.
>

you are right but HMIPv6 (because of the MAP makes it easier
and more efficient....

>
> - There should be only one kind of care-of address, and it

why ? we propose 2 kinds of CoA for different purposes/applications....
Both modes have their own pros and cons (see section 8 for more
details...)..

>
>   should belong to the node which makes the address look
>   topologically correct.  Thus, a mobile node SHOULD NOT
>   have an address on the MAP's subnet, unless of course
>   the mobile node is running applications that appear to
>   be attached to that network.
>

why? Why can't you use an address belonging to the MAP's subnet?

Could you be more specific and give technical reasons...

>
>   I think this means that the "basic mode" should be
>   deleted.  Even without the abovementioned considerations,
>   it is an unnecessary complication to have two modes of
>   care-of address management for the mobile node.
>

both modes are very useful as explained in the draft...if you remove one
of the
modes you just weaken the proposal...unless you give us valid technical
reasons I
will suggest to keep both modes...

>

> - How often does the 'M' bit force the mobile node to re-register
>   with its home agent?  Presumably, not every time the
>   advertisement is received.
>

of course not..only once and then periodically like in MIPv6...

>
> - Section 15 should be deleted.
>

In the last version of the draft, Section 15 is the acknowledgements
session...
do you actually mean to delete it ;-)

>
> - There should be a very clear statement, perhaps in an
>   appendix, about exactly which parts of the protocol
>   specification are covered by Ericsson patents.

I'll let Hesham or Karim answer this point...

Thanks Charlie for your comments eventhough I am not convinced about
their
technical validity (or you need to be more precise ...) ...

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------B7D2123BB549C3C57BF8BF36
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello Charlie,

Charlie Perkins wrote:

Hello folks,

Here are some suggestions about possible revisions to the

HMIPv6 draft that merit consideration.

- Discussion about smooth handovers (e.g., section 10) should

  be deleted.  It is not the purpose of a document about

  localizing binding update delivery to do that.

 

I don't understand why? Why don't you need to worry about smooth

handovers between MAPs? We actually usually standard MIP mechanisms..

this section just clarifies how to use it in the context of HMIPv6....
we should

keep it...

 

- Load balancing should not be part of HMIPv6.  It does not

  belong, and the particular methods chosen may need to be

  refined independently of the discussion about localizing

  the delivery of binding updates.  So, for instance, the

  'L' bit should be eliminated.

  So, for instance, we may wish to have load balancing in

  domains that do not implement any regionalized bindings.

  Separation of concerns is important.

 

you are right but HMIPv6 (because of the MAP makes it easier

and more efficient....

 

- There should be only one kind of care-of address, and it

why ? we propose 2 kinds of CoA for different purposes/applications....

Both modes have their own pros and cons (see section 8 for more details...)..

 

  should belong to the node which makes the address look

  topologically correct.  Thus, a mobile node SHOULD NOT

  have an address on the MAP's subnet, unless of course

  the mobile node is running applications that appear to

  be attached to that network.

 

why? Why can't you use an address belonging to the MAP's subnet?

Could you be more specific and give technical reasons...

 

  I think this means that the "basic mode" should be

  deleted.  Even without the abovementioned considerations,

  it is an unnecessary complication to have two modes of

  care-of address management for the mobile node.

 

both modes are very useful as explained in the draft...if you remove one
of the

modes you just weaken the proposal...unless you give us valid technical
reasons I

will suggest to keep both modes...

 



- How often does the 'M' bit force the mobile node
to re-register

  with its home agent?  Presumably, not every time the

  advertisement is received.

 

of course not..only once and then periodically like in MIPv6...

 

- Section 15 should be deleted.

 

In the last version of the draft, Section 15 is the acknowledgements session...

do you actually mean to delete it ;-)

 

- There should be a very clear statement, perhaps in an

  appendix, about exactly which parts of the protocol

  specification are covered by Ericsson patents.

I'll let Hesham or Karim answer this point...

Thanks Charlie for your comments eventhough I am not convinced about
their

technical validity (or you need to be more precise ...) ...

regards,

Claude.

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------B7D2123BB549C3C57BF8BF36--



From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 17 14:04:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08617
	for ; Sat, 17 Mar 2001 14:04:14 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18215;
	Sat, 17 Mar 2001 11:03:45 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28871;
	Sat, 17 Mar 2001 11:03:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HJ2NIm013327
	for ; Sat, 17 Mar 2001 11:02:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HJ2NZw013326
	for mobile-ip-dist; Sat, 17 Mar 2001 11:02:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HJ2EIm013319
	for ; Sat, 17 Mar 2001 11:02:14 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28813
	for ; Sat, 17 Mar 2001 11:02:14 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA03244
	for ; Sat, 17 Mar 2001 11:02:14 -0800 (PST)
Message-Id: <200103171902.LAA03244@heliopolis.Eng.Sun.COM>
Date: Sat, 17 Mar 2001 11:02:14 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BCHPJen6uePa58Lx8R7M4A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

>This is to say that RegReg can come up with another autoconfig scheme for the 
routing
>hierarchy that decouples BU signalling and caters for
>single points of failures. This can also be expressed as "we are supplying a 
detailed
>supplement to the draft that solves this problem" which is
>just as good as your statement. What we need to make sure is understand that 
everything
>comes at a price. Complex protocol and signalling for
>really awkward mobility situations that can become the norm, or protocol 
simplicity for
>the base case and addition of optimization that again
>bring complications to the signalling design...I cannot see a clear cut choice 
to any of
>the two options.
>
>I feel that the group would benefit infinetely if the specs merge...
>

I'd like to second this.

But first, I think there needs to be some agreement on requirements.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 17 18:58:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10457
	for ; Sat, 17 Mar 2001 18:58:10 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05750;
	Sat, 17 Mar 2001 15:57:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03266;
	Sat, 17 Mar 2001 15:57:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HNuOIm013747
	for ; Sat, 17 Mar 2001 15:56:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2HNuN6v013746
	for mobile-ip-dist; Sat, 17 Mar 2001 15:56:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.88.31])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2HNuFIm013739
	for ; Sat, 17 Mar 2001 15:56:15 -0800 (PST)
Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247])
	by jurassic.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with SMTP id f2HNuFBM564522
	for ; Sat, 17 Mar 2001 15:56:16 -0800 (PST)
Message-Id: <200103172356.f2HNuFBM564522@jurassic.eng.sun.com>
Date: Sat, 17 Mar 2001 15:54:01 -0800 (PST)
From: Alper Yegin 
Subject: [mobile-ip] rfc3012 question
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: glWEhOSIbh2fNpcGanW5eQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello,

I have a question about how FA can keep track of valid challenge values.

As I understand, FA keeps track of valid challenges by noting the challenge 
values sent in multicast/broadcast RAs (these are global, received by all MNs), 
and challenge values sent to individual MNs.

It's easy to keep track of challenge values, when they are sent in a 
registration reply. MN's identity is the key.

But, when challenge values are sent in unicast RAs in response to RS, how can FA 
keep track of these? FA wouldn't know the identity of the MN. There's no NAI in 
RS. And the source address of the RS doesn't have to be home address.


If the solicited RA is sent multicast/broadcast, then since there can be too 
many MNs sending RS, this would fill up the CHALLENGE_WINDOW very quickly and 
create unnecessary rejections.

Unless I'm missing something, this seems like a problem.

alper



From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 18 01:16:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15598
	for ; Sun, 18 Mar 2001 01:16:27 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08134;
	Sat, 17 Mar 2001 22:10:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19893;
	Sat, 17 Mar 2001 22:10:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I68XIm014005
	for ; Sat, 17 Mar 2001 22:08:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2I68X0j014004
	for mobile-ip-dist; Sat, 17 Mar 2001 22:08:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I68IIm013997
	for ; Sat, 17 Mar 2001 22:08:22 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10090
	for ; Sat, 17 Mar 2001 22:08:17 -0800 (PST)
Received: from mailbreak.com ([216.207.225.170])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12686
	for ; Sat, 17 Mar 2001 23:08:16 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for ; Sun, 18 Mar 2001 01:07:44 -0500
Message-ID: <016201c0af72$39111fd0$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" 
To: 
Cc: "Eunsoo Shim" 
References: <200103171902.LAA03244@heliopolis.Eng.Sun.COM>
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
Date: Sun, 18 Mar 2001 01:11:07 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I also think that agreed requirements will help developing the  protocol
tremendously.
Unfortunately I don't know all the detailed history of the WG and thus I
don't know what requirements were used as the base for the existing drafts.
I'd like to list several requirements that seem to me a sort of minimal
ones.

1) Localizing signaling for intra-domain handoffs
- Minimizing signaling traffic to HA or CN for intra-domain handoffs
2) Minimizing overhead on air-interface and MN
3) Reliability
- Capability to provide connectivity continously to existing or new MNs
visiting the domain in the case of intermediate node failures
(the intermedia node would be MAP, GFA, RFA, etc.)
4) Minimizing service disruption period in the case of intermediate node
failures
5) Scalability
6) Security

I'd like to point several issues for each proposal (RR, HMIP).

RR:
It has been pointed out that the existing RR draft has a serious problem in
reliability.
I read in multiple emails that there could be a solution for relaibility for
the RR proposal as a kind of dynamic configuration protocol.
I'd appreciate if the protocol is presented.
I'd like to add that actually we proposed a solution recently (Reliable and
Scalable Mobile IP Regional Registration) if it could be helpful at all.
I read some people are interested in applying IPv6 anycast for RR. I will
have to think about how it helps reliability of RR for MIPv6. Anyway I still
wonder about RR for MIPv4. What kind of solution is being pursued by the
authors of the draft?

HMIP:
In my understanding, the HMIP proposal allows redundant or multiple MAPs
covering a certain spot (or cell). I see several issues in HMIP regarding
it. I assume a MN registers with only a MAP at a time.
- Overhead to the air-interface due to MAP option advertisement
As the number of MAPs increase, the overhead becomes larger.
- Overhead to the MN
MN needs to monitor the MAP option advertisement continously to know whether
the MAP is alive even when the MN has not moved its location
- Connectivity recovery time
The MN needs to wait for the MAP option advertisements and then do
re-registration to a new MAP, HA and/or CN. The MN should know the MAP
option advertisement period and wait for a certain timeout period to find
out the failure of the MAP. Obviously the advertisement period is related to
the overhead to the air-interface and thus it is not easy to reduce the
period.

I'd appreciate any answer or correction on my understanding of the drafts.

Eunsoo

----- Original Message -----
From: "James Kempf" 
To: 
Sent: Saturday, March 17, 2001 2:02 PM
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6


> >This is to say that RegReg can come up with another autoconfig scheme for
the
> routing
> >hierarchy that decouples BU signalling and caters for
> >single points of failures. This can also be expressed as "we are
supplying a
> detailed
> >supplement to the draft that solves this problem" which is
> >just as good as your statement. What we need to make sure is understand
that
> everything
> >comes at a price. Complex protocol and signalling for
> >really awkward mobility situations that can become the norm, or protocol
> simplicity for
> >the base case and addition of optimization that again
> >bring complications to the signalling design...I cannot see a clear cut
choice
> to any of
> >the two options.
> >
> >I feel that the group would benefit infinetely if the specs merge...
> >
>
> I'd like to second this.
>
> But first, I think there needs to be some agreement on requirements.
>
> jak
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 18 01:24:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16674
	for ; Sun, 18 Mar 2001 01:24:06 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11440;
	Sat, 17 Mar 2001 22:22:15 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20252;
	Sat, 17 Mar 2001 22:22:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I6KHIm014040
	for ; Sat, 17 Mar 2001 22:20:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2I6KH1o014039
	for mobile-ip-dist; Sat, 17 Mar 2001 22:20:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2I6K8Im014031
	for ; Sat, 17 Mar 2001 22:20:08 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20192
	for ; Sat, 17 Mar 2001 22:20:07 -0800 (PST)
Received: from mailbreak.com ([216.207.225.170])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17453
	for ; Sat, 17 Mar 2001 23:20:06 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for ; Sun, 18 Mar 2001 01:19:08 -0500
Message-ID: <017b01c0af73$d0ac8180$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" 
To: 
Cc: "Eunsoo Shim" 
References: 
Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
Date: Sun, 18 Mar 2001 01:22:31 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

It seems to me the draft covers the following cases:
1) The old FA(or AR) knows the IP address of the new FA while the MN is
attached to the old FA.
2) The old BS knows the L2 address of the new BS while the MN is attached to
the old BS
3) The new FA knows the IP address of the old FA before the MN registers
with the new FA (reactive case)

I wonder whether these cases are all we need to cover in the wireless IP
world.
In particular, what is the solution for a fast handoff that results in a
similar latency to NAMONC in the case where the assumptions of 1) and 2) are
not vaild?

Regards,

Eunsoo

----- Original Message -----
From: "Karim El-Malki (ERA)" 
To: ; "'Koichi Ishibashi'"

Sent: Friday, March 09, 2001 1:19 PM
Subject: RE: [mobile-ip] Fast Handoffs (IPv4 & IPv6)


> Hello
>
> > Here, I am confusing.
> > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip-
> > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff.
>
> Low latency Handoffs proposes two methods:
>
> - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
> - Network Initiated, Mobile Terminated (NIMOT) Handoff
>
> This is the combination of two existing drafts.
> The first method comes from draft-elmalki-mobileip-fast-handoffs-03
> and the second is from draft-calhoun-mobileip-proactive-fa-03.
>
> > In this draft, the Registration procedure will be done pro-actively.
> > On the other hand, the fast handoff for Mobile IPv6 draft proposes
> > another mechanism.
>
> The v4 and v6 drafts do not propose completely different mechanisms.
> You can run a similar handoff procedure in v4 and v6. However you may
> be pointing to a NIMOT-like approach in v6?
>
> > And I have another confusion.
> > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff)
> > without the bi-casting, the loss of packets during the transition
> > between networks will be eliminated.
>
> If you don't use bicasting (independently of the method supported) then
> achieving a loss-less v4 handoff depends on when the MN actually
disconnects
> from the old FA and connects to the new one, if buffering is available
etc.
> This needs more looking into and hopefully we'll get some discussion going
> at this IETF.
>
> Regards
> /Karim
>




From ronyoung@nortelnetworks.com  Sun Mar 18 16:52:58 2001
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10907
	for ; Sun, 18 Mar 2001 16:52:58 -0500 (EST)
Received: from zrchh190 by smtprch2.nortel.com; Sun, 18 Mar 2001 09:00:47 -0600
Received: from marvin.corpeast.baynetworks.com by zrchh190;
          Sun, 18 Mar 2001 09:02:25 -0600
Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) 
          by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP 
          id JAA25761 for ;
          Sun, 18 Mar 2001 09:46:21 -0500 (EST)
Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t;
          Sun, 18 Mar 2001 09:45:19 -0500
Received: from by.genie.uottawa.ca ( [137.122.20.226]) by 
          with SMTP (MailShield v1.5); Sun, 18 Mar 2001 09:47:07 -0500
Received: from mobstar ([137.122.107.157]) by by.genie.uottawa.ca (8.9.1/8.9.1) 
          with SMTP id JAA18604; Sun, 18 Mar 2001 09:27:24 -0500 (EST)
Reply-To: karmouch 
From: Ahmed Karmouch 
To: karmouch 
Subject: IEEE/ACM Workshop on Mobile Software Agents- MATA 2001- Deadline-April 
         1.
Date: Sun, 18 Mar 2001 00:20:25 -0500
Message-ID: <001f01c0ad2a$7563cb80$9d6b7a89@uottawa.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-UIDL: ae345eaa9c07da9d4d3b9ea7fdaf9c90
Importance: Normal
X-MIME-Autoconverted: from 8bit to quoted-printable by by.genie.uottawa.ca id 
                      JAA18604
X-SMTP-HELO: by.genie.uottawa.ca
X-SMTP-MAIL-FROM: Karmouch@site.uottawa.ca
X-SMTP-RCPT-TO: nseddigh@nortelnetworks.com,mobile-ip@standards.nortelnetworks.com
X-SMTP-PEER-INFO: [137.122.20.226]
X-Orig: 
X-Orig: 
X-Orig: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10907


[My apologies if you receive this more than once]
======================================================
			MATA'2001

  Third International Workshop on Mobile Agents for
	Telecommunication Applications
	August 14-16, 2001, Montréal, CANADA
	  Co-sponsored by IEEE and ACM
	http://www.congresbcu.com/mata01/


CALL FOR PAPERS
================
Technical papers (4500 words maximum) describing previously unpublished,
completed research or work in progress, not currently under review by
another journal or conference, are solicited on the following topics:
Mobile Agent Architecture and Models
Agent Identification, Tracking and Persistence
Agent-based Mobility Management in Mobile Networks
Web Agent Systems
Agent Integration with CORBA and TINA
Active Networks and Mobile Agents
Feature Interaction and Agents
Mobile Agents Communication Language
Security in Mobile Agent Systems
Interactive Multimedia Presentation Agents
Agent-based Electronic Commerce
Agent-based Access to Legacy Services
Managing QoS with agents
Information Discovery and Gathering using agents
Data Mining Agents
Network Management Agents
Policy-based Management using Mobile Agents
Education and Applications of Mobile Agents
Prototypes and Experience with Mobile Agents
Seamless Messaging and Mobile Agents

Accepted papers will be published in the conference proceedings. Papers of
particular merit will be proposed for publication in IEEE Network  Magazine.
All paper submissions should have a cover page containing the title, names,
email address and complete postal addresses (including telephone and fax
numbers) for all authors. Please indicate the main author for the purpose of
correspondence. The cover page should also provide an abstract (150 words
maximum), and a list of keywords. Please include a statement stating that
"when accepted, one of the authors will attend the Workshop to present the
paper".
Submissions should be sent by email to the program chair:

Roch Glitho
Ericcson Research Canada
8400, boul. Décarie
Ville Mont-Royal, Québec, Canada, H4P 2N2
email: roch.glitho@lmc.ericsson.se
Tel.: (514) 345-7000 ext. 2266

IMPORTANT DATES FOR PAPER SUBMISSION
Full paper submission due	April 1, 2001
Notification of acceptance	May 15, 2001
Final paper due	June 15, 2001
=======================================








From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 18 21:01:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13795
	for ; Sun, 18 Mar 2001 21:01:07 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25895;
	Sun, 18 Mar 2001 18:00:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09593;
	Sun, 18 Mar 2001 18:00:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J1wrIm015386
	for ; Sun, 18 Mar 2001 17:58:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2J1wr2u015385
	for mobile-ip-dist; Sun, 18 Mar 2001 17:58:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J1wiIm015378
	for ; Sun, 18 Mar 2001 17:58:44 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09474
	for ; Sun, 18 Mar 2001 17:58:44 -0800 (PST)
From: wjkim@samsung.com
Received: from ms.samsung.com ([211.45.29.136])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24412
	for ; Sun, 18 Mar 2001 17:58:43 -0800 (PST)
Received: from metro ([203.241.48.20]) by ms.samsung.com
          (Netscape Messaging Server 4.15) with SMTP id GAF9CY00.KWY for
          ; Mon, 19 Mar 2001 10:55:46 +0900 
Message-ID: <002401c0b017$56130f80$13e0d5a5@telecom.samsung.co.kr>
To: 
References: <88256A11.00727F9F.00@hqoutbound.ops.3com.com>
Subject: Re: [mobile-ip] Re: [MOBILE-IP] Who implements MIP?
Date: Mon, 19 Mar 2001 10:53:03 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f2J1wjIm015379
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Sorry for the mistake. Obviously I've was short on info. But my comments / answers to some of the items below.



> The closest is the 2.5G cdma2000 1xRTT systems that are currently in
> commercial service in Korea (as I am sure you are aware), but even they do
> not have any commercial mobile IP terminals.
> 
> pdn>The above statement is false.

The false part is my statement that cdma2000 is the closest service to commercially deploying MIP. Obviously there seems to be other systems besides the cdma2000 systems that implement MIP.
The true part is that so far for cdma2000 there is no MIP capable terminals that I am aware of in Korea or the US.  

> 
> It would help if (as numerous people have said) if Microsoft would get
> around to really supporting Mobile IP v4 / v6 in their OS ...
> 
> pdn>I am curious about the above comment.  How would this really help MIP?
> pdn>I guess I am trying to visualize the use cases that would be served that
> pdn>are not served now.
> 

What I was pointing out that in many cases people are expected (at least in Korea) to use notebook PCs connected to their wireless phones. While such a configuration would be hard to carry around (thereby reducing cases of handoff between FAs) it would be a useful for other cases such as the ability to do push service and instant messaging. Currently the limited availability of commercial MIP implementations for Windows notebooks limits its use in the Korean cdma2000 markets.

I would think that this may be the case for US market users as well. Would someone enlighten me on the implementations / services offered by the NexTel and Sprint networks ? 

thanks

Woojune Kim


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 02:15:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04231
	for ; Mon, 19 Mar 2001 02:15:35 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05076;
	Sun, 18 Mar 2001 23:11:47 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04535;
	Sun, 18 Mar 2001 23:11:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J7AUIm015853
	for ; Sun, 18 Mar 2001 23:10:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2J7AU9S015852
	for mobile-ip-dist; Sun, 18 Mar 2001 23:10:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2J7ALIm015845
	for ; Sun, 18 Mar 2001 23:10:21 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24952
	for ; Sun, 18 Mar 2001 23:10:22 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22804
	for ; Sun, 18 Mar 2001 23:10:21 -0800 (PST)
Received: from FRED-W2K.cisco.com (sj-dial-4-33.cisco.com [171.68.181.162])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA19288;
	Sun, 18 Mar 2001 23:10:36 -0800 (PST)
Message-Id: <5.0.2.1.2.20010318083035.02691c50@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 18 Mar 2001 10:35:18 -0800
To: mobile-ip@sunroof.eng.sun.com
From: Fred Baker 
Subject: Re: [mobile-ip] Question to Chairs re: QoS
Cc: mobile-ip@sunroof.eng.sun.com, Dave Oran ,
        rcoltun@redback.com
In-Reply-To: <15024.9028.54884.980740@thomasm-u1.cisco.com>
References: 
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

At 06:04 PM 3/14/2001 -0800, Michael Thomas wrote:
>Question to the AD's and Chairs: does MIP WG
>include in its charter the task of recreating RSVP
>just because at first blush it's not clear how
>RSVP will interact with MIP?

Dumb question of the month - would RSVP not follow the source/destination 
routes involved, and potentially impose a reservation for the tunnel in 
question? The real problems should relate to service surrounding a change 
in COA or FA; one presumably is forced to trigger a reservation 
installation for the new route which may involve a temporary disruption 
surrounding a route which is already in place. One would like to re-use the 
reservation in place for the old to support the new route, up to the point 
where the two routes differ.

This is not dissimilar to the behavior of RSVP-TE for MPLS, in switching 
over between bandwidth-guaranteed routes. I should think we could re-use 
the concepts applied there.



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 07:57:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09769
	for ; Mon, 19 Mar 2001 07:57:42 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14254;
	Mon, 19 Mar 2001 04:54:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21817;
	Mon, 19 Mar 2001 04:54:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JCr4Im016205
	for ; Mon, 19 Mar 2001 04:53:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JCr4h9016204
	for mobile-ip-dist; Mon, 19 Mar 2001 04:53:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JCqsIm016197
	for ; Mon, 19 Mar 2001 04:52:55 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA15719
	for ; Mon, 19 Mar 2001 13:52:49 +0100 (MET)
Date: Mon, 19 Mar 2001 12:52:39 +0000 (PST)
From: Erik Nordmark 
Subject: Re: [mobile-ip] Hierarchical MIPv6 Requirements
To: mobile-ip@sunroof.eng.sun.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> One of our requirements is that it shall be possible to support
> multiple levels of hierarchy with minimal (ideally no) mobile involvement.

James,

While I understand the basis for your requirement to minimize (header) overhead
on the radio link, I don't understand the basis for the multiple levels of
hirarchy.

Can you enlighten me,

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 11:25:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14387
	for ; Mon, 19 Mar 2001 11:25:02 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07338;
	Mon, 19 Mar 2001 08:18:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13458;
	Mon, 19 Mar 2001 08:18:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGGNIm016510
	for ; Mon, 19 Mar 2001 08:16:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JGGNpC016509
	for mobile-ip-dist; Mon, 19 Mar 2001 08:16:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGGEIm016502
	for ; Mon, 19 Mar 2001 08:16:14 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28035;
	Mon, 19 Mar 2001 08:16:14 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA13679;
	Mon, 19 Mar 2001 08:16:09 -0800 (PST)
From: James Kempf 
Message-Id: <200103191616.IAA13679@heliopolis.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 10:15:07 -0700
To: , 
Cc: "Eunsoo Shim" 
Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Eunsoo,

There was never any intent for each solution to cover all cases. So, if
the particular link layer does not provide a source trigger at the
old FA or a trigger on the mobile node, then the NAMONC solution would
not be used. Similarly, if no source trigger is available on the old FA 
and no target trigger is available on the new FA, then the NIMOT solution
would not be used.

		jak

>It seems to me the draft covers the following cases:
>1) The old FA(or AR) knows the IP address of the new FA while the MN is
>attached to the old FA.
>2) The old BS knows the L2 address of the new BS while the MN is attached to
>the old BS
>3) The new FA knows the IP address of the old FA before the MN registers
>with the new FA (reactive case)
>
>I wonder whether these cases are all we need to cover in the wireless IP
>world.
>In particular, what is the solution for a fast handoff that results in a
>similar latency to NAMONC in the case where the assumptions of 1) and 2) are
>not vaild?
>
>Regards,
>
>Eunsoo
>
>----- Original Message -----
>From: "Karim El-Malki (ERA)" 
>To: ; "'Koichi Ishibashi'"
>
>Sent: Friday, March 09, 2001 1:19 PM
>Subject: RE: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
>
>
>> Hello
>>
>> > Here, I am confusing.
>> > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip-
>> > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff.
>>
>> Low latency Handoffs proposes two methods:
>>
>> - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
>> - Network Initiated, Mobile Terminated (NIMOT) Handoff
>>
>> This is the combination of two existing drafts.
>> The first method comes from draft-elmalki-mobileip-fast-handoffs-03
>> and the second is from draft-calhoun-mobileip-proactive-fa-03.
>>
>> > In this draft, the Registration procedure will be done pro-actively.
>> > On the other hand, the fast handoff for Mobile IPv6 draft proposes
>> > another mechanism.
>>
>> The v4 and v6 drafts do not propose completely different mechanisms.
>> You can run a similar handoff procedure in v4 and v6. However you may
>> be pointing to a NIMOT-like approach in v6?
>>
>> > And I have another confusion.
>> > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff)
>> > without the bi-casting, the loss of packets during the transition
>> > between networks will be eliminated.
>>
>> If you don't use bicasting (independently of the method supported) then
>> achieving a loss-less v4 handoff depends on when the MN actually
>disconnects
>> from the old FA and connects to the new one, if buffering is available
>etc.
>> This needs more looking into and hopefully we'll get some discussion going
>> at this IETF.
>>
>> Regards
>> /Karim
>>
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 11:40:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14858
	for ; Mon, 19 Mar 2001 11:40:23 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20554;
	Mon, 19 Mar 2001 08:37:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17027;
	Mon, 19 Mar 2001 08:37:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGZhIm016553
	for ; Mon, 19 Mar 2001 08:35:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JGZhsY016552
	for mobile-ip-dist; Mon, 19 Mar 2001 08:35:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGZYIm016545
	for ; Mon, 19 Mar 2001 08:35:34 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13105
	for ; Mon, 19 Mar 2001 08:35:35 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA14272
	for ; Mon, 19 Mar 2001 08:35:32 -0800 (PST)
From: James Kempf 
Message-Id: <200103191635.IAA14272@heliopolis.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 10:34:28 -0700
To: 
Subject: Re: [mobile-ip] Hierarchical MIPv6 Requirements
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Erik,

>> One of our requirements is that it shall be possible to support
>> multiple levels of hierarchy with minimal (ideally no) mobile involvement.
>
>James,
>
>While I understand the basis for your requirement to minimize (header) overhead
>on the radio link, I don't understand the basis for the multiple levels of
>hirarchy.
>
>Can you enlighten me,
>

One of the things we've been looking at in MWIF is using hierarchical MIP
in a future all-IP radio access network. This list is not the right place
to get into details about exactly what this would allow, but the point
is that if an hierarchical MIP is used in the RAN, the core network
also needs the option to have its own level of hierarchy. There are 
other possible configurations that might require this.

Also, while general principles can be misleading, those of us who remember
the DOS or VMS file system have a general distrust of hierarchical systems that
limit the number of levels. Eventually, somebody wants more than that
limit. This isn't a hard and fast requirement, but I think maybe it
is a design principle.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 12:00:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15399
	for ; Mon, 19 Mar 2001 12:00:34 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03289;
	Mon, 19 Mar 2001 08:54:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19543;
	Mon, 19 Mar 2001 08:53:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGq9Im016640
	for ; Mon, 19 Mar 2001 08:52:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JGq9pS016639
	for mobile-ip-dist; Mon, 19 Mar 2001 08:52:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JGq0Im016632
	for ; Mon, 19 Mar 2001 08:52:00 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29678
	for ; Mon, 19 Mar 2001 08:52:00 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22416
	for ; Mon, 19 Mar 2001 08:51:59 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id C802672543; Mon, 19 Mar 2001 18:51:56 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 575F8BA08; Mon, 19 Mar 2001 18:51:55 +0200 (EET)
Message-ID: <3AB63A39.49928755@nomadiclab.com>
Date: Mon, 19 Mar 2001 18:56:25 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Claude Castelluccia 
Cc: MobileIP Mailing List 
Subject: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Claude,

Here are some half-baked comments to your draft
draft-castelluccia-mobileip-privacy-00.txt

Firstly, I don't immediately see the usability of TMI instead
of just dropping the Home Address altogether, as I suggest
(among other things) in my Homeless Mobile IPv6 draft,
  draft-nikander-mobileip-homelessv6-01.txt

That is, if you use IPsec, you don't need home 
addresses and therefore the home address
destination option is useless.  On the other hand, if
IPsec is not used, the home address destination option
may be faked, and its only use is to try to find out the
supposedly right socket that should receive the packet.
However, if there exists an entry in the Binding Cache,
you can use that entry to look up the right home address
anyway, and therefore you don't need the home address.
Thus, the only reason for sending a home address in the
Home Address Destiation Option is to use it for a Binding
Update.  But then again, you would be using Ipsec....
Ok, I admit that there is the case where you do not or
cannot send a BU but you still want to use your CoA
as the source address and home address in the dest opt.
However, the only reason for that is ingress filtering,
which is broken IMHO anyway.

Secondly, the method that you propose to create TMIs 
actually largely defeats your purpose.  That is, if you know
the home address, you can easily calculate the TMI, and you
can still follow the communications as easily as if you
were using the home address.  This even applies to the
subsequently generated TMIs.

What comes to security, I think that using TMIs would
make it even harder to authorize BUs.  In one way, when
a MN is the client and sends a TMI, it is no different
from e.g. PBK EIDs.  If they are clearly given a separate
address space, as you tentatively suggest, then the
problem might disappear.  However, if you allow overlapping
between TMIs and genuine home addresses, you actually
make it very easy to steal traffic destined to specific
home addresses unless you solve the address ownership problem.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 13:14:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17229
	for ; Mon, 19 Mar 2001 13:14:07 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02638;
	Mon, 19 Mar 2001 10:12:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09025;
	Mon, 19 Mar 2001 10:12:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JIAIIm016871
	for ; Mon, 19 Mar 2001 10:10:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JIAHPs016870
	for mobile-ip-dist; Mon, 19 Mar 2001 10:10:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JIA8Im016863
	for ; Mon, 19 Mar 2001 10:10:09 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08334
	for ; Mon, 19 Mar 2001 10:10:08 -0800 (PST)
Received: from mailbreak.com ([216.207.225.170])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05104
	for ; Mon, 19 Mar 2001 11:10:06 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for ; Mon, 19 Mar 2001 13:09:08 -0500
Message-ID: <008c01c0b0a0$2bbdf860$96958e3f@nyc.solidstreaming.net>
From: "Eunsoo Shim" 
To: 
References: <200103191616.IAA13679@heliopolis.Eng.Sun.COM>
Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
Date: Mon, 19 Mar 2001 13:12:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James,

Thanks for the reply.
I guess your 'trigger' includes information of the IP address or the L2
address of the new FA or the old FA or something similar.
That means it is not just a signal saying that the link quality is not good
enough or that the MN should change the attachment point.

What would be then the design team's plan for the cases not covered by the
schemes of the draft?
Thanks.

Eunsoo

----- Original Message -----
From: "James Kempf" 
To: ; 
Cc: "Eunsoo Shim" 
Sent: Monday, March 19, 2001 12:15 PM
Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)


> Eunsoo,
>
> There was never any intent for each solution to cover all cases. So, if
> the particular link layer does not provide a source trigger at the
> old FA or a trigger on the mobile node, then the NAMONC solution would
> not be used. Similarly, if no source trigger is available on the old FA
> and no target trigger is available on the new FA, then the NIMOT solution
> would not be used.
>
> jak
>
> >It seems to me the draft covers the following cases:
> >1) The old FA(or AR) knows the IP address of the new FA while the MN is
> >attached to the old FA.
> >2) The old BS knows the L2 address of the new BS while the MN is attached
to
> >the old BS
> >3) The new FA knows the IP address of the old FA before the MN registers
> >with the new FA (reactive case)
> >
> >I wonder whether these cases are all we need to cover in the wireless IP
> >world.
> >In particular, what is the solution for a fast handoff that results in a
> >similar latency to NAMONC in the case where the assumptions of 1) and 2)
are
> >not vaild?
> >
> >Regards,
> >
> >Eunsoo
> >
> >----- Original Message -----
> >From: "Karim El-Malki (ERA)" 
> >To: ; "'Koichi Ishibashi'"
> >
> >Sent: Friday, March 09, 2001 1:19 PM
> >Subject: RE: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
> >
> >
> >> Hello
> >>
> >> > Here, I am confusing.
> >> > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip-
> >> > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff.
> >>
> >> Low latency Handoffs proposes two methods:
> >>
> >> - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
> >> - Network Initiated, Mobile Terminated (NIMOT) Handoff
> >>
> >> This is the combination of two existing drafts.
> >> The first method comes from draft-elmalki-mobileip-fast-handoffs-03
> >> and the second is from draft-calhoun-mobileip-proactive-fa-03.
> >>
> >> > In this draft, the Registration procedure will be done pro-actively.
> >> > On the other hand, the fast handoff for Mobile IPv6 draft proposes
> >> > another mechanism.
> >>
> >> The v4 and v6 drafts do not propose completely different mechanisms.
> >> You can run a similar handoff procedure in v4 and v6. However you may
> >> be pointing to a NIMOT-like approach in v6?
> >>
> >> > And I have another confusion.
> >> > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff)
> >> > without the bi-casting, the loss of packets during the transition
> >> > between networks will be eliminated.
> >>
> >> If you don't use bicasting (independently of the method supported) then
> >> achieving a loss-less v4 handoff depends on when the MN actually
> >disconnects
> >> from the old FA and connects to the new one, if buffering is available
> >etc.
> >> This needs more looking into and hopefully we'll get some discussion
going
> >> at this IETF.
> >>
> >> Regards
> >> /Karim
> >>
> >
> >
>
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 14:32:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19286
	for ; Mon, 19 Mar 2001 14:32:06 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22067;
	Mon, 19 Mar 2001 11:30:01 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07518;
	Mon, 19 Mar 2001 11:29:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JJRoIm016971
	for ; Mon, 19 Mar 2001 11:27:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JJRnjw016970
	for mobile-ip-dist; Mon, 19 Mar 2001 11:27:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JJRcIm016963
	for ; Mon, 19 Mar 2001 11:27:39 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11810;
	Mon, 19 Mar 2001 11:27:37 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA18260;
	Mon, 19 Mar 2001 11:27:29 -0800 (PST)
From: Patrice Calhoun 
Message-Id: <200103191927.LAA18260@nasnfs.Eng.Sun.COM>
Date: Mon, 19 Mar 2001 11:23:58 -0800
To: "Phillip Neumiller" ,
        "Alexandru Petrescu" 
Cc: , 
Subject: [mobile-ip] Re: [seamoby] Re: Who implements MIP?
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

May I ask why the seamoby list needs to be cross-posted on this Mobile IP
topic? 

Could we remove the cross-post in all future e-mails that have no relevance
to Seamoby?

PatC
>The difference between your list and mine, is that your list is primarly
>a list of free (more research/testbed ) versions for study whereas
>my list is commercially deployed versions of MIP.  I am trying to collect
>data points and  measurements on commercially deployed MIP systems.
>
>Thanks,
>
>Phil
>----- Original Message ----- > 
>> I maintain a list of publicly-available (simple) mobile ipv6
>> implementations and I'd like to know more details about the above in
>> order to add them to my list.
>> 
>




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 15:46:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21272
	for ; Mon, 19 Mar 2001 15:46:19 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07535;
	Mon, 19 Mar 2001 12:43:15 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16594;
	Mon, 19 Mar 2001 12:42:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JKa7Im017266
	for ; Mon, 19 Mar 2001 12:36:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JKa66A017265
	for mobile-ip-dist; Mon, 19 Mar 2001 12:36:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JKZsIm017258
	for ; Mon, 19 Mar 2001 12:35:55 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23818
	for ; Mon, 19 Mar 2001 12:35:53 -0800 (PST)
Received: from hygro.adsl.duke.edu (pcp000811pcs.wireless.meeting.ietf.org [135.222.65.55])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23803
	for ; Mon, 19 Mar 2001 12:35:52 -0800 (PST)
Received: from hygro.adsl.duke.edu (narten@localhost)
	by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f2JKZU501536
	for ; Mon, 19 Mar 2001 15:35:30 -0500
Message-Id: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] IESG security concerns with MIPv6
Date: Mon, 19 Mar 2001 15:35:30 -0500
From: Thomas Narten 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a note to summarize some security-related concerns that the
IESG has with the Mobile IP v6 Draft
(draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
follows:

The IESG has concerns about the draft's dependency on IPSEC AH to
authenticate Binding Updates. There are several issues here.

   a) There is significant overhead associated with building and
      maintaining AH/IPsec SAs (both in terms of state that needs to
      be maintained, but also in terms of required message flows, and
      the processing required to implement those flows). This has
      negative implications for larger servers that process many 100s
      of thousands of connections at a time.

   b) The processing rules for authenticating a Binding Update with AH
      are complex and are apparently not readily supported by the
      current generation of IPsec/IKE implementations (e.g., the IPsec
      policies are needed that specify sufficient granularity about
      IPv6 packets containing binding updates). There is a concern
      that this will not be rectified in the short term or that
      providing this level of granularity is even approriate for
      IPsec, leading to a possible result that the Binding Update
      won't be implemented/supported at all, (or even worse) that it
      will be used without proper authentication.

The IESG strongly recommends that the WG find an alternate approach
that is not tied to IPsec/AH. Our recommendation is to consider
approaches that are Binding Update specific, so that a solution can be
tailored to meet the actual requirement at hand. The main requirement
that needs to be met is that the use of MIPv6 with Binding Updates be
no less secure than the level of security one currently has with IPv4
(without mobility). That does not mean that the protocol needs to be
immune to *all* types of vulnerabilities. Rather, it means that a
solution should not introduce significant new vulnerabilities that are
not present in IPv4 today. (Of course, reducing vulnerabilities
compared to IPv4 is a very desireable goal.)

The WG is encouraged to look at the ID
http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
It was developed specifically as an alternate approach to addressing
the problems discussed in this note.

Jeff Schiller will give a brief presentation on the approach discussed
in the ID during the Mobile IP session at Minneapolis. The WG chairs
will likely be forming a design team to work on a specific solution to
the identified problems. This also will be discussed at the Thursday
session.

Thomas


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 17:03:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23267
	for ; Mon, 19 Mar 2001 17:03:46 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12564;
	Mon, 19 Mar 2001 14:01:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18202;
	Mon, 19 Mar 2001 14:01:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JLxQIm017519
	for ; Mon, 19 Mar 2001 13:59:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JLxPRH017518
	for mobile-ip-dist; Mon, 19 Mar 2001 13:59:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JLxGIm017511
	for ; Mon, 19 Mar 2001 13:59:16 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06097
	for ; Mon, 19 Mar 2001 13:59:14 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17807
	for ; Mon, 19 Mar 2001 13:59:13 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id 9144E72543; Mon, 19 Mar 2001 23:59:11 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 05095BA08; Mon, 19 Mar 2001 23:59:06 +0200 (EET)
Message-ID: <3AB6823D.5578EB6A@nomadiclab.com>
Date: Tue, 20 Mar 2001 00:03:41 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: Thomas Narten 
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> The WG is encouraged to look at the ID
> http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> It was developed specifically as an alternate approach to addressing
> the problems discussed in this note.

I'd like to point out an additional draft,

http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt

which attempts to take one security view the very problem in 
a larger context.  It is our conviction that the problem mentioned
is just a specific example of a larger problem present in many 
IPv6 signalling mechanisms.  Mobile IPv6 BUs just seem to be the
one that gets most affected.  However, if things like SCTP Dynamic
Addition of IP addresses (draft-ietf-sigtran-addip-sctp-01.txt)
gets accepted, we will see probably worse examples of this problem.

> Jeff Schiller will give a brief presentation on the approach discussed
> in the ID during the Mobile IP session at Minneapolis. The WG chairs
> will likely be forming a design team to work on a specific solution to
> the identified problems. This also will be discussed at the Thursday
> session.

In addition to the PBK approach, a number of alternative approaches
are being emerged.  Based on some discussions that I've had with some
people looking at the solutions, even the various attack models seem
to be somewhat unclear.  I'd suggest that before advancing to select
between the proposed and to-be-proposed solutions, or desiging a new
solution, the design team focuses on trying to fully understand the
extent of the problem.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 17:36:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24197
	for ; Mon, 19 Mar 2001 17:36:27 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09743;
	Mon, 19 Mar 2001 14:29:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26951;
	Mon, 19 Mar 2001 14:29:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JMRrIm017610
	for ; Mon, 19 Mar 2001 14:27:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JMRqEJ017609
	for mobile-ip-dist; Mon, 19 Mar 2001 14:27:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JMRiIm017602
	for ; Mon, 19 Mar 2001 14:27:44 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2JMQUH23623;
	Mon, 19 Mar 2001 14:26:30 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103192226.f2JMQUH23623@locked.eng.sun.com>
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
In-Reply-To: <200103192035.f2JKZU501536@hygro.adsl.duke.edu> from Thomas Narten
 at "Mar 19, 2001 03:35:30 pm"
To: narten@raleigh.ibm.com, mobile-ip@sunroof.eng.sun.com
Date: Mon, 19 Mar 2001 14:26:30 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> This is a note to summarize some security-related concerns that the
> IESG has with the Mobile IP v6 Draft
> (draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
> follows:
> 
> The IESG has concerns about the draft's dependency on IPSEC AH to
> authenticate Binding Updates. There are several issues here.
> 
>    a) There is significant overhead associated with building and
>       maintaining AH/IPsec SAs (both in terms of state that needs to
>       be maintained, but also in terms of required message flows, and
>       the processing required to implement those flows). This has
>       negative implications for larger servers that process many 100s
>       of thousands of connections at a time.
> 
>    b) The processing rules for authenticating a Binding Update with AH
>       are complex and are apparently not readily supported by the
>       current generation of IPsec/IKE implementations (e.g., the IPsec
>       policies are needed that specify sufficient granularity about
>       IPv6 packets containing binding updates). There is a concern
>       that this will not be rectified in the short term or that
>       providing this level of granularity is even approriate for
>       IPsec, leading to a possible result that the Binding Update
>       won't be implemented/supported at all, (or even worse) that it
>       will be used without proper authentication.
>
These are not all the issues...

> The IESG strongly recommends that the WG find an alternate approach
> that is not tied to IPsec/AH. Our recommendation is to consider
> approaches that are Binding Update specific, so that a solution can be
> tailored to meet the actual requirement at hand. The main requirement
> that needs to be met is that the use of MIPv6 with Binding Updates be
> no less secure than the level of security one currently has with IPv4
> (without mobility). That does not mean that the protocol needs to be
> immune to *all* types of vulnerabilities. Rather, it means that a
> solution should not introduce significant new vulnerabilities that are
> not present in IPv4 today. (Of course, reducing vulnerabilities
> compared to IPv4 is a very desireable goal.)
>
I think one of the most important issues is the authorization problem
that was raised at the last ietf.  Binding update contains two
important things. One is the home address and the other is the
care of address. If i can forge any of this two then there is no
use of having a binding update. Note that it is possible to use
IPsec and solve the authorization problem associated with
the home address and if we send binding updates *only*
to the home agent. Yes, this will kill route optimization. 
But i feel that this problem is unique to mobility i.e a
node moves to a new place and wants to direct all traffic
destined to the home address to a care of address. If i
can use any address, then the potential application of
Mobile IPv6 e.g. cell phones will suffer severe security
problem.

> The WG is encouraged to look at the ID
> http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> It was developed specifically as an alternate approach to addressing
> the problems discussed in this note.
>
But this does not address the above problem which is important.
draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
which if can be generalized looks like a good solution for the
same problem that pbk-frame is solving. At least, pbk-frame
seems to have problems if somebody can spoof somebody elses
IP address and send the EID.

-mohan
 
> Jeff Schiller will give a brief presentation on the approach discussed
> in the ID during the Mobile IP session at Minneapolis. The WG chairs
> will likely be forming a design team to work on a specific solution to
> the identified problems. This also will be discussed at the Thursday
> session.
> 
> Thomas



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 17:40:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24353
	for ; Mon, 19 Mar 2001 17:40:45 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15073;
	Mon, 19 Mar 2001 14:38:33 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29348;
	Mon, 19 Mar 2001 14:37:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JMaBIm017631
	for ; Mon, 19 Mar 2001 14:36:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JMaBXC017630
	for mobile-ip-dist; Mon, 19 Mar 2001 14:36:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JMa2Im017623
	for ; Mon, 19 Mar 2001 14:36:02 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01399
	for ; Mon, 19 Mar 2001 14:36:02 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10581
	for ; Mon, 19 Mar 2001 15:36:00 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2JMZwd08880
	for ; Mon, 19 Mar 2001 23:35:58 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Mar 19 23:35:58 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 19 Mar 2001 23:34:40 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBC9E@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Suggested revisions to HMIPv6
Date: Mon, 19 Mar 2001 23:35:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	Hello Charlie, 

	After our private discussion today and after reading Claude's
	response I'd like to add some comments. I basically 
	agree with all of Claude's comments but will address 
	the points he left.


> - MAP advertisements should not have preference values.
>   The use of preferences is very fragile in any sort of
>   dynamic situation such as is described within the HMIP
>   draft.
> 
	=> The preference is the same as the HA preference. 
	I don't see why that is fragile.

> - Using router renumbering for establishing MAP discovery
>   techniques is highly speculative.  Creating a new message
>   type greatly diminishes the claim of re-use of existing protocols.
> 
	=> Creating a new ICMP type, certainly means that the same
	protocol is being reused (ICMP). Why is RR highly speculative ?

> - The 'T' bit for the Neighbor Discovery extension is either
>   confusing, or should be eliminated (or both).
> 
	=> We can clarify that.


> - In section 7, the HA should not be tunneling things to
>   the mobile node's site-local address.
> 
	=> MIPv6 (rev 13) says it SHOULD. If you remove
	it from the base draft then it can e removed from this one.

> - Contrary to the statement in section 13.1, there are
>   benefits to having multiple "levels" of care-of address
>   locality.
> 
	=> I guess we discussed this for a while. Basically 
	as you know we haven't seen any clear resons but 
	let's see what others in the WG think.

> - There should be a very clear statement, perhaps in an
>   appendix, about exactly which parts of the protocol
>   specification are covered by Ericsson patents.
> 
	=> No, the current statement is enough. I don't 
	think you really mean that given your statement
	in the Reg forwarding draft.
	We're compliant with section 10 of 2026 and that's
	all that needs to be said. Even if we wanted 
	to, we don't know what exactly will be covered. 

	Regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 18:05:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24961
	for ; Mon, 19 Mar 2001 18:05:55 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07225;
	Mon, 19 Mar 2001 15:03:52 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06180;
	Mon, 19 Mar 2001 15:03:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JN2HIm017722
	for ; Mon, 19 Mar 2001 15:02:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JN2H4L017721
	for mobile-ip-dist; Mon, 19 Mar 2001 15:02:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JN27Im017714
	for ; Mon, 19 Mar 2001 15:02:08 -0800 (PST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id AAA10991;
	Tue, 20 Mar 2001 00:02:03 +0100 (MET)
Date: Mon, 19 Mar 2001 19:27:49 +0000 (PST)
From: Erik Nordmark 
Subject: Re: [mobile-ip] Suggested revisions to HMIPv6
To: charliep@iprg.nokia.com
Cc: "mobile-ip@sunroof.eng.sun.com" 
In-Reply-To: "Your message with ID" <3AB2A153.4202E60C@iprg.nokia.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Charlie,

> Here are some suggestions about possible revisions to the
> HMIPv6 draft that merit consideration.

Seems like a fair number of your suggested changes have to do
with disagreement about the problem statement.

Does the WG have a written and agreed upon problem statement for
handover?

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 18:13:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25212
	for ; Mon, 19 Mar 2001 18:13:42 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02212;
	Mon, 19 Mar 2001 15:09:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16876;
	Mon, 19 Mar 2001 15:08:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JN7mIm017748
	for ; Mon, 19 Mar 2001 15:07:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JN7lfR017747
	for mobile-ip-dist; Mon, 19 Mar 2001 15:07:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JN7cIm017740
	for ; Mon, 19 Mar 2001 15:07:39 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16560
	for ; Mon, 19 Mar 2001 15:07:39 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20976
	for ; Mon, 19 Mar 2001 15:07:39 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA20727;
	Mon, 19 Mar 2001 15:07:42 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACK07022;
	Mon, 19 Mar 2001 15:07:35 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00313; Mon, 19 Mar 2001 15:07:35 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15030.37175.357306.848766@thomasm-u1.cisco.com>
Date: Mon, 19 Mar 2001 15:07:35 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Dave Oran , rcoltun@redback.com
Subject: Re: [mobile-ip] Question to Chairs re: QoS
In-Reply-To: <5.0.2.1.2.20010318083035.02691c50@mira-sjcm-2.cisco.com>
References: 
	<5.0.2.1.2.20010318083035.02691c50@mira-sjcm-2.cisco.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Fred Baker writes:
 > At 06:04 PM 3/14/2001 -0800, Michael Thomas wrote:
 > >Question to the AD's and Chairs: does MIP WG
 > >include in its charter the task of recreating RSVP
 > >just because at first blush it's not clear how
 > >RSVP will interact with MIP?
 > 
 > Dumb question of the month - would RSVP not follow the source/destination 
 > routes involved, and potentially impose a reservation for the tunnel in 
 > question? The real problems should relate to service surrounding a change 
 > in COA or FA; one presumably is forced to trigger a reservation 
 > installation for the new route which may involve a temporary disruption 
 > surrounding a route which is already in place. One would like to re-use the 
 > reservation in place for the old to support the new route, up to the point 
 > where the two routes differ.

   The main problem is that the join point for the
   repaired reservation in the MN->CN direction is,
   in fact, the CN itself. Ie, not good. Life would
   be much better if the filter spec didn't need to
   change (which a changed CoA seems to imply). This
   could be done either by using the Home Address
   destination option as the source address filter,
   which would probably be pretty sucky for routers
   or by placing the home address in the source address
   which has RPF implications. 

   One other consideration which needs to be pointed
   out here is what is the implication of wireline
   (fixed) hosts behind a mobile router. Are they
   aware of their mobility or not? If not, they 
   will cluelessly put their home address into the
   source address tickling the RPF problem. Is this
   enough to tilt the balance? I don't know.

   I don't know whether you scanned my RSVP/MIP
   analysis draft, but there are a number of 
   considerations like these. Suffice it to say,
   I have a lot more questions than answers.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 18:13:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25227
	for ; Mon, 19 Mar 2001 18:13:52 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15083;
	Mon, 19 Mar 2001 15:11:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07895;
	Mon, 19 Mar 2001 15:11:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNAjIm017768
	for ; Mon, 19 Mar 2001 15:10:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JNAjW7017767
	for mobile-ip-dist; Mon, 19 Mar 2001 15:10:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNAaIm017760
	for ; Mon, 19 Mar 2001 15:10:36 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09525
	for ; Mon, 19 Mar 2001 15:10:32 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22476
	for ; Mon, 19 Mar 2001 15:10:31 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2JNATd12994
	for ; Tue, 20 Mar 2001 00:10:30 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Mar 20 00:10:29 2001 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 00:06:25 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCA2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6
Date: Tue, 20 Mar 2001 00:10:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> > >
> > > In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP.
> > > The question is which one the home address or the onlink (LCoA)?
> > >
> >         => Is there an "ACoA" in the draft ? If so it's a typo.
> >         I don't really understand your question. In extended mode the mobile
> >         node uses the MAP's advertised address as an alternate-CoA, oh I
> >         see what you meant by ACOA !
> >
> >         So I still don't get your last statement. The source address in the
> >         IP packets is the LCoA. The address shown to the appliccations
> >         is the Home Address. The address that the CN/HA has in their
> >         binding cache is the alternate-CoA (MAP's address).
> >
> >         Have I confused you more ?
> 
> Not at all, but let me rephraze. The question is which address would the MN use as its
> ACoA, the _home_ address of the MAP _or_ the onlink (LCoA) of the MAP?
> 
	=> In Extended mode, the MN sends packets using 
	its LCoA. In basic mode it can do the same unless
	instructed otherwise as er the P and I flags in rev 3 
	of the draft that Claude announced.

> > > If a MAP is serving as a mobile AR you enforce that it must advertise its and all
> > > MAP options available. Does that imply that the 'preference' is specific here?
> > >
> >         => The preference is either configured in the MAP or a default
> >         behaviour that varies with loading ...etc.
> >         Each MAP can have its own preference value independantly from
> >         other MAPs
> >
> 
> or a default behaviour that varies with loading ...etc.
> 
> 
> This is as vague as the statement in the draft...could you elaborate please? In fact
> that brings me to a whole new question
> with respect to my study of your scheme.
> 
> 1)There is no mention about how the preference metric is regulated and by what entities.
> Is it dynamic or static?
> 
> 2) Does the preference and distance metric work for different modes? Does one override
> the other?
> 
> If you have a preference metric and you opt for a map with the lowest preference, then I
> feel that your load balancing goes out of the window. All
> MN will get the lowest preference and a single MAP is guaranteed to always pick the same
> MAP. This is the one with the lowest pref.
> 
> What are the reasons imposing preference over distance?
> 
	=> I agree that we should show ways of setting the 
	preference. However one could argue that the same is 
	required for the HA in MIPv6. But you do have a point
	and it should be addressed for both.

	Perhaps a separate draft addressing both would be good.

> >
> > > Further (page 20, top statement) you state that this would allow the MN to obtain a
> > > new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA).
> > >
> >         => We mean RCoA. The RCoA is the address provided by the MAP, regardless
> >         of which mode it operates in. So for Basic mode the RCoA is the
> >         address that the MN forms on the MAP's subnet. In extended mode
> >         the RCoA is the MAP's IP address.
> >
> 
> No RCoA is provided by MAP... MAP only provides a prefix and does DAD as far as I can
> tell from your protocol spec. This is not the same. I think it would be correct to state
> in your draft that the ACoA may take two values: an RCoA and the MAP's IP addr (I trust
> LCoA). I think this is better and leaves no space for ambiguity.
> 
	=> Ok. But we will use RCoA for both modes just for simplicity
	and state that RCoA can be used as a src address with basic 
	mode but not with Extended mode.

> >         => For the same reason you need HMIPv6 at all. Reduce signalling
> >         and help speed up the handover by updating a node close
> >         to the MN.> 
> >
> 
> Objection ! Speculative...If the MR acts as the closest MAP, I fail to see why the MN> 
> should choose the "further" (i.e. higher MAP in the routing hierarchy) so as to register
> its home addr and its CoA which is the IP address of the MAP that it has registered with
> (ie the closest one :)
> 
> In fact that creates exactly the pitfall that you argue against for RegReg: the creation
> of a routing hierarchy (two level for a single MR). Consider:
> Packets arrive to the "further" MAP; these are decapsulated and the B. Cache find that
> needs to send them to the CoA for that MN which (hey...) is..the _next_ MAP (level 1
> reached). This MAP will receive the packet and check the routing header to find the
> final dest the MN home addr. Encapsulate and send over to MN (level 2 reached). Do you
> agree?
> 
	No. The path between the MAP and the MN in the mobile 
	network case MUST include one of the MRs as the last hop or
	as an entry point to the mobile network.  This is not 
	an HMIPv6 restriction, the same is valid for a MN connected 
	to an AR. Just replace the MR with AR.

	My objection to the approach mentioned in Reg6, is that
	the traffic is _forced_ to go through the mobility 
	aware routers and there is no need for that.



> > Anyhow we've dicovered
> >         that there is a need for the network to inform the MN
> >         whether the use of RCoA is possible or not.
> >         We added that in the draft and Claude will post
> >         that on the INRIA web page soon.
> >
> 
> Fine...that however proves that you need to improve your spec further...what I am trying
> to say here is that
> the solution that each side proposes has got its merits, weaknesses, and may be open to
> further improvement (as with anything in life :)
> 
	=> Have a look at rev 3.

> This is to say that RegReg can come up with another autoconfig scheme for the routing
> hierarchy that decouples BU signalling and caters for
> single points of failures. This can also be expressed as "we are supplying a detailed
> supplement to the draft that solves this problem" which is
> just as good as your statement. What we need to make sure is understand that everything
> comes at a price. Complex protocol and signalling for
> really awkward mobility situations that can become the norm, or protocol simplicity for
> the base case and addition of optimization that again
> bring complications to the signalling design...I cannot see a clear cut choice to any of
> the two options.
> 
> I feel that the group would benefit infinetely if the specs merge...
> 
	=> "Merging" is not a goal. The goal should be to highlight
	what's missing in the current draft (HMIPv6) and if that 
	missing fuctionality is stated somewhere else then merging 
	makes sense. So far we haven't been given a good technical
	reason. The complexity of mobility management as you mention
	above does not imply the need for a multi-level hiearchy.
	It is solved with the single level one in HMIPv6.

> >
> > > If you have load balancing effected which RCoA do you send back to the HA?
> > >
> >         => Load balancing is done by the MAP, you only need to send
> >         one RCoA to the HA. Did you mean something else ?
> >
> 
> Well I cannot see the rational behind the load balancing being done by the MAP. Do you
> mean that a MAP will elect another MAP to forward encapsulated flows from different CNs.
> 
	=> No. Maybe load balancing s a bad name. Perhaps 
	we should call it something like "Per-connection or Per-flow
	movement". It is about moving a connection/flow to another
	interface. Using the MAP (a router in the visted network)
	seems reasonable for the same reasons that a BU to 
	a local anchor point is required.
	So the MN "moves" one connection while using the 
	same MAP.


	Thanks for your comments,

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 18:25:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25604
	for ; Mon, 19 Mar 2001 18:25:06 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23461;
	Mon, 19 Mar 2001 15:20:52 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19604;
	Mon, 19 Mar 2001 15:20:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNJdIm017827
	for ; Mon, 19 Mar 2001 15:19:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JNJdif017826
	for mobile-ip-dist; Mon, 19 Mar 2001 15:19:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNJUIm017819
	for ; Mon, 19 Mar 2001 15:19:30 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09555;
	Mon, 19 Mar 2001 15:19:29 -0800 (PST)
Received: from hygro.adsl.duke.edu (pcp000811pcs.wireless.meeting.ietf.org [135.222.65.55])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27670;
	Mon, 19 Mar 2001 15:19:29 -0800 (PST)
Received: from hygro.adsl.duke.edu (narten@localhost)
	by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f2JNJnh01306;
	Mon, 19 Mar 2001 18:19:49 -0500
Message-Id: <200103192319.f2JNJnh01306@hygro.adsl.duke.edu>
To: Mohan Parthasarathy 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6 
In-Reply-To: Message from Mohan Parthasarathy  
   of "Mon, 19 Mar 2001 14:26:30 PST." <200103192226.f2JMQUH23623@locked.eng.sun.com> 
Date: Mon, 19 Mar 2001 18:19:49 -0500
From: Thomas Narten 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mohan Parthasarathy  writes:

> These are not all the issues...

There may be others, but these seem to be the major ones, so that was
the focus of the message.

> I think one of the most important issues is the authorization problem
> that was raised at the last ietf.  Binding update contains two
> important things. One is the home address and the other is the
> care of address. If i can forge any of this two then there is no
> use of having a binding update.

In order to produce a solution that is not more vulnerable than IPv4,
it is likely that one will want the equivalent of a 3-way
handshake. That is:

1) Mobile Node (MN) sends something to Correspondent (CN)
2) CN sends something back to MN
3) MN then sends something back of the CN that includes information
   that is only knowable if the MN receives the message in 2)

Once step 3) completes, the CN knows that packets it is sending to the
MN are reaching the MN (or at least to the node that it *thinks* is
the MN). I.e., this is what you get in IPv4 today, when communicating
with some node.

> Note that it is possible to use IPsec and solve the authorization
> problem associated with the home address

Yes. If the goal is simply to establish a set of keys between two
communicating nodes (i.e., to verify that packets are flowing in both
directions), you can probably do that with IPsec. I.e, negotiating
some sort of keys between two nodes, allows one to force a
re-authentication later, to verify that one is still talking with who
they were earlier. But mobile IPv6 as specfied today doesn't include
the details about doing this within the context of IPsec. Having said
that, there is still the overall concern that using IPsec to do this
is not ideal.

> > The WG is encouraged to look at the ID
> > http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> > It was developed specifically as an alternate approach to addressing
> > the problems discussed in this note.
> >
> But this does not address the above problem which is important.
> draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
> which if can be generalized looks like a good solution for the
> same problem that pbk-frame is solving. At least, pbk-frame
> seems to have problems if somebody can spoof somebody elses
> IP address and send the EID.

Note that the pbk draft is not necessarily the *only* or even *best*
way to solve the issues at hand. It was developed, however, so that
there would at least be one approach to consider as a possible
starting point.

Thomas


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 18:36:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25925
	for ; Mon, 19 Mar 2001 18:36:42 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07482;
	Mon, 19 Mar 2001 15:18:01 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25671;
	Mon, 19 Mar 2001 15:17:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNFKIm017794
	for ; Mon, 19 Mar 2001 15:15:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2JNFKQw017793
	for mobile-ip-dist; Mon, 19 Mar 2001 15:15:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2JNFAIm017783
	for ; Mon, 19 Mar 2001 15:15:10 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25054
	for ; Mon, 19 Mar 2001 15:15:10 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18336
	for ; Mon, 19 Mar 2001 15:15:10 -0800 (PST)
Received: from FRED-W2K.cisco.com (sjc-vpn-365.cisco.com [10.21.65.109])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA29842;
	Mon, 19 Mar 2001 15:15:28 -0800 (PST)
Message-Id: <5.0.2.1.2.20010319171434.045fc970@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 19 Mar 2001 17:14:53 -0600
To: mobile-ip@sunroof.eng.sun.com
From: Fred Baker 
Subject: Re: [mobile-ip] Question to Chairs re: QoS
Cc: mobile-ip@sunroof.eng.sun.com, Dave Oran ,
        rcoltun@redback.com
In-Reply-To: <15030.37175.357306.848766@thomasm-u1.cisco.com>
References: <5.0.2.1.2.20010318083035.02691c50@mira-sjcm-2.cisco.com>
 
 <5.0.2.1.2.20010318083035.02691c50@mira-sjcm-2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

At 03:07 PM 3/19/2001 -0800, Michael Thomas wrote:
>    I don't know whether you scanned my RSVP/MIP
>    analysis draft, but there are a number of
>    considerations like these. Suffice it to say,
>    I have a lot more questions than answers.

I have not. What is its identifier?



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 19:49:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27891
	for ; Mon, 19 Mar 2001 19:49:57 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21618;
	Mon, 19 Mar 2001 16:48:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15137;
	Mon, 19 Mar 2001 16:48:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K0kJIm018256
	for ; Mon, 19 Mar 2001 16:46:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2K0kIQM018255
	for mobile-ip-dist; Mon, 19 Mar 2001 16:46:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K0k9Im018248
	for ; Mon, 19 Mar 2001 16:46:10 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28442
	for ; Mon, 19 Mar 2001 16:46:10 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17791
	for ; Mon, 19 Mar 2001 17:46:08 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2K0k2d44383
	for ; Tue, 20 Mar 2001 01:46:03 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id BAA28369
	for ; Tue, 20 Mar 2001 01:46:02 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2K0k2A33587
	for ; Tue, 20 Mar 2001 01:46:02 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103200046.f2K0k2A33587@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6 
In-reply-to: Your message of Mon, 19 Mar 2001 15:35:30 EST.
             <200103192035.f2JKZU501536@hygro.adsl.duke.edu> 
Date: Tue, 20 Mar 2001 01:46:02 +0100
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   The IESG has concerns about the draft's dependency on IPSEC AH to
   authenticate Binding Updates.

=> I'll be politically incorrect but it seems the real issue is
Mobile IPv6 relies on a mandatory mechanism (IPsec AH) which is
expensive to implement, ..., ie. many people want to kill it...
If this is the case why not to say it (oh! this would be politically
incorrect :-).

    There are several issues here.
   
      a) There is significant overhead associated with building and
         maintaining AH/IPsec SAs (both in terms of state that needs to
         be maintained, but also in terms of required message flows, and
         the processing required to implement those flows). This has
         negative implications for larger servers that process many 100s
         of thousands of connections at a time.
   
=> I assume that large servers stand for correspondent nodes. I don't
believe a good security level will be very cheap... The issue here seems
to be the price of IKE in terms of CPU cycles and message exchanges
(phase 1 in aggressive mode is 3 messages, phase 2 again 3 messages).
There are three obvious ways to fix this:
 - don't optimize routing (of course we don't want this solution)
 - define a little brother of IKE which will be able to build
   a pair of SAs in a minimal number of messages (it seems that
   3 messages are the minimal number and the BU can be piggybacked in
   the third one... If we merge aggressive and quick modes this can
   be done but we'll loose almost all negociation capabilities).
 - define an ad hoc mechanism... This will give the same result than
   the second solution but as a special mechanism we'll get special
   new bugs.

      b) The processing rules for authenticating a Binding Update with AH
         are complex and are apparently not readily supported by the
         current generation of IPsec/IKE implementations (e.g., the IPsec
         policies are needed that specify sufficient granularity about
         IPv6 packets containing binding updates).

=> if this is true I can't explain why there are different working
implementations of secure Mobile IPv6... If the issue is identities
work only for UDP and TCP because of ports this is easy to fix and
will be fixed for other protocols too (the case of ICMPv6 is far
harder because ICMPv6 is used for many things and some can funny fail
when ICMPv6 is blindly secure, the neighbor discovery is a well known
example of this).

         There is a concern that this will not be rectified in the
         short term or that providing this level of granularity is
         even approriate for IPsec

=> I apologize because I'll be again politically incorrect:
if IPsec should be restricted to its current market (VPNs)
of course this is a real issue...

         leading to a possible result that the Binding Update
         won't be implemented/supported at all, (or even worse) that it
         will be used without proper authentication.
   
=> of course nobody wants this.

   The IESG strongly recommends that the WG find an alternate approach
   that is not tied to IPsec/AH. Our recommendation is to consider
   approaches that are Binding Update specific, so that a solution can be
   tailored to meet the actual requirement at hand.

=> so the IESG recommendation is an ad hoc mechanism.

   The WG is encouraged to look at the ID
   http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
   It was developed specifically as an alternate approach to addressing
   the problems discussed in this note.
   
=> I am not convinced by this proposal... IKE with self-signed/unverified
certificates gives a better security (because of the DH shared secret
and the symetrical authentication).

   Jeff Schiller will give a brief presentation on the approach discussed
   in the ID during the Mobile IP session at Minneapolis. The WG chairs
   will likely be forming a design team to work on a specific solution to
   the identified problems. This also will be discussed at the Thursday
   session.
   
=> rendez-vous at the Thursday session!

Regards

Francis.Dupont@enst-bretagne.fr

PS: for a standard correspondent the mobile node can use its care-of address
or its home address (the MUST for the care-of address is for the first
home registration from a visited network: the home address can be used only
after this home registration). The care-of address seems a bit better for
security (direct path) but has an authorization issue for the usage of
the home address in SAs. The home address has of course the opposite
properties (known/indirect path but the address is the same for phase 1,
phase 2 and BU).


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 19:58:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28130
	for ; Mon, 19 Mar 2001 19:58:57 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25878;
	Mon, 19 Mar 2001 16:57:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00903;
	Mon, 19 Mar 2001 16:57:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K0uOIm018335
	for ; Mon, 19 Mar 2001 16:56:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2K0uObi018334
	for mobile-ip-dist; Mon, 19 Mar 2001 16:56:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K0uFIm018327
	for ; Mon, 19 Mar 2001 16:56:15 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2K0t0T23742;
	Mon, 19 Mar 2001 16:55:00 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103200055.f2K0t0T23742@locked.eng.sun.com>
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
In-Reply-To: <200103192319.f2JNJnh01306@hygro.adsl.duke.edu> from Thomas Narten
 at "Mar 19, 2001 06:19:49 pm"
To: Thomas Narten 
Date: Mon, 19 Mar 2001 16:55:00 -0800 (PST)
CC: Mohan Parthasarathy ,
        mobile-ip@sunroof.eng.sun.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Mohan Parthasarathy  writes:
> 
> > These are not all the issues...
> 
> There may be others, but these seem to be the major ones, so that was
> the focus of the message.
> 
> > I think one of the most important issues is the authorization problem
> > that was raised at the last ietf.  Binding update contains two
> > important things. One is the home address and the other is the
> > care of address. If i can forge any of this two then there is no
> > use of having a binding update.
> 
> In order to produce a solution that is not more vulnerable than IPv4,
> it is likely that one will want the equivalent of a 3-way
> handshake. That is:
> 
> 1) Mobile Node (MN) sends something to Correspondent (CN)
> 2) CN sends something back to MN
> 3) MN then sends something back of the CN that includes information
>    that is only knowable if the MN receives the message in 2)
> 
> Once step 3) completes, the CN knows that packets it is sending to the
> MN are reaching the MN (or at least to the node that it *thinks* is
> the MN). I.e., this is what you get in IPv4 today, when communicating
> with some node.
>
Then, this limits the use of mobile ipv6 for certain type of applications
where security is important. Or are we saying that those potential
applications does not need security ? Are you saying that we just
list the shortcomings of mobile ipv6 and let people decide what they
want to do with it ?

-mohan
 
> > Note that it is possible to use IPsec and solve the authorization
> > problem associated with the home address
> 
> Yes. If the goal is simply to establish a set of keys between two
> communicating nodes (i.e., to verify that packets are flowing in both
> directions), you can probably do that with IPsec. I.e, negotiating
> some sort of keys between two nodes, allows one to force a
> re-authentication later, to verify that one is still talking with who
> they were earlier. But mobile IPv6 as specfied today doesn't include
> the details about doing this within the context of IPsec. Having said
> that, there is still the overall concern that using IPsec to do this
> is not ideal.
> 
> > > The WG is encouraged to look at the ID
> > > http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> > > It was developed specifically as an alternate approach to addressing
> > > the problems discussed in this note.
> > >
> > But this does not address the above problem which is important.
> > draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
> > which if can be generalized looks like a good solution for the
> > same problem that pbk-frame is solving. At least, pbk-frame
> > seems to have problems if somebody can spoof somebody elses
> > IP address and send the EID.
> 
> Note that the pbk draft is not necessarily the *only* or even *best*
> way to solve the issues at hand. It was developed, however, so that
> there would at least be one approach to consider as a possible
> starting point.
> 
> Thomas



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 22:01:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02293
	for ; Mon, 19 Mar 2001 22:01:01 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA12232;
	Mon, 19 Mar 2001 18:59:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28043;
	Mon, 19 Mar 2001 18:59:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K2v7Im018491
	for ; Mon, 19 Mar 2001 18:57:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2K2v6Dk018490
	for mobile-ip-dist; Mon, 19 Mar 2001 18:57:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K2uoIm018483
	for ; Mon, 19 Mar 2001 18:56:50 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA12342;
	Mon, 19 Mar 2001 19:56:49 -0700 (MST)
Received: from sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id TAA22394; Mon, 19 Mar 2001 19:59:09 -0700
Message-ID: <3AB6C5D7.89DFAB1E@sun.com>
Date: Tue, 20 Mar 2001 03:52:07 +0100
From: gabriel montenegro 
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mobile-ip@sunroof.eng.sun.com" 
Subject: Re: [mobile-ip] -HMIPv6 draft + Privacy draft-
Content-Type: multipart/mixed;
 boundary="------------2D6239C521DC62A8DE8B3035"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.
--------------2D6239C521DC62A8DE8B3035
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[This message bounced the first time I sent it. This is a resend.]

On the subject, folks may be interested in a recent message sent out by
Pekka Nikander:

    http://www.vpnc.org/ietf-ipsec/mail-archive/threads.html#02559

and my response on both IPSEC and IPNG mailing lists (attached).

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chene         Email: gab@sun.com
38240 Meylan, FRANCE              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88
--------------2D6239C521DC62A8DE8B3035
Content-Type: message/rfc822
Content-Disposition: inline

Received: from engmail4.Eng.Sun.COM (engmail4.Eng.Sun.COM [129.144.134.6])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id FAA08819
	for ; Sun, 18 Mar 2001 05:37:24 -0800 (PST)
Received: from sunmail2.Sun.COM (sunmail2.EBay.Sun.COM [129.150.166.10])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11027
	for ; Sun, 18 Mar 2001 05:37:24 -0800 (PST)
Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10])
	by sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id FAA20462
	for ; Sun, 18 Mar 2001 05:37:24 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id GAA18624;
	Sun, 18 Mar 2001 06:37:23 -0700 (MST)
Received: from sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id GAA09370; Sun, 18 Mar 2001 06:39:33 -0700
Message-ID: <3AB4B8EC.8791167A@sun.com>
Date: Sun, 18 Mar 2001 14:32:28 +0100
From: gabriel montenegro 
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Nikander 
CC: IPSEC Mailing List ,
        IPNG Mailing List 
Subject: Re: A method to prevent DoS in IPv6 DAD and Mobile IPv6
References: <3AB47F98.A5CFEC6C@nomadiclab.com>
Content-Type: multipart/mixed;
 boundary="------------6671185CAB32645A5EC3C3B5"

This is a multi-part message in MIME format.
--------------6671185CAB32645A5EC3C3B5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Wow! I came up with the same scheme, although as part of a slightly more general mechanism.
I've only been discussing with a couple of folks including Claude Castellucia and Erik Nordmark.
But your  message prompts me to send my stuff in as well. We should  talk in Minneapolis.
I had to name these things something, and based on the fact that what's important about them
is the fact that they are: statistically unique and cryptographically verifiable, I just called them
SUCV's. So we have SUCV identifiers and SUCV addresses. The latter are the ones you
mentioned in your previous note.

I attach my notes, although they are not yet complete nor in internet draft format.

The attachments are:

    1. my notes on pekka's address ownership, PBK and claude's privacy extension drafts
    2. proposal and thoughts on SUCV's

-gabriel
--
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
29, chemin du Vieux Chene         Email: gab@sun.com
38240 Meylan, FRANCE              Mobile: +33 673 99 56 62
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88


--------------6671185CAB32645A5EC3C3B5
Content-Type: text/html; charset=us-ascii;
 name="AddressOwnershipAndPrivacyForMipV6.htm"
Content-Disposition: inline;
 filename="AddressOwnershipAndPrivacyForMipV6.htm"
Content-Transfer-Encoding: 7bit







   

   

    TWiki . Main . AddressOwnershipAndPrivacyForMipV6  










Notes on V6 address ownership problems


http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt


    


  • 

protection against hijacking of valid addresses requires cryptographic

authorization for operations that modify routing (BU's, source routing,

etc)
    • 




  • 

quoting from above draft: "Currently there exists no specified mechanism

for proving address ownership in Internet-wide scale."
    • 




Mini Proposal:


    


  • 

remaining use of redirect operations: they are only allowed with

non-global addresses which are bound (via a cryptographically sound binding)

to anonymous or pseudonymous addresses
    • 




  • 

the above constitues perhaps the only rule that operates by default, allowing

any other more dangerous operation only if authorized by strong cryptographic

mechanisms
    • 









Notes on PBK


http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt


    


  • 

temporary public/private pair
    • 




  • 

EID = hash(publicComponent)
    • 




      


    1. 

Initiator sends EID to Responder
      2. 




    2. 

Initiator sends publicComponent to Responder
      3. 


    















Note







 This exchange must be secure, but it is an improvement over cookies.











    


  • 

Initiator sends (BU, EID)Priv to Responder
    • 




Problems:


    


  • 

does NOT really address the address ownership problem of any publicly routable

addresses
    • 




  • 

it is not specified how the EID and public component of the PK are sent

by the initiator to the responder
    • 




  • 

preventing hijacking and MIM attacks depend on this sequence if not clearly

specified
    • 




  • 

might as well make it secure: use HIP and its sequence
    • 









Notes on simple privacy extension for Mobile IP v6


http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt

What it hides: home address in the following two situations:


    


  1. 

MN initiated traffic: hides home address from CN (a server?) and eavesdroppers
    2. 




  2. 

CN initiated traffic: hides home addr from eavesdropper (not from CN) What

it does not hide: home address from initiating CN's when the MN

is a server/responder
    3. 




Basics:


    


  • 

MN's instead of their home address use a 128 bit identifier called TMI
    • 




      


    • 

digest for TMI' = MD5 ( Home address | digest of TMI )
      • 




    • 

define a new TLA (16 bits) for TMI address space
      • 




    • 

[why not SHA-1 (also required by IPSEC) given the collision resistance

issues with MD5?]
      • 


    




Works as follows:


    


  1. 

mobile initiator
    2. 




      


    • 

uses TMI as home address.
      • 




    • 

CN sends to TMI@COA (where the addr before

the @ is carried within the home address option
      • 


    




  2. 

mobile responder
    3. 




      


    • 

"CN knows the MN's identity by definition" (?)
      • 




    • 

[Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve

the COA by some other means.]
      • 




    • 

In this case, the MN can still hide its location (COA) by using a bi-directional

tunnel with its HA and not sending any BU's to the CN.
      • 




    • 

traffic MN to CN would be of the form: homeAddr@TMI@COA
      • 




    • 

requires a new destination option to carry the real homeAddr
      • 




    • 

subsequent packets have just the TMI (essentially an SA), [so why not just

use IPSEC]?
      • 


    




Still has problems


    


  • 

TMI does not prevent hijacking as explained in the nikander draft on addr

ownership
    • 




  • 

this is the problem our new default trust rule addresses (in conjunction

with HIP)
    • 




  • 

There may be issues with its use of MD5: WeaknessInMd5
    • 









Proposal


Given that:


    


  • 

The addr ownership problem is real. BU's and other exchanges which alter

routing or tunneling open up DOS attacks. PBK attempts to solve these,

but does not succeed for globally routable addresses.
    • 




  • 

Privacy concerns are also real, and the privacy extensions aim to solve

this.
    • 




  • 

Neither of the above solves both at the same time, yet independently, both

require non-trivial changes to BU's and other formats, as well as to the

handling of SA's and IPSEC.
    • 




The obvious solution is to address both:


    


  • 

Privacy
    • 




  • 

Address ownership
    • 




In one common mechanism.


I suggest it be based on HIP:


    


  • 

For all the cases at hand (v6 based) the HIP handshake provides for a very

good and DOS-resistant sequence.
    • 




  • 

For new application layer cases (hinted at by PBK, and applicable to P2P,

for example), the sequence must not be left up to the application. This

may be easier to do with TCP in which existing frameworks could be extended

(BEEP, TLS), but not immediately obvious how to accomplish it for UDP traffic.

SCTP is another matter.
    • 




-- GabrielMontenegro

- 18 Mar, 2001 - 12:40:30


 






--------------6671185CAB32645A5EC3C3B5
Content-Type: text/html; charset=us-ascii;
 name="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html"
Content-Disposition: inline;
 filename="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html"
Content-Transfer-Encoding: 7bit




   
   
    TWiki . Main . ProposalToSolveAddressOwnershipAndPrivacyForMipV6  





Statistical Uniqueness and Cryptographic Verifiability




The Need for a Common Solution

The idea is to propose one common mechanism that can solve two problems
dealt with in AddressOwnershipAndPrivacyForMipV6:

    

  • 
address ownership: Given the different ways of altering routing information,
and in particular, binding updates received at a correspondent node, how
does this CN decide if it should heed it?
    • 


  • 
privacy for MIPv6: Mobile IP allows a node to keep the same home address
as it changes its point of attachment to the network (care-of address or
COA).
    • 


There are proposals to solve each of the above. However, these proposals
require modifying Mobile IP v6 and/or IPSEC separately. Instead, this is
an attempt at using a common mechanism to achieve both of those goals.

This note does not look at the problem from the point of view of practical
Mobile IPv6 deployment, as it could be applied to, say, 3G or 4G wireless
networks.

Here, the assumption is that we have a network in which the nodes inherently
distrust each other, and in which a global or centralized PKI or KDC will
never be available. This is more akin to Peer-to-peer and to opportunistic
networking.

The goal is to arrive at some fundamental assumptions about trust on
top of which one can build some useful communication.


Statistically Unique Cryptographically Verifiable ID's (SUCV ID's)

How does a node preclude other parties (eavesdroppers, correspondent nodes,
etc) from gleaning too much information about its identity, or its home
address or its whereabouts?

The latter concern leads to ephemeral forms of addresses which typical
proposals base on cryptographic hashes. These identifiers (or EID's or
TMI's or HIT's) can have several interesting characteristics:

    

  • 
they are distinguishable from globally routable addresses
    • 


      

    • 
they are doled out from a separate TLA (TMI's)
      • 


    • 
they have a special form which may include an administrative prefix (HIT's)
      • 

    


  • 
because they are based on cryptographic hashes, they are statistically
unique
    • 




  • 
they are the hashes of a public component of a self-generated Public Key
(perhaps unsigned Diffie-Hellman)
    • 


So these identifiers have a strong cryptographic binding with their public
components (of their private-public keys). This is exactly the purpose
that certificates have. There is a catch, as always. The name or identity
must be communicated securely, otherwise there is a possibility of man-in-the-middle
attack (which is reduced if the initiator also signs the source address,
and if there is ingress filtering, etc).

Whereas in other applications of self-signed certificates it is possible
to secure this step, in the situation at hand (opportunistic security)
there is no practical way to do this. Instead, the initiator must communicate
its identity/name to the responder using in-band mechanisms. Barring this
detail, the initiator proves he owns this self-signed certificate by signing
stuff with his private key, and given the algorithmic characteristics of
the hash used, he further shows that his identity is statistically unique
(within bounds set approximately by the birthday paradox).

Let's call them Statistically Unique Cryptographically Verifiable
ID's, or SUCV ID's.

Because of this, once a CN obtains information about one of these identifiers,
it has a strong cryptographic assurance about which entity created it.
Not only that, it knows that this identifier is owned and used exclusively
by only one node in the universe: its peer in the current exchange. Thus,
it is safe to allow that peer to effect changes (via BU's, for example)
on how this address or identifier is routed to. Notice that with publically
routable addresses, this assurance is much harder to arrive at, given that
the address may be 'loaned' to (not owned by) the peer in question, perhaps
thanks to the good service of a friendly DHCP server, for example.

Despite the fact that currently there is no way to prove address ownership
in the Internet, these considerations lead to the following fundamental
assumption:

    

  • 
redirect operations are only allowed with SUCV ID's
    • 


The above constitutes perhaps the only rule that operates by default, allowing
any other more dangerous operation only if authorized by strong cryptographic
mechanisms


SUCV ID's versus SUCV Addresses

What should one use: pure identifiers with no routing significance or addresses?

For example, in the Mobile IPv6 case, a node could just start using
its current care-of address (CoA?)
as if it were its home address, and issue binding updates accordingly when
it moved in the future.

Of course, regular CoA?'s
will not qualify under the rule above, so it would mean it might be very
difficult (impossible?) for whoever sends this BU to prove that it 'owns'
that CoA?
address and can rightfully send redirects for it.

The most the node can do is to establish some cryptographic evidence
that it is sitting on that CoA?
address. And it is sitting on as opposed to owning , because
the former more accurately describes what is going on (from the CN's point
of view at least, and maybe also in reality).

With a CoA?
that is not an SUCV ID it is never evident to the CN that whoever was sitting
on that address actually owns it. At the very most, the CN's peer can prove
that at some point it was sitting on CoA?,
and later it can prove it is still the same node, but now sitting on another CoA?.

But it cannot prove ownership. It may have obtained the CoA?
from a DHCP server, for example. Ignoring this subtle distinction leads
to DOS and hijacking attacks.

Problems may also arise because of honest mistakes in configuration.
For example, say node A was originally sitting on CoA?,
and then moved on to CoA?'.
Suppose it then asks its CN's to redirect traffic to CoA?'.
In the meanwhile, the original CoA?
may have been assigned to another node B, perhaps by the DHCP server that
rightfully 'owns' that address. The result is that now traffic meant for
B has been redirected to A at its new location.

Relying on ingress filtering may limit the risk, but essentially, the
only way for a node to prove ownership of an identifier (in the absence
of any other centralized or global mechanism), is for it to prove that
it created this statistically unique series of bits.

Once you bite into using a 'home address' that is not really your home
address, then what you're really trying to do is to use some identity instead
of an address. And if you use identities that satisfy the conditions outlined
above, then you suddenly gain the tremendous advantage that anybody can
safely believe you when you claim you own that identity. Hence they can
safely heed your redirects when you say that your identity is now available
at some different CoA?
(and later at another). Furthermore, you do not rely on ingress filtering
to limit exposure.

The only advantage to using an address is that the data traffic need
not carry extra information in the packet to guarantee proper delivery
by routing. One could, perhaps try to achieve both purposes by creating CoA?'s
that can serve as both an address and as an SUCV ID.

This could be accomplished by:

    

  • 
using the top 64 bits from your routing prefix (as in rfc3041)
    • 


  • 
defining the bottom 64 bits as an SUCV ID
    • 


Using the resultant 128 bit field gives you an identifier that is routable,
avoiding the need for taking extra space in the packet by sending routing
options UNTIL you move and send a BU indicating this identifier is now
available at another CoA?.
This would leak information as to your whereabouts (or at least where you
were at some point) to eavesdroppers. The top 64 bits also tells them where
that identity began to be used, which could be very important information.

On the other hand, if you use a 'pure' SUCV ID (without any routing
significance), then your packets will always need extra information somewhere
to assure they are routed properly. Eavesdroppers may still know where
that identity is at any particular point in time. This is unavoidable.
But at least they will not know where (under what prefix) that identity
began to be used.


When to use SUCV ID's versus SUCV addresses

All in all, if one is more concerned about privacy then using an SUCV ID
with no routing significance seems preferable.

As often (perhaps even more), nodes are not particularly interested
in privacy. But they (rather their users) are definitely interested in
using Mobile IP v6 such that their BU's are heeded. Since this implies
proving address ownership, these nodes would want to use SUCV home addresses
. If they do so, CN's can safely heed BU's for these addresses, because
they have reasonable confidence that in doing so they are not unwittingly
participating in some DOS or hijacking attack. This follows because of
the SUCV property of the lower 64 bits within the address.

This SUCV-ness, by solving the address ownership problem, helps in both
cases:

    

  1. 
applications in which routing redirects need to be heeded (of which MIPv6
BU's are but one example), and
    2. 


  2. 
applications in which privacy is the main concern
    3. 


Only that in the former(no privacy, regular use) you want a routable address
for optimization as in an SUCV home address, and in the latter you want
an SUCV ID.

With CoA?'s
it is perhaps a little different in the sense that you nodes no not have
to prove ownership, so SUCV may not be as necessary. However, if privacy
is a concern then randomized CoA?'s
(SU CoA?,
without the CV part) are quite useful (as has been pointed out elsewhere).


Proposal for a Solution

Using these ID's or addresses depends on also communicating safely the
SUCV portion, and this, in turn is dependent on the packet sequencing,
etc. These concerns are not addresses at all in the PBK draft. On the other
hand, HIP includes mechanisms and detailed considerations in this regard
(protection against replay, DOS and MITM attacks). This is why this note
proposes that a solution be drafted based heavily on HIP:

We assume MIPv6

    

  • 
Use HIP identities, in particular, anonymous HI's
    • 


  • 
since we assume v6 here, use HIT the 128 bit long operational representation
of HI's
    • 


  • 
HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6
draft
    • 


TODO: continue this entire section!

-- GabrielMontenegro
- 18 Mar, 2001 - 13:22:02

 



--------------6671185CAB32645A5EC3C3B5--


--------------2D6239C521DC62A8DE8B3035--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 22:42:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04547
	for ; Mon, 19 Mar 2001 22:42:58 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27317;
	Mon, 19 Mar 2001 19:40:47 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27881;
	Mon, 19 Mar 2001 19:40:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K3dOIm018537
	for ; Mon, 19 Mar 2001 19:39:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2K3dOeK018536
	for mobile-ip-dist; Mon, 19 Mar 2001 19:39:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K3dFIm018529
	for ; Mon, 19 Mar 2001 19:39:15 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24752
	for ; Mon, 19 Mar 2001 19:39:14 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11842
	for ; Mon, 19 Mar 2001 20:39:13 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA16424
	for ; Mon, 19 Mar 2001 19:39:13 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2K3dB822105
	for ; Mon, 19 Mar 2001 19:39:11 -0800
X-mProtect:  Mon, 19 Mar 2001 19:39:11 -0800 Nokia Silicon Valley Messaging Protection
Received: from nokdab005149.americas.nokia.com (172.18.5.149, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd50CoAJ; Mon, 19 Mar 2001 19:39:02 PST
Message-ID: <3AB6D0CC.5F78D152@iprg.nokia.com>
Date: Mon, 19 Mar 2001 19:38:52 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Analysis of fastv6 draft, part II
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit



(CST)
Received: from daebh01nok.americas.nokia.com (unverified) by 
davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id 
 for 
;
 Fri, 16 Mar 2001 17:43:11 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 16 Mar 2001 17:43:11 -0600
Message-ID: 
To: mobile-ip@sunroof.eng.sun.com
Subject: Analysis of fastv6 draft, part II
Date: Fri, 16 Mar 2001 17:43:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"


Hello folks,

here is my second part of the analysis. It deals with the delay
surrounding
Neighbor Advertisement message and receiving BAck before the MN is able
to
use its IP address. This delay, equal to at least one RTT, could be
significant in certain links. 

Regards,

-Rajeev



Improving "IP connectivity" latency subsequent to handover
-----------------------------------------------------------

Note that it takes an "RTT-air" delay before the MN can transmit
packets with a new IP address. The reason for this delay is due to the
following, as 
currently specified in the fast handover design team draft:

a> MN has to send an NA message, and 
b> MN has to wait until it receives packets from NAR confirming using
the IP
address, or
c> MN receives a suitable error message indicating to the MN to resort
to
address 
   configuration

It would be very desirable to have the MN send IP packets without having
to
wait for
packets arriving from NAR. We outline two ways of achieving this below.

i> Subsequent to establishing a new L2 with NAR, the MN sends IP packets
directly to
   NAR. However, the IP source address in these packets is at best
tentative. Thus, the
   MN maintains a new flag called TENTATIVE in its ND cache entry. This
flag
is set to 
   ON prior to sending any IP packets on the new L2 with NAR. This flag
is
set to OFF 
   upon receiving positive confirmation. When this flag is set to ERROR,
the
MN MUST 
   NOT send any packets using the new IP address. 

   When the ND module receives any IP packets when TENTATIVE is ON, it
encapsulates the 
   IP packet in a new ND message type called Neighbor Cache Validation
and
does normal 
   transmission. This message type, which is described below, must
include
the MN's new 
   tentative IP address and its link-layer address. When the receiver
receives this ND 
   packet, its ND module treats the new message type addressing the
scenarios described 
   earlier (and also repeated below). 

i.a> if there is already an entry belonging to another node, NAR
generates
an error
   message, and discards the packet. In the error message, the NAR may
indicate to
   the MN to use old CoA or to initiate address configuration procedure.
The
NAR MAY
   forward packets addressed to old CoA. Once it receives an error
message,
the MN 
   MUST NOT send any more IP packets using the new CoA. It MUST set the
TENTATIVE 
   flag to ERROR. 

i.b> NAR is proxying the address for the MN. In this case, the NAR
overrides
its 
   existing cache entry with the information supplied by the MN. The NAR
MAY
generate 
   a unicast NA to the MN confirming its IP address. Alternatively, it
may
simply 
   forward any queued packets as an indication to confirm the new
address.
The NAR then 
   removes the encapsulation and forwards the inner IP packet towards
destination IP 
   address specified in the inner IP packet. Once the MN receives
confirmation that its
   IP address is valid, it sets the TENTATIVE flag to OFF, and proceeds
to
behave like
   any other node. It MAY send a Neighbor Advertisement message to all
nodes
on-link
   to advertise its presence.

i.c> NAR is proxying the address for some other node. This scenario is
not
valid since
   the relevant node would not use Neighbor Cache Validation message. 

ii> Using link-layer triggers. The NAR would determine that the MN is
present on the
   link by using link-layer triggers and forward any packets. Depending
on
the 
   destination address present in these IP packets, the MN would
determine
what IP
   address to use. This solution, however, relies on the presence of IP
packets at 
   NAR in order to enable the MN to use a confirmed IP address. Indeed,
one
such 
   packet could be the BAck. However, there are two issues to consider
here.

   First, if there are no packets to be forwarded to the MN (e.g., the
BAck
packet 
   is lost and there are no other packets), then the trigger is not very
useful. 
   What is important is that the MN should be able to use its IP
connectivity as 
   soon as the link becomes enabled, whether or not there are packets
waiting for 
   it to be delivered at NAR. The second issue is that standardization
of
link 
   triggers is presumably dependent on each link layer technology. Even
if
this is
   less of an issue, the former problem persists.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 19 22:50:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04829
	for ; Mon, 19 Mar 2001 22:50:24 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01935;
	Mon, 19 Mar 2001 19:48:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28596;
	Mon, 19 Mar 2001 19:48:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K3lAIm018563
	for ; Mon, 19 Mar 2001 19:47:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2K3lAEZ018562
	for mobile-ip-dist; Mon, 19 Mar 2001 19:47:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2K3l1Im018555
	for ; Mon, 19 Mar 2001 19:47:01 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12333
	for ; Mon, 19 Mar 2001 19:47:01 -0800 (PST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27496
	for ; Mon, 19 Mar 2001 19:46:59 -0800 (PST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 19 Mar 2001 22:46:58 -0500
Message-ID: 
From: George Tsirtsis 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Analysis of fastv6 draft, part II
Date: Mon, 19 Mar 2001 22:46:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Rajeev,

Could you please send me part I of this? I never got it...


Thanks
George

-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
Sent: Tuesday, March 20, 2001 3:39 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Analysis of fastv6 draft, part II




(CST)
Received: from daebh01nok.americas.nokia.com (unverified) by 
davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id 
 for 
;
 Fri, 16 Mar 2001 17:43:11 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 16 Mar 2001 17:43:11 -0600
Message-ID: 
To: mobile-ip@sunroof.eng.sun.com
Subject: Analysis of fastv6 draft, part II
Date: Fri, 16 Mar 2001 17:43:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"


Hello folks,

here is my second part of the analysis. It deals with the delay
surrounding
Neighbor Advertisement message and receiving BAck before the MN is able
to
use its IP address. This delay, equal to at least one RTT, could be
significant in certain links. 

Regards,

-Rajeev



Improving "IP connectivity" latency subsequent to handover
-----------------------------------------------------------

Note that it takes an "RTT-air" delay before the MN can transmit
packets with a new IP address. The reason for this delay is due to the
following, as 
currently specified in the fast handover design team draft:

a> MN has to send an NA message, and 
b> MN has to wait until it receives packets from NAR confirming using
the IP
address, or
c> MN receives a suitable error message indicating to the MN to resort
to
address 
   configuration

It would be very desirable to have the MN send IP packets without having
to
wait for
packets arriving from NAR. We outline two ways of achieving this below.

i> Subsequent to establishing a new L2 with NAR, the MN sends IP packets
directly to
   NAR. However, the IP source address in these packets is at best
tentative. Thus, the
   MN maintains a new flag called TENTATIVE in its ND cache entry. This
flag
is set to 
   ON prior to sending any IP packets on the new L2 with NAR. This flag
is
set to OFF 
   upon receiving positive confirmation. When this flag is set to ERROR,
the
MN MUST 
   NOT send any packets using the new IP address. 

   When the ND module receives any IP packets when TENTATIVE is ON, it
encapsulates the 
   IP packet in a new ND message type called Neighbor Cache Validation
and
does normal 
   transmission. This message type, which is described below, must
include
the MN's new 
   tentative IP address and its link-layer address. When the receiver
receives this ND 
   packet, its ND module treats the new message type addressing the
scenarios described 
   earlier (and also repeated below). 

i.a> if there is already an entry belonging to another node, NAR
generates
an error
   message, and discards the packet. In the error message, the NAR may
indicate to
   the MN to use old CoA or to initiate address configuration procedure.
The
NAR MAY
   forward packets addressed to old CoA. Once it receives an error
message,
the MN 
   MUST NOT send any more IP packets using the new CoA. It MUST set the
TENTATIVE 
   flag to ERROR. 

i.b> NAR is proxying the address for the MN. In this case, the NAR
overrides
its 
   existing cache entry with the information supplied by the MN. The NAR
MAY
generate 
   a unicast NA to the MN confirming its IP address. Alternatively, it
may
simply 
   forward any queued packets as an indication to confirm the new
address.
The NAR then 
   removes the encapsulation and forwards the inner IP packet towards
destination IP 
   address specified in the inner IP packet. Once the MN receives
confirmation that its
   IP address is valid, it sets the TENTATIVE flag to OFF, and proceeds
to
behave like
   any other node. It MAY send a Neighbor Advertisement message to all
nodes
on-link
   to advertise its presence.

i.c> NAR is proxying the address for some other node. This scenario is
not
valid since
   the relevant node would not use Neighbor Cache Validation message. 

ii> Using link-layer triggers. The NAR would determine that the MN is
present on the
   link by using link-layer triggers and forward any packets. Depending
on
the 
   destination address present in these IP packets, the MN would
determine
what IP
   address to use. This solution, however, relies on the presence of IP
packets at 
   NAR in order to enable the MN to use a confirmed IP address. Indeed,
one
such 
   packet could be the BAck. However, there are two issues to consider
here.

   First, if there are no packets to be forwarded to the MN (e.g., the
BAck
packet 
   is lost and there are no other packets), then the trigger is not very
useful. 
   What is important is that the MN should be able to use its IP
connectivity as 
   soon as the link becomes enabled, whether or not there are packets
waiting for 
   it to be delivered at NAR. The second issue is that standardization
of
link 
   triggers is presumably dependent on each link layer technology. Even
if
this is
   less of an issue, the former problem persists.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 06:06:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00819
	for ; Tue, 20 Mar 2001 06:06:26 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05632;
	Tue, 20 Mar 2001 02:58:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23863;
	Tue, 20 Mar 2001 02:57:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KAujIm019016
	for ; Tue, 20 Mar 2001 02:56:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KAujFm019015
	for mobile-ip-dist; Tue, 20 Mar 2001 02:56:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KAuaIm019008
	for ; Tue, 20 Mar 2001 02:56:36 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02952
	for ; Tue, 20 Mar 2001 02:56:35 -0800 (PST)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA12683
	for ; Tue, 20 Mar 2001 02:56:34 -0800 (PST)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 11:56:20 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD0C@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 
To: "'mobile-ip@sunroof.eng.sun.com'" ,
        Claude Castelluccia 
Subject: RE: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-0
	0.txt
Date: Tue, 20 Mar 2001 11:38:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2KAubIm019009
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id CAA05632
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA00819

Hello,

You know the movement of the mobile node with regard to its home network if
you know well its home address and the location of its home network.
If the home address belongs to a virtual network or if at every new
communication it uses the address obtained in the visited network as a
source address (as specified in draft-kassi-mobileip-dmi-00.txt) you can
know that the mobile node is in movement but without having a point of
departure. So in these cases, the mobile node is never at home or the
location of its home network is not well known.

Regards,

Kassi

-----Message d'origine-----
De : Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]
Envoyé : lundi 19 mars 2001 17:56
À : Claude Castelluccia
Cc : MobileIP Mailing List
Objet : [mobile-ip] Comments to
draft-castelluccia-mobileip-privacy-00.txt


Claude,

Here are some half-baked comments to your draft
draft-castelluccia-mobileip-privacy-00.txt

Firstly, I don't immediately see the usability of TMI instead
of just dropping the Home Address altogether, as I suggest
(among other things) in my Homeless Mobile IPv6 draft,
  draft-nikander-mobileip-homelessv6-01.txt

That is, if you use IPsec, you don't need home 
addresses and therefore the home address
destination option is useless.  On the other hand, if
IPsec is not used, the home address destination option
may be faked, and its only use is to try to find out the
supposedly right socket that should receive the packet.
However, if there exists an entry in the Binding Cache,
you can use that entry to look up the right home address
anyway, and therefore you don't need the home address.
Thus, the only reason for sending a home address in the
Home Address Destiation Option is to use it for a Binding
Update.  But then again, you would be using Ipsec....
Ok, I admit that there is the case where you do not or
cannot send a BU but you still want to use your CoA
as the source address and home address in the dest opt.
However, the only reason for that is ingress filtering,
which is broken IMHO anyway.

Secondly, the method that you propose to create TMIs 
actually largely defeats your purpose.  That is, if you know
the home address, you can easily calculate the TMI, and you
can still follow the communications as easily as if you
were using the home address.  This even applies to the
subsequently generated TMIs.

What comes to security, I think that using TMIs would
make it even harder to authorize BUs.  In one way, when
a MN is the client and sends a TMI, it is no different
from e.g. PBK EIDs.  If they are clearly given a separate
address space, as you tentatively suggest, then the
problem might disappear.  However, if you allow overlapping
between TMIs and genuine home addresses, you actually
make it very easy to steal traffic destined to specific
home addresses unless you solve the address ownership problem.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 08:01:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04248
	for ; Tue, 20 Mar 2001 08:01:51 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA26780;
	Tue, 20 Mar 2001 04:59:14 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06752;
	Tue, 20 Mar 2001 04:59:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KCvxIm019198
	for ; Tue, 20 Mar 2001 04:58:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KCvxem019197
	for mobile-ip-dist; Tue, 20 Mar 2001 04:57:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KCvoIm019190
	for ; Tue, 20 Mar 2001 04:57:50 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15287
	for ; Tue, 20 Mar 2001 04:57:49 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28113
	for ; Tue, 20 Mar 2001 04:57:47 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id NAA29932;
	Tue, 20 Mar 2001 13:57:43 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id NAA10122;
	Tue, 20 Mar 2001 13:56:41 +0100 (MET)
Message-ID: <3AB75389.25077265@inrialpes.fr>
Date: Tue, 20 Mar 2001 13:56:41 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com
Subject: Re: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
References: <3AB63A39.49928755@nomadiclab.com>
Content-Type: multipart/alternative;
 boundary="------------FF571E0EE696BD6BF8D6309C"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------FF571E0EE696BD6BF8D6309C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello Pekka and thanks for your comments.

Pekka Nikander wrote:

> Claude,
>
> Here are some half-baked comments to your draft
> draft-castelluccia-mobileip-privacy-00.txt
>
> Firstly, I don't immediately see the usability of TMI instead
> of just dropping the Home Address altogether, as I suggest
> (among other things) in my Homeless Mobile IPv6 draft,
>   draft-nikander-mobileip-homelessv6-01.txt

The reasons for not dropping the Home Address altogether
are the same that the reasons why we do not encrypt the Home Address
option.
There were some discussions about this issues few weeks ago on the
mailing list...
The reasons of keeping the Home Address (in cleartext) is:
- because IPSec uses it to locate the SA...if you remove the Home
Address
option you basically needs to use the CoA and since this CoA changes you

have to reestablished the SA each time you move...
- because some firewalls use it to perform some kind of filtering...

>
> That is, if you use IPsec, you don't need home
> addresses and therefore the home address
> destination option is useless.  On the other hand, if
> IPsec is not used, the home address destination option
> may be faked, and its only use is to try to find out the
> supposedly right socket that should receive the packet.
> However, if there exists an entry in the Binding Cache,
> you can use that entry to look up the right home address
> anyway, and therefore you don't need the home address.
> Thus, the only reason for sending a home address in the
> Home Address Destiation Option is to use it for a Binding
> Update.  But then again, you would be using Ipsec....
> Ok, I admit that there is the case where you do not or
> cannot send a BU but you still want to use your CoA
> as the source address and home address in the dest opt.
> However, the only reason for that is ingress filtering,
> which is broken IMHO anyway.
>
> Secondly, the method that you propose to create TMIs
> actually largely defeats your purpose.  That is, if you know
> the home address, you can easily calculate the TMI, and you
> can still follow the communications as easily as if you
> were using the home address.  This even applies to the
> subsequently generated TMIs.
>

In the draft  we suggest to generate the TMI as follows:
new TMI = MD5 ( Home address | current TMI),

if the current TMI is initialized with a random value, you won't be able
to
calculate the TMI even if you know the Home Address...
However if you know the current TMI and the home address, you will
be able to compute the next TMI....

We should probably use something like that:

new TMI = MD5 ( Home address | current TMI | random value),

thanks ! We will update the draft...

>
> What comes to security, I think that using TMIs would
> make it even harder to authorize BUs.  In one way, when
> a MN is the client and sends a TMI, it is no different

I am not sure...this depends the address owernship mechanism that
will be used...

>
> from e.g. PBK EIDs.  If they are clearly given a separate
> address space, as you tentatively suggest, then the
> problem might disappear.  However, if you allow overlapping
> between TMIs and genuine home addresses, you actually
> make it very easy to steal traffic destined to specific
> home addresses unless you solve the address ownership problem.

we have some ideas on how to do that....

thanks again for your comments,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------FF571E0EE696BD6BF8D6309C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello Pekka and thanks for your comments.

Pekka Nikander wrote:

Claude,

Here are some half-baked comments to your draft

draft-castelluccia-mobileip-privacy-00.txt

Firstly, I don't immediately see the usability of TMI instead

of just dropping the Home Address altogether, as I suggest

(among other things) in my Homeless Mobile IPv6 draft,

  draft-nikander-mobileip-homelessv6-01.txt

The reasons for not dropping the Home Address altogether

are the same that the reasons why we do not encrypt the Home Address
option.

There were some discussions about this issues few weeks ago on the
mailing list...

The reasons of keeping the Home Address (in cleartext) is:

- because IPSec uses it to locate the SA...if you remove the Home Address

option you basically needs to use the CoA and since this CoA changes
you

have to reestablished the SA each time you move...

- because some firewalls use it to perform some kind of filtering...

 

That is, if you use IPsec, you don't need home

addresses and therefore the home address

destination option is useless.  On the other hand, if

IPsec is not used, the home address destination option

may be faked, and its only use is to try to find out the

supposedly right socket that should receive the packet.

However, if there exists an entry in the Binding Cache,

you can use that entry to look up the right home address

anyway, and therefore you don't need the home address.

Thus, the only reason for sending a home address in the

Home Address Destiation Option is to use it for a Binding

Update.  But then again, you would be using Ipsec....

Ok, I admit that there is the case where you do not or

cannot send a BU but you still want to use your CoA

as the source address and home address in the dest opt.

However, the only reason for that is ingress filtering,

which is broken IMHO anyway.

Secondly, the method that you propose to create TMIs

actually largely defeats your purpose.  That is, if you know

the home address, you can easily calculate the TMI, and you

can still follow the communications as easily as if you

were using the home address.  This even applies to the

subsequently generated TMIs.

 

In the draft  we suggest to generate the TMI as follows:

new TMI = MD5 ( Home address | current TMI),

if the current TMI is initialized with a random value, you won't be
able to

calculate the TMI even if you know the Home Address...

However if you know the current TMI and the home address, you will

be able to compute the next TMI....

We should probably use something like that:

new TMI = MD5 ( Home address | current TMI | random value),

thanks ! We will update the draft...

 

What comes to security, I think that using TMIs would

make it even harder to authorize BUs.  In one way, when

a MN is the client and sends a TMI, it is no different

I am not sure...this depends the address owernship mechanism that

will be used...

 

from e.g. PBK EIDs.  If they are clearly given a separate

address space, as you tentatively suggest, then the

problem might disappear.  However, if you allow overlapping

between TMIs and genuine home addresses, you actually

make it very easy to steal traffic destined to specific

home addresses unless you solve the address ownership problem.

we have some ideas on how to do that....

thanks again for your comments,

Claude.

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------FF571E0EE696BD6BF8D6309C--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 08:13:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04592
	for ; Tue, 20 Mar 2001 08:13:32 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05214;
	Tue, 20 Mar 2001 05:11:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08416;
	Tue, 20 Mar 2001 05:11:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KDAVIm019237
	for ; Tue, 20 Mar 2001 05:10:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KDAUvQ019236
	for mobile-ip-dist; Tue, 20 Mar 2001 05:10:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KDALIm019229
	for ; Tue, 20 Mar 2001 05:10:22 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00162
	for ; Tue, 20 Mar 2001 05:10:20 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08711
	for ; Tue, 20 Mar 2001 05:10:19 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id OAA00443
	for ; Tue, 20 Mar 2001 14:10:18 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id OAA10138
	for ; Tue, 20 Mar 2001 14:09:16 +0100 (MET)
Message-ID: <3AB7567B.F6F60B9E@inrialpes.fr>
Date: Tue, 20 Mar 2001 14:09:16 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBCA2@esealnt448.al.sw.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------CD79643FD2B99B4D50030F45"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------CD79643FD2B99B4D50030F45
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

>
> > I feel that the group would benefit infinetely if the specs merge...
> >
>         => "Merging" is not a goal. The goal should be to highlight
>         what's missing in the current draft (HMIPv6) and if that
>         missing fuctionality is stated somewhere else then merging
>         makes sense. So far we haven't been given a good technical
>         reason. The complexity of mobility management as you mention
>         above does not imply the need for a multi-level hiearchy.
>         It is solved with the single level one in HMIPv6.
>

I agree with Hesham...

Actually I do no mind merging if that makes sense technically.
What is the goal of the merge?
If there is an other proposal tomorrow will we have to merge too?

We should merge only if this makes sense technically otherwise we might
end up with a monster because the 2 approaches are quite different ....

A better approach might be:
- define the requirements
- evaluate HMIPv6 and Regv6 against these requirements
- and then decide whether it makes sense to merge or not...

I think this is the only way to make some progress...

regards,

Claude.



--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------CD79643FD2B99B4D50030F45
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Hesham Soliman (ERA)" wrote:

 

> I feel that the group would benefit infinetely if the specs merge...

>

        => "Merging" is not a goal.
The goal should be to highlight

        what's missing in the current
draft (HMIPv6) and if that

        missing fuctionality is
stated somewhere else then merging

        makes sense. So far we haven't
been given a good technical

        reason. The complexity of
mobility management as you mention

        above does not imply the
need for a multi-level hiearchy.

        It is solved with the single
level one in HMIPv6.

 




I agree with Hesham...

Actually I do no mind merging if that makes sense technically.

What is the goal of the merge?

If there is an other proposal tomorrow will we have to merge too?

We should merge only if this makes sense technically otherwise we might

end up with a monster because the 2 approaches are quite different
....

A better approach might be:

- define the requirements

- evaluate HMIPv6 and Regv6 against these requirements

- and then decide whether it makes sense to merge or not...

I think this is the only way to make some progress...

regards,

Claude.

 

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------CD79643FD2B99B4D50030F45--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 09:50:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07941
	for ; Tue, 20 Mar 2001 09:50:05 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08150;
	Tue, 20 Mar 2001 06:48:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11512;
	Tue, 20 Mar 2001 06:48:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KEkVIm019295
	for ; Tue, 20 Mar 2001 06:46:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KEkUZu019294
	for mobile-ip-dist; Tue, 20 Mar 2001 06:46:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KEkLIm019287
	for ; Tue, 20 Mar 2001 06:46:22 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11338
	for ; Tue, 20 Mar 2001 06:46:19 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21824
	for ; Tue, 20 Mar 2001 06:46:18 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 20 Mar 2001 08:32:27 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 20 Mar 2001 08:32:19 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301934F58@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Tue, 20 Mar 2001 08:32:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B14A.90007820"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B14A.90007820
Content-Type: text/plain;
	charset="iso-8859-1"

Claude,
 
More comments on your privacy draft:
 
http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html
 
 
Generally it seems to me that your solution is quite complex for what it is
trying to solve - bang for the buck.
 
You do not give any reasons for why simply dynamically allocating an
anonymous home address is not sufficient. How can someone track someone if
they do not know their IP address? If someone is concerned about previous
communications they could simple refresh with a new anonymous address on
each communication.
 
You also indicate that IPSEC will have to change in order to use ESP as a
protection mechanisms. This is a pretty lame excuse for your solution in
that your solution proposes changes to both ESP and MIP. 
 
In short, I don't like and I won't support it. I re-iterate it is far too
complex for what it is providing.
 
I do not see why these other proposals for handling this particular problem
are not sufficient as is or with some relatively minor work to security.
 
respectfully,
 
Glenn
 
 
 
 


 


------_=_NextPart_001_01C0B14A.90007820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Claude,


 


More=20
comments on your privacy draft:


 


http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html


 


Generally it seems to me that your solution =
is quite=20
complex for what it is trying to solve - bang for the=20
buck.


 


You do=20
not give any reasons for why simply dynamically allocating an =
anonymous=20
home address is not sufficient. How can someone track someone if they =
do not=20
know their IP address? If someone is concerned about previous =
communications=20
they could simple refresh with a new anonymous address on each=20
communication.


 


You=20
also indicate that IPSEC will have to change in order to use ESP as a =
protection=20
mechanisms. This is a pretty lame excuse for your solution in that your =
solution=20
proposes changes to both ESP and MIP. 


 


In=20
short, I don't like and I won't support it. I re-iterate it is far too =
complex=20
for what it is providing.


 


I do=20
not see why these other proposals for handling this particular problem =
are not=20
sufficient as is or with some relatively minor work to=20
security.


 


respectfully,


 


Glenn


 


 


 


 



  

 


------_=_NextPart_001_01C0B14A.90007820--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 10:02:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08336
	for ; Tue, 20 Mar 2001 10:02:29 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28867;
	Tue, 20 Mar 2001 07:00:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22202;
	Tue, 20 Mar 2001 07:00:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KEw6Im019323
	for ; Tue, 20 Mar 2001 06:58:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KEw5gS019322
	for mobile-ip-dist; Tue, 20 Mar 2001 06:58:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KEvuIm019315
	for ; Tue, 20 Mar 2001 06:57:57 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20038
	for ; Tue, 20 Mar 2001 06:57:57 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA06833;
	Tue, 20 Mar 2001 06:57:54 -0800 (PST)
From: James Kempf 
Message-Id: <200103201457.GAA06833@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 08:57:45 -0700
To: , 
Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Eunsoo,

>I guess your 'trigger' includes information of the IP address or the L2
>address of the new FA or the old FA or something similar.
>That means it is not just a signal saying that the link quality is not good
>enough or that the MN should change the attachment point.
>

We do not have a comprehensive presentation of the link layer triggers
in the current draft, we intend to fix that in the next draft. As you
say, there is a need in a few cases to have some data available with
the link layer trigger, in others, just a trigger is enough.

>What would be then the design team's plan for the cases not covered by the
>schemes of the draft?

If there are some cases that you feel correspond to existing link layers
that are not covered, then please send them. We are interested in covering
existing link layers that have support. Base RFC 2002 does a fine job
if there is no support. We have tried to abstract existing link layer
support based on our knowledge of it, but we may have missed something,
of course.

		jak
>Thanks.
>
>Eunsoo
>
>----- Original Message -----
>From: "James Kempf" 
>To: ; 
>Cc: "Eunsoo Shim" 
>Sent: Monday, March 19, 2001 12:15 PM
>Subject: Re: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
>
>
>> Eunsoo,
>>
>> There was never any intent for each solution to cover all cases. So, if
>> the particular link layer does not provide a source trigger at the
>> old FA or a trigger on the mobile node, then the NAMONC solution would
>> not be used. Similarly, if no source trigger is available on the old FA
>> and no target trigger is available on the new FA, then the NIMOT solution
>> would not be used.
>>
>> jak
>>
>> >It seems to me the draft covers the following cases:
>> >1) The old FA(or AR) knows the IP address of the new FA while the MN is
>> >attached to the old FA.
>> >2) The old BS knows the L2 address of the new BS while the MN is attached
>to
>> >the old BS
>> >3) The new FA knows the IP address of the old FA before the MN registers
>> >with the new FA (reactive case)
>> >
>> >I wonder whether these cases are all we need to cover in the wireless IP
>> >world.
>> >In particular, what is the solution for a fast handoff that results in a
>> >similar latency to NAMONC in the case where the assumptions of 1) and 2)
>are
>> >not vaild?
>> >
>> >Regards,
>> >
>> >Eunsoo
>> >
>> >----- Original Message -----
>> >From: "Karim El-Malki (ERA)" 
>> >To: ; "'Koichi Ishibashi'"
>> >
>> >Sent: Friday, March 09, 2001 1:19 PM
>> >Subject: RE: [mobile-ip] Fast Handoffs (IPv4 & IPv6)
>> >
>> >
>> >> Hello
>> >>
>> >> > Here, I am confusing.
>> >> > The fast handoff for Mobile IPv4 draft (draft-ietf-mobileip-
>> >> > lowlatencyhandoffs-v4-00.txt) proposes a pro-active handoff.
>> >>
>> >> Low latency Handoffs proposes two methods:
>> >>
>> >> - Network Assisted, Mobile and Network Controlled (NAMONC) Handoff
>> >> - Network Initiated, Mobile Terminated (NIMOT) Handoff
>> >>
>> >> This is the combination of two existing drafts.
>> >> The first method comes from draft-elmalki-mobileip-fast-handoffs-03
>> >> and the second is from draft-calhoun-mobileip-proactive-fa-03.
>> >>
>> >> > In this draft, the Registration procedure will be done pro-actively.
>> >> > On the other hand, the fast handoff for Mobile IPv6 draft proposes
>> >> > another mechanism.
>> >>
>> >> The v4 and v6 drafts do not propose completely different mechanisms.
>> >> You can run a similar handoff procedure in v4 and v6. However you may
>> >> be pointing to a NIMOT-like approach in v6?
>> >>
>> >> > And I have another confusion.
>> >> > When I apply to the fast handoff for Mobile IPv4 (pro-active handoff)
>> >> > without the bi-casting, the loss of packets during the transition
>> >> > between networks will be eliminated.
>> >>
>> >> If you don't use bicasting (independently of the method supported) then
>> >> achieving a loss-less v4 handoff depends on when the MN actually
>> >disconnects
>> >> from the old FA and connects to the new one, if buffering is available
>> >etc.
>> >> This needs more looking into and hopefully we'll get some discussion
>going
>> >> at this IETF.
>> >>
>> >> Regards
>> >> /Karim
>> >>
>> >
>> >
>>
>>
>>
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 10:05:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08467
	for ; Tue, 20 Mar 2001 10:05:38 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02418;
	Tue, 20 Mar 2001 07:04:00 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21554;
	Tue, 20 Mar 2001 07:03:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KF2JIm019351
	for ; Tue, 20 Mar 2001 07:02:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KF2IM9019350
	for mobile-ip-dist; Tue, 20 Mar 2001 07:02:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KF28Im019340
	for ; Tue, 20 Mar 2001 07:02:08 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22470
	for ; Tue, 20 Mar 2001 07:01:54 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04255
	for ; Tue, 20 Mar 2001 07:01:53 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 20 Mar 2001 08:56:40 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 20 Mar 2001 09:01:45 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301935003@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Tue, 20 Mar 2001 09:01:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B14E.ACD30590"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B14E.ACD30590
Content-Type: text/plain;
	charset="iso-8859-1"

Whoops, one more time - wrong link and an additional question:
 
How do you propose to protect against eavesdroppers who discern the COA from
previous communications?
 


Claude,
 
More comments on your privacy draft:
 
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-p
rivacy-00.txt
 
 
Generally it seems to me that your solution is quite complex for what it is
trying to solve - bang for the buck.
 
You do not give any reasons for why simply dynamically allocating an
anonymous home address is not sufficient. How can someone track someone if
they do not know their IP address? If someone is concerned about previous
communications they could simple refresh with a new anonymous address on
each communication.
 
You also indicate that IPSEC will have to change in order to use ESP as a
protection mechanisms. This is a pretty lame excuse for your solution in
that your solution proposes changes to both ESP and MIP. 
 
In short, I don't like and I won't support it. I re-iterate it is far too
complex for what it is providing.
 
I do not see why these other proposals for handling this particular problem
are not sufficient as is or with some relatively minor work to security.
 
respectfully,
 
Glenn
 
 
 
 


 


------_=_NextPart_001_01C0B14E.ACD30590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Whoops, one more time - wrong link and an =
additional=20
question:


 


How do=20
you propose to protect against eavesdroppers who discern the COA from =
previous=20
communications?


 



  

  
Claude,

  
 

  
More=20
  comments on your privacy draft:

  
 

  
http://www.inrialpes.fr/planete/people/ccaste=
l/draft-castelluccia-mobileip-privacy-00.txt

  
 

  
Generally it seems to me that your =
solution is quite=20
  complex for what it is trying to solve - bang for the=20
  buck.

  
 

  
You=20
  do not give any reasons for why simply dynamically allocating an =

  anonymous home address is not sufficient. How can someone track =
someone if=20
  they do not know their IP address? If someone is concerned about =
previous=20
  communications they could simple refresh with a new anonymous address =
on each=20
  communication.

  
 

  
You=20
  also indicate that IPSEC will have to change in order to use ESP as a =

  protection mechanisms. This is a pretty lame excuse for your solution =
in that=20
  your solution proposes changes to both ESP and MIP. =


  
 

  
In=20
  short, I don't like and I won't support it. I re-iterate it is far =
too complex=20
  for what it is providing.

  
 

  
I do=20
  not see why these other proposals for handling this particular =
problem are not=20
  sufficient as is or with some relatively minor work to=20
  security.

  
 

  
respectfully,

  
 

  
Glenn

  
 

  
 

  
 

  
 

  

    

 
=


------_=_NextPart_001_01C0B14E.ACD30590--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 10:09:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08652
	for ; Tue, 20 Mar 2001 10:09:44 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06603;
	Tue, 20 Mar 2001 07:08:26 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23106;
	Tue, 20 Mar 2001 07:08:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KF62Im019381
	for ; Tue, 20 Mar 2001 07:06:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KF61Gc019380
	for mobile-ip-dist; Tue, 20 Mar 2001 07:06:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KF5jIm019373
	for ; Tue, 20 Mar 2001 07:05:48 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23240
	for ; Tue, 20 Mar 2001 07:05:46 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04024
	for ; Tue, 20 Mar 2001 07:05:45 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id QAA05417
	for ; Tue, 20 Mar 2001 16:05:39 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id QAA21705
	for ; Tue, 20 Mar 2001 16:04:36 +0100 (MET)
Message-ID: <3AB77184.CEDDC6A6@inrialpes.fr>
Date: Tue, 20 Mar 2001 16:04:36 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] -HMIPv6 draft + Privacy draft-
References: <85AA7486A2C1D411BCA20000F8073E4301934F58@crchy271.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------A559DAC22280EF9742FF29DE"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------A559DAC22280EF9742FF29DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Gleen,

Glenn Morrow wrote:

> Claude,More comments on your privacy
> draft:http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html

I did not write this draft ;-) ...


> Generally it seems to me that your solution is quite complex for what
> it is trying to solve - bang for the buck.You do not give any reasons
> for why simply dynamically allocating an anonymous home address is not
> sufficient.

what is it an "anonymous home address"??? A TMI  ;-)

> How can someone track someone if they do not know their IP address?

I don't understand what you mean....

> If someone is concerned about previous communications they could
> simple refresh with a new anonymous address on each communication.You
> also indicate that IPSEC will have to change in order to use ESP as a
> protection mechanisms.

did I say that ?

> This is a pretty lame excuse for your solution in that your solution
> proposes changes to both ESP and MIP.

My draft does not talk about ESP at all...

> In short, I don't like and I won't support it. I re-iterate it is far
> too complex for what it is providing.I do not see why these other
> proposals for handling this particular problem are not sufficient as
> is or with some relatively minor work to security.

 what are the other proposals you are talking about?

Our proposal is actually very simple... I am really wondering whether
you've read the right draft ...

> respectfully,Glenn

thanks for your comments anyway,
regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------A559DAC22280EF9742FF29DE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hello Gleen,

Glenn Morrow wrote:

Claude,More
comments on your privacy draft:http://dailynews.yahoo.com/h/ap/20010319/hl/telemedicine_1.html

I did not write this draft ;-) ...

 

Generally
it seems to me that your solution is quite complex for what it is trying
to solve - bang for the buck.You
do not give any reasons for why simply dynamically allocating an anonymous
home address is not sufficient.

what is it an "anonymous home address"??? A TMI  ;-)

How
can someone track someone if they do not know their IP address?

I don't understand what you mean....

If
someone is concerned about previous communications they could simple refresh
with a new anonymous address on each communication.You
also indicate that IPSEC will have to change in order to use ESP as a protection
mechanisms.

did I say that ?

This
is a pretty lame excuse for your solution in that your solution proposes
changes to both ESP and MIP. 

My draft does not talk about ESP at all...

In
short, I don't like and I won't support it. I re-iterate it is far too
complex for what it is providing.I
do not see why these other proposals for handling this particular problem
are not sufficient as is or with some relatively minor work to security.




 what are the other proposals you are talking about?

Our proposal is actually very simple... I am really wondering whether
you've read the right draft ...

respectfully,Glenn

thanks for your comments anyway,

regards,

Claude.

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------A559DAC22280EF9742FF29DE--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 11:01:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10839
	for ; Tue, 20 Mar 2001 11:01:41 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24641;
	Tue, 20 Mar 2001 07:58:50 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02733;
	Tue, 20 Mar 2001 07:58:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KFvWIm019510
	for ; Tue, 20 Mar 2001 07:57:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KFvVjW019509
	for mobile-ip-dist; Tue, 20 Mar 2001 07:57:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KFvMIm019502
	for ; Tue, 20 Mar 2001 07:57:23 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02433
	for ; Tue, 20 Mar 2001 07:57:23 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23329
	for ; Tue, 20 Mar 2001 07:57:22 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 20 Mar 2001 09:51:09 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 20 Mar 2001 09:51:01 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4301935104@crchy271.us.nortel.com>
From: "Glenn Morrow" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
Date: Tue, 20 Mar 2001 09:51:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B155.8FA1B550"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B155.8FA1B550
Content-Type: text/plain;
	charset="iso-8859-1"


  

[Morrow, Glenn]
Generally it seems to me that your solution is quite complex for what it is
trying to solve - bang for the buck.You do not give any reasons for why
simply dynamically allocating an anonymous home address is not sufficient.

what is it an "anonymous home address"??? A TMI  ;-) 
[Morrow, Glenn ] 
An anonymous home address is an address that would be allocated similar to
how anonymous stateless autoconfiguration addresses are allocated.


[Morrow, Glenn ]  How can someone track someone if they do not know their IP
address?

I don't understand what you mean.... 
[Morrow, Glenn ] If you dynamically and anonymously allocate an address at
the home network then there is no long lasting association with a node and
this address. 


[Morrow, Glenn ]  If someone is concerned about previous communications they
could simple refresh with a new anonymous address on each communication.You
also indicate that IPSEC will have to change in order to use ESP as a
protection mechanisms.

did I say that ? 
[Morrow, Glenn ]  Quote:

   - HA option encryption: An other solution could be to encrypt the
   home address option. This solution is not satisfactory because
   (1) it would require to modify IPsec implementation (SA should then
   be indexed with the care-of address and therefore would need to be
   updated at each movement of the mobile node) and (2) it would make
   the usage of firewalls difficult (currently firewalls look at the
   home address option to perform some filtering). Futhermore this
   solution does not solve the problem of incoming packets that
   contain a routing header which reveals the home address.
 
[Morrow, Glenn ]  Quote:
This TMI might be used by the correspondent
   node to index the IPsec SA correspondent to the mobile and might be
   used by firewalls to do filtering.
 
Oh - so you want to change security anyway.

This is a pretty lame excuse for your solution in that your solution
proposes changes to both ESP and MIP. 

My draft does not talk about ESP at all... 
[Morrow, Glenn ] Claude, really - how would you encrypt the HA. I quote
again.
 
The home address option MUST be placed as follows:
      - After the routing header, if that header is present
      - Before the fragment header, if that header is present
      - Before the AH Header or ESP Header, if either one of those
      headers is present

 


[Morrow, Glenn ]  In short, I don't like and I won't support it. I
re-iterate it is far too complex for what it is providing.I do not see why
these other proposals for handling this particular problem are not
sufficient as is or with some relatively minor work to security.


 what are the other proposals you are talking about? 
[Morrow, Glenn ] More quotes:

 3. Possible solutions

   Several solutions are possible, all with their limitations:

   - IPv6 Privacy Extension: A solution could be to used the privacy
   extension described in [1] to configure the home address and
   the care-of addresses. While this solution represents a marked
   improvement over the standard address configuration methods [2],
   and should be used for the home and care-of addresses, we contend
   that this is not sufficient.  [1] causes nodes to generate
   global-scope addresses from interface identifiers that change over
   time, even in cases where the interface contains an embedded IEEE
   identifier. As a result if [1] is used to generate the home address,
   this address will change periodically but the network prefix (64
   highest bits) will remain unchanged. This network perfix can still
   reveal much information about the mobile node's identity to an
   eavesdropper. This mechanism described in [1] must be used for the
   home address and care-of address in Mobile IPv6 but one should not
   rely on it to get full privacy protection.


C. Castelluccia                                                 [Page 3]

Internet Draft        Privacy Extension for MIPv6        February,  2001


   - HA option encryption: An other solution could be to encrypt the
   home address option. This solution is not satisfactory because
   (1) it would require to modify IPsec implementation (SA should then
   be indexed with the care-of address and therefore would need to be
   updated at each movement of the mobile node) and (2) it would make
   the usage of firewalls difficult (currently firewalls look at the
   home address option to perform some filtering). Futhermore this
   solution does not solve the problem of incoming packets that
   contain a routing header which reveals the home address.

   - IPsec bi-directional Tunnel (mobile VPN): A solution could be to
   open a bi-directional IPsec tunnel between the mobile node and its
   home agent [3]. This solution has the following disadvantages: (1)
   addition of extra bandwidth (packets need to be encapsulated) and
   processing overhead, (2) the routing is suboptimal.


Our proposal is actually very simple... I am really wondering whether you've
read the right draft ... 
[Morrow, Glenn ] 

I sincerely hope the quotes reduce your wondering and hopefully your
wandering. Someone should give you a big KISS.

With less respect,

 Glenn

 


------_=_NextPart_001_01C0B155.8FA1B550
Content-Type: text/html;
	charset="iso-8859-1"










  

    

  

[Morrow, 
    Glenn]

    
Generally it seems to me that 
    your solution is quite complex for what it is trying to solve - bang for the 
    buck.You do not give any reasons for why simply 
    dynamically allocating an anonymous home address is not 
    sufficient.

  
what is it an "anonymous home address"??? A TMI  ;-) 
[Morrow, Glenn 
  ] 

  
An 
  anonymous home address is an address that would be allocated similar 
  to how anonymous stateless autoconfiguration addresses are 
  allocated.

  

[Morrow, Glenn 
    ]  How can someone track someone if they do not know their 
    IP address?
I don't understand what you 
  mean.... 
[Morrow, Glenn ] If you dynamically and 
  anonymously allocate an address at the home network then there is no long 
  lasting association with a node and this address.
  

[Morrow, Glenn 
    ]  If someone is concerned about previous communications 
    they could simple refresh with a new anonymous address on each 
    communication.You also indicate that IPSEC will 
    have to change in order to use ESP as a protection 
    mechanisms.

  
did I say that ? 
[Morrow, Glenn ]  Quote:

  
<!--StartFragment-->
   - HA 
  option encryption: An other solution could be to encrypt the
   
  home address option. This solution is not satisfactory because
   
  (1) it would require to modify IPsec implementation (SA 
  should then
   be indexed with the care-of address and therefore 
  would need to be
   updated at each movement of the mobile node) 
  and (2) it would make
   the usage of firewalls difficult 
  (currently firewalls look at the
   home address option to 
  perform some filtering). Futhermore this
   solution does not 
  solve the problem of incoming packets that
   contain a routing 
  header which reveals the home address.

  
 

  
[Morrow, Glenn ]  
  Quote:

  
<!--StartFragment-->This TMI 
  might be used by the correspondent
   node to index the IPsec SA 
  correspondent to the mobile and might be
   used by firewalls to 
  do filtering.
 

  
Oh - 
  so you want to change security anyway.

  
This is a 
    pretty lame excuse for your solution in that your solution proposes changes 
    to both ESP and MIP. 

  
My draft does not talk about ESP at all... 
[Morrow, Glenn ] Claude, 
  really - how would you encrypt the HA. I quote again.

  
 

  
<!--StartFragment-->The home address option 
  MUST be placed as follows:
      - After the 
  routing header, if that header is present
      - 
  Before the fragment header, if that header is 
  present
      - Before the AH Header or ESP 
  Header, if either one of those
      headers is 
  present

  
 

  

[Morrow, Glenn ]  In short, I 
    don't like and I won't support it. I re-iterate it is far too complex for 
    what it is providing.I do not see why these other 
    proposals for handling this particular problem are not sufficient as is or 
    with some relatively minor work to security.

  

 what are the other proposals you are talking about? 
[Morrow, Glenn 
  ] More quotes:

  
 <!--StartFragment-->3. Possible 
  solutions

   Several solutions are possible, all with their 
  limitations:

   - IPv6 Privacy Extension: A solution could be 
  to used the privacy
   extension described in [1] to configure 
  the home address and
   the care-of addresses. While this 
  solution represents a marked
   improvement over the standard 
  address configuration methods [2],
   and should be used for the 
  home and care-of addresses, we contend
   that this is not 
  sufficient.  [1] causes nodes to generate
   global-scope 
  addresses from interface identifiers that change over
   time, 
  even in cases where the interface contains an embedded IEEE
   
  identifier. As a result if [1] is used to generate the home 
  address,
   this address will change periodically but the network 
  prefix (64
   highest bits) will remain unchanged. This network 
  perfix can still
   reveal much information about the mobile 
  node's identity to an
   eavesdropper. This mechanism described 
  in [1] must be used for the
   home address and care-of address 
  in Mobile IPv6 but one should not
   rely on it to get full 
  privacy protection.


C. 
  Castelluccia                                                 
  [Page 3]

Internet Draft        
  Privacy Extension for MIPv6        
  February,  2001


   - HA option encryption: An other 
  solution could be to encrypt the
   home address option. This 
  solution is not satisfactory because
   (1) it would require to 
  modify IPsec implementation (SA should then
   be indexed with 
  the care-of address and therefore would need to be
   updated at 
  each movement of the mobile node) and (2) it would make
   the 
  usage of firewalls difficult (currently firewalls look at the
   
  home address option to perform some filtering). Futhermore 
  this
   solution does not solve the problem of incoming packets 
  that
   contain a routing header which reveals the home 
  address.

   - IPsec bi-directional Tunnel (mobile VPN): A 
  solution could be to
   open a bi-directional IPsec tunnel 
  between the mobile node and its
   home agent [3]. This solution 
  has the following disadvantages: (1)
   addition of extra 
  bandwidth (packets need to be encapsulated) and
   processing 
  overhead, (2) the routing is suboptimal.

  
Our proposal is actually very simple... I am really wondering whether 
  you've read the right draft ... 
[Morrow, Glenn ] 

  
I 
  sincerely hope the quotes reduce your wondering and hopefully your 
  wandering. Someone should give you a big KISS.

  
With 
  less respect,

 Glenn

  
 


------_=_NextPart_001_01C0B155.8FA1B550--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 11:07:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11103
	for ; Tue, 20 Mar 2001 11:07:39 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01650;
	Tue, 20 Mar 2001 08:05:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04475;
	Tue, 20 Mar 2001 08:05:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KG4LIm019539
	for ; Tue, 20 Mar 2001 08:04:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KG4LWL019538
	for mobile-ip-dist; Tue, 20 Mar 2001 08:04:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KG4CIm019531
	for ; Tue, 20 Mar 2001 08:04:13 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03921
	for ; Tue, 20 Mar 2001 08:04:13 -0800 (PST)
Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12560
	for ; Tue, 20 Mar 2001 08:04:11 -0800 (PST)
Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1])
	by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id RAA24466
	for ; Tue, 20 Mar 2001 17:04:11 +0100
Received: from bull.net (localhost [127.0.0.1])
	by isatis.frec.bull.fr (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA163690
	for ; Tue, 20 Mar 2001 17:04:09 +0100
Message-ID: <3AB77F78.2FD96207@bull.net>
Date: Tue, 20 Mar 2001 17:04:09 +0100
From: AIme Le-Rouzic 
Organization: Bull
X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3)
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> 
> The IESG has concerns about the draft's dependency on IPSEC AH to
> authenticate Binding Updates.

 Even if the protocol doesn't require IPSEC to protect BU and
 BA, MobileIPv6 must cohabitate with IPSEC and IKE to let the
 mobile user using MobileIPv6 to protect the datas by AH or
 ESP.  IPSEC is useful to protect all the packet and in
 particularly BU and BA.

 Best regards

-- 
     ________________________Aime LEROUZIC____________________________
     BULL S.A ECHIROLLES FRANCE      mailto:Aime.Lerouzic@frec.bull.fr
     http://www-frec.bull.com                tel: +33 (0)4 76 29 75 51
     Communications TCPIP                     http://intranet/lerouzic


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 12:20:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14311
	for ; Tue, 20 Mar 2001 12:20:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11939;
	Tue, 20 Mar 2001 09:18:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24367;
	Tue, 20 Mar 2001 09:18:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHHUIm019658
	for ; Tue, 20 Mar 2001 09:17:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KHHUjO019657
	for mobile-ip-dist; Tue, 20 Mar 2001 09:17:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KHHKIm019650
	for ; Tue, 20 Mar 2001 09:17:21 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05725
	for ; Tue, 20 Mar 2001 09:17:21 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09739
	for ; Tue, 20 Mar 2001 09:17:19 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2KHH7d07183
	for ; Tue, 20 Mar 2001 18:17:07 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Mar 20 18:17:04 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 18:17:06 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCA3@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Header Compression overhead in HMIPv6
Date: Tue, 20 Mar 2001 18:17:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

	Hello Rajeev, 

	IF context transfer is needed for HC, then it's a seamoby
	issue that I hope we don't get into here. 

> traffic, the flow may last as long as only 20 packets, 
> 
	=> You probably know HC more than me, but I checked
	with the HC experts and I was told that this is not 
	true. 3-4 packets in the worste case scenario is 
	what I've been told. 

	Regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 14:14:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19518
	for ; Tue, 20 Mar 2001 14:14:26 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00248;
	Tue, 20 Mar 2001 11:13:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05228;
	Tue, 20 Mar 2001 11:12:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJB7Im020006
	for ; Tue, 20 Mar 2001 11:11:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KJB6w6020005
	for mobile-ip-dist; Tue, 20 Mar 2001 11:11:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJAvIm019998
	for ; Tue, 20 Mar 2001 11:10:58 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21632
	for ; Tue, 20 Mar 2001 11:10:57 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09374
	for ; Tue, 20 Mar 2001 12:10:49 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06461
	for ; Tue, 20 Mar 2001 11:10:38 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KJAa405765
	for ; Tue, 20 Mar 2001 11:10:36 -0800
X-mProtect:  Tue, 20 Mar 2001 11:10:36 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdENHn2p; Tue, 20 Mar 2001 11:10:31 PST
Message-ID: <3AB7AB29.5441A43D@cs.ucl.ac.uk>
Date: Tue, 20 Mar 2001 11:10:33 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBCA2@esealnt448.al.sw.ericsson.se> <3AB7567B.F6F60B9E@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Claude,


>>
>> > I feel that the group would benefit infinetely if the specs
>> merge...
>> >
>>         => "Merging" is not a goal. The goal should be to highlight
>>         what's missing in the current draft (HMIPv6) and if that
>>         missing fuctionality is stated somewhere else then merging
>>         makes sense. So far we haven't been given a good technical
>>         reason. The complexity of mobility management as you mention
>>
>>         above does not imply the need for a multi-level hiearchy.
>>         It is solved with the single level one in HMIPv6.
>
>
> I agree with Hesham...
>
> Actually I do no mind merging if that makes sense technically.
> What is the goal of the merge?
> If there is an other proposal tomorrow will we have to merge too?
>

The issue that the WG has been looking over the RegReg and HMIP drafts
is, undoubtedly
hierarchical mobility, whether this is called regional, hierarchical,
tree-base n-ary, foo, for me (the other could comment further)
it is the same notion/idea.

Having read both drafts numerous times, I can see that one can fit
within the other if you wanted. Both you guys know that, I trust.

So to me it seems that the all-essential purpose is to get a strong
specification about hierarchical/regional (or regional/hierarchical just
in case one assumes that I am in favour of one of the two) mobility.
This is much better instead of trying to knock out each other as to who
has the a better spec. Both specs keep changing so much that they keep
the door of ambiguity and partiality wide open.

Instead of trying to knock the specs out individually, it seems to me
that it is in the in the interest of the community, and on the long run
of the hierarchical mobility, if the authors of both specs work
together, a single _well written_ spec comes out and becomes the object
of progress for the working group. Both specs today have had ambiguities
in their writing and I am sure we could spend the next 3 months trying
to understand what the authors intend to cover in the spec.

If a proposal comes out tomorrow as you stated, then I think that the
MIP WG is mature enough to evaluate its grounds for existence and if
need be merge the good ideas and their respective authors to the draft.
To me this is the fundamental reason why the constituency is called a
WORKING GROUP (emphasis on the word group). It is not about
individualism, be it a single individual or a company. This way
contribution to the group is much more comprehensive and focused, rather
than statements of authority....

The question is not whether we want to merge that too, but whether (if
the solution is neat) we are strong enough to admit that other people
can contribute nice solutions too, towards a better solution space, such
as hierarchical/regional mobility.

I think the above provide a sound justification for merging spec
solutions,


>
> We should merge only if this makes sense technically otherwise we
> might
> end up with a monster because the 2 approaches are quite different
> ....

the two approaches are quite different???? it depends on one's
definition of difference..... :)




>
>
> A better approach might be:
> - define the requirements
> - evaluate HMIPv6 and Regv6 against these requirements
> - and then decide whether it makes sense to merge or not...
>

Open the requirements box for hierachical mobility...

    what is it really...?   In a nutshell.. to provide a local
instantiation of the HA near the MN. How near...??? there can be a
measure for that

of course this needs to be secure, fault tolerant, low signalling load,
blah blah blah..

the rest of the so called "requirements" are just trying to make what
people preach about "DIFFERENT" schemes..

In all honesty....am I wrong here...???   :)))


Theo


UCL / Mobile systems



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 14:55:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21327
	for ; Tue, 20 Mar 2001 14:55:51 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09849;
	Tue, 20 Mar 2001 11:54:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14535;
	Tue, 20 Mar 2001 11:53:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJpuIm020051
	for ; Tue, 20 Mar 2001 11:51:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KJpt2o020050
	for mobile-ip-dist; Tue, 20 Mar 2001 11:51:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJpkIm020043
	for ; Tue, 20 Mar 2001 11:51:47 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21542
	for ; Tue, 20 Mar 2001 11:51:46 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20137
	for ; Tue, 20 Mar 2001 11:51:46 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29449
	for ; Tue, 20 Mar 2001 11:51:49 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACO01369;
	Tue, 20 Mar 2001 11:51:45 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00622; Tue, 20 Mar 2001 11:51:45 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15031.46288.964150.682721@thomasm-u1.cisco.com>
Date: Tue, 20 Mar 2001 11:51:44 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6 
In-Reply-To: <200103200046.f2K0k2A33587@givry.rennes.enst-bretagne.fr>
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
	<200103200046.f2K0k2A33587@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis Dupont writes:
 >    The IESG has concerns about the draft's dependency on IPSEC AH to
 >    authenticate Binding Updates.
 > 
 > => I'll be politically incorrect but it seems the real issue is
 > Mobile IPv6 relies on a mandatory mechanism (IPsec AH) which is
 > expensive to implement, ..., ie. many people want to kill it...
 > If this is the case why not to say it (oh! this would be politically
 > incorrect :-).
 
While the too expensive argument (for some metric
of expensive) has some appeal, the actual serious
issue is that authentication is not
*authorization*. That is, being able to assert an
identity does not in any way suggest what rights
and privileges I should gain given that identity.

The former is possibly a solvable (though
completely unproven), the latter would require
global coordination, treaties, etc, etc. I there
is high amount of desire to avoid those sorts of
implications if even vaguely plausible.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 14:56:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21420
	for ; Tue, 20 Mar 2001 14:56:55 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11353;
	Tue, 20 Mar 2001 11:55:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22235;
	Tue, 20 Mar 2001 11:55:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJsFIm020061
	for ; Tue, 20 Mar 2001 11:54:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KJsF6M020060
	for mobile-ip-dist; Tue, 20 Mar 2001 11:54:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJs5Im020053
	for ; Tue, 20 Mar 2001 11:54:06 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02100
	for ; Tue, 20 Mar 2001 11:54:05 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA15017;
	Tue, 20 Mar 2001 11:54:02 -0800 (PST)
From: James Kempf 
Message-Id: <200103201954.LAA15017@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 13:53:25 -0700
To: , 
Subject: RE: [mobile-ip] -HMIPv6 draft + Privacy draft-
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I'm having a hard time understanding why this is an issue. 

Seems to me that if you don't want anyone to get a handle on who you are,
don't register your address to your host name in DNS. 

Someone could still grovel through the routing tables to find out something, if
they could get a hold of them, but that would only trace you as far
as the BGP domain if the attacker were outside.

Is there something I'm missing? What's the requirement?

		jak
>
>  
>
>[Morrow, Glenn]
>Generally it seems to me that your solution is quite complex for what it is
>trying to solve - bang for the buck.You do not give any reasons for why
>simply dynamically allocating an anonymous home address is not sufficient.
>
>what is it an "anonymous home address"??? A TMI  ;-) 
>[Morrow, Glenn ] 
>An anonymous home address is an address that would be allocated similar to
>how anonymous stateless autoconfiguration addresses are allocated.
>
>
>[Morrow, Glenn ]  How can someone track someone if they do not know their IP
>address?
>
>I don't understand what you mean.... 
>[Morrow, Glenn ] If you dynamically and anonymously allocate an address at
>the home network then there is no long lasting association with a node and
>this address. 
>
>
>[Morrow, Glenn ]  If someone is concerned about previous communications they
>could simple refresh with a new anonymous address on each communication.You
>also indicate that IPSEC will have to change in order to use ESP as a
>protection mechanisms.
>
>did I say that ? 
>[Morrow, Glenn ]  Quote:
>
>   - HA option encryption: An other solution could be to encrypt the
>   home address option. This solution is not satisfactory because
>   (1) it would require to modify IPsec implementation (SA should then
>   be indexed with the care-of address and therefore would need to be
>   updated at each movement of the mobile node) and (2) it would make
>   the usage of firewalls difficult (currently firewalls look at the
>   home address option to perform some filtering). Futhermore this
>   solution does not solve the problem of incoming packets that
>   contain a routing header which reveals the home address.
> 
>[Morrow, Glenn ]  Quote:
>This TMI might be used by the correspondent
>   node to index the IPsec SA correspondent to the mobile and might be
>   used by firewalls to do filtering.
> 
>Oh - so you want to change security anyway.
>
>This is a pretty lame excuse for your solution in that your solution
>proposes changes to both ESP and MIP. 
>
>My draft does not talk about ESP at all... 
>[Morrow, Glenn ] Claude, really - how would you encrypt the HA. I quote
>again.
> 
>The home address option MUST be placed as follows:
>      - After the routing header, if that header is present
>      - Before the fragment header, if that header is present
>      - Before the AH Header or ESP Header, if either one of those
>      headers is present
>
> 
>
>
>[Morrow, Glenn ]  In short, I don't like and I won't support it. I
>re-iterate it is far too complex for what it is providing.I do not see why
>these other proposals for handling this particular problem are not
>sufficient as is or with some relatively minor work to security.
>
>
> what are the other proposals you are talking about? 
>[Morrow, Glenn ] More quotes:
>
> 3. Possible solutions
>
>   Several solutions are possible, all with their limitations:
>
>   - IPv6 Privacy Extension: A solution could be to used the privacy
>   extension described in [1] to configure the home address and
>   the care-of addresses. While this solution represents a marked
>   improvement over the standard address configuration methods [2],
>   and should be used for the home and care-of addresses, we contend
>   that this is not sufficient.  [1] causes nodes to generate
>   global-scope addresses from interface identifiers that change over
>   time, even in cases where the interface contains an embedded IEEE
>   identifier. As a result if [1] is used to generate the home address,
>   this address will change periodically but the network prefix (64
>   highest bits) will remain unchanged. This network perfix can still
>   reveal much information about the mobile node's identity to an
>   eavesdropper. This mechanism described in [1] must be used for the
>   home address and care-of address in Mobile IPv6 but one should not
>   rely on it to get full privacy protection.
>
>
>C. Castelluccia                                                 [Page 3]
>
>Internet Draft        Privacy Extension for MIPv6        February,  2001
>
>
>   - HA option encryption: An other solution could be to encrypt the
>   home address option. This solution is not satisfactory because
>   (1) it would require to modify IPsec implementation (SA should then
>   be indexed with the care-of address and therefore would need to be
>   updated at each movement of the mobile node) and (2) it would make
>   the usage of firewalls difficult (currently firewalls look at the
>   home address option to perform some filtering). Futhermore this
>   solution does not solve the problem of incoming packets that
>   contain a routing header which reveals the home address.
>
>   - IPsec bi-directional Tunnel (mobile VPN): A solution could be to
>   open a bi-directional IPsec tunnel between the mobile node and its
>   home agent [3]. This solution has the following disadvantages: (1)
>   addition of extra bandwidth (packets need to be encapsulated) and
>   processing overhead, (2) the routing is suboptimal.
>
>
>Our proposal is actually very simple... I am really wondering whether you've
>read the right draft ... 
>[Morrow, Glenn ] 
>
>I sincerely hope the quotes reduce your wondering and hopefully your
>wandering. Someone should give you a big KISS.
>
>With less respect,
>
> Glenn
>
> 
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 15:02:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21665
	for ; Tue, 20 Mar 2001 15:02:14 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01861;
	Tue, 20 Mar 2001 12:00:43 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00643;
	Tue, 20 Mar 2001 12:00:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJx8Im020117
	for ; Tue, 20 Mar 2001 11:59:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KJx8RX020116
	for mobile-ip-dist; Tue, 20 Mar 2001 11:59:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KJwxIm020109
	for ; Tue, 20 Mar 2001 11:59:00 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03097
	for ; Tue, 20 Mar 2001 11:58:59 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA15130
	for ; Tue, 20 Mar 2001 11:58:56 -0800 (PST)
From: James Kempf 
Message-Id: <200103201958.LAA15130@heliopolis.Eng.Sun.COM>
Date: Tue, 20 Mar 2001 13:58:19 -0700
To: 
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Theo,


>Open the requirements box for hierachical mobility...
>
>    what is it really...?   In a nutshell.. to provide a local
>instantiation of the HA near the MN. How near...??? there can be a
>measure for that
>
>of course this needs to be secure, fault tolerant, low signalling load,
>blah blah blah..
>
>the rest of the so called "requirements" are just trying to make what
>people preach about "DIFFERENT" schemes..
>
>In all honesty....am I wrong here...???   :)))
>

Actually, I think you are wrong. I think one of the problems is that
the two drafts are based on some very fundamental differences in 
opinion about what the requirements are. 

Before the working group has agreement on that, I think it's useless
to proceed with a solution.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 15:10:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22136
	for ; Tue, 20 Mar 2001 15:10:25 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22297;
	Tue, 20 Mar 2001 12:08:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25679;
	Tue, 20 Mar 2001 12:08:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KK7EIm020153
	for ; Tue, 20 Mar 2001 12:07:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KK7EIS020152
	for mobile-ip-dist; Tue, 20 Mar 2001 12:07:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KK75Im020145
	for ; Tue, 20 Mar 2001 12:07:05 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04843
	for ; Tue, 20 Mar 2001 12:07:04 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12930
	for ; Tue, 20 Mar 2001 13:07:00 -0700 (MST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2KK6vC16199
	for ; Tue, 20 Mar 2001 21:06:57 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 20 21:08:46 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 21:06:57 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCAC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6
Date: Tue, 20 Mar 2001 21:06:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

	James,

> >Open the requirements box for hierachical mobility...
> >
> >    what is it really...?   In a nutshell.. to provide a local
> >instantiation of the HA near the MN. How near...??? there can be a
> >measure for that
> >
> >of course this needs to be secure, fault tolerant, low signalling load,
> >blah blah blah..
> >
> >the rest of the so called "requirements" are just trying to make what
> >people preach about "DIFFERENT" schemes..
> >
> >In all honesty....am I wrong here...???   :)))
> >
> 
> Actually, I think you are wrong. I think one of the problems is that
> the two drafts are based on some very fundamental differences in 
> opinion about what the requirements are. 
> 
> Before the working group has agreement on that, I think it's useless
> to proceed with a solution.
> 
	=> Agreed.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 15:19:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22573
	for ; Tue, 20 Mar 2001 15:19:22 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09889;
	Tue, 20 Mar 2001 12:18:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27555;
	Tue, 20 Mar 2001 12:18:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKGbIm020182
	for ; Tue, 20 Mar 2001 12:16:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KKGbrq020181
	for mobile-ip-dist; Tue, 20 Mar 2001 12:16:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKGQIm020174
	for ; Tue, 20 Mar 2001 12:16:28 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27111
	for ; Tue, 20 Mar 2001 12:15:46 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17740
	for ; Tue, 20 Mar 2001 13:15:42 -0700 (MST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2KKFdC17411
	for ; Tue, 20 Mar 2001 21:15:39 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 20 21:15:37 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 21:15:39 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCAD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Re: Comments on Regional Registration
Date: Tue, 20 Mar 2001 21:15:38 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


	G'day Glenn, 

	A late reply....

> You have some good points and I will try to explore or re-use some other mechanisms which can hopefully resolve these points. I apologize that the suggestion was targeted to just the RR concept. I should have included more suggestions for HMIP as well such as the one I gave the other day on how to achieve the arbitrary point. 
> 
> This is getting ridiculous. It seems that if I make a suggestion to either I end up irritating the other - not exactly a hospitable environment to contribute to either.
> 
	=> Actually, I am not offended or irritated at all. I can't emphasise
	enough the need for technical feedback. So no need to worry about 
	that. 

> The requirement is to make BU authorization faster, more scalable and eliminate the need to send more than one BU over the air.
> 
	=> Agreed.

> Excuse me if I extended it into the RR assumptions alone. It seems obvious to me on how to do the same thing with HMIP. 
> 
	=> No need to feel guilty ;) I look forward to your feedback.

> The last point I made was definitely out of place and thank you for pointing that out. 
> 
> In the end I do not care what we call it. Perhaps we should come up with another acronym just to reduce the my idea vs. your idea competition. 
> 
> These discussions stink of what I call PWS (Patent War Syndrome). If that is the case then people will likely end up promoting something that isn't the most optimal solution as the standard or there will be multiple optional standards which exacerbate the solution space for future issues.
> 
	=> Here I have to disagree. If our sole purpose is to protect 
	IPR (which BTW we don't know much about what it covers)
	we would not ave welcomed and included other comments 
	or merged with other drafts as we did with Claude. 
	We're happy to modify _anything_ in HMIPv6
	provided there is a good technical argument behind it. 
	I really hope you don't get that impression. It's definitely 
	not what we've been thinking about. 
	 
	Regards,
	Hesham


> -----Original Message----- 
> From: Hesham Soliman (ERA) [ ] 
> Sent: Thursday, March 15, 2001 3:03 PM 
> To: 'mobile-ip@sunroof.eng.sun.com' 
> Subject: RE: [mobile-ip] Re: Comments on Regional Registration 
> 
> 
> Hello Glenn, 
> 
> Before I start commenting on your proposal, I think there are 
> some questions that need to be answered. 
> Why do we need a multilevel static hierarchy of mobility 
> aware routers ? This is a mystery to me. The argument 
> of delays if the MAP is too far simply doesn't hold. 
> If I have an 80ms delay over the air interface and the MAP is 
> another 4 ms away, I think such delay is insignificant. 
> 
> The other question is, do we want to associate the implementation 
> of this protocol with an imaginary protocol that generates 
> an SA between the MN and the domain and distributes the 
> key to all mobility aware routers ? 
> The idea of generating such keys between two nodes is great 
> and we have presented it in San Diego, but I don't think it 
> should be a requirement for this to be used. 
> 
> Do we want to have a tree-based hierarchy full of single 
> points of failure ? 
> 
> I don't want any of the above, but I'd like to see what others 
> think. 
> 
> As you said Light travels fast and I like to Keep it simple, 
> so unless there are strong and well thought requirements 
> for the multi-level hierarchy, I think it should be dropped. 
> 
> I hope you don't take this as a negative response to your 
> proposal, but I like to do things for a reason. The reasons 
> and requirements here are not stated. 
> 
> Regards, 
> Hesham 
> 
> PS: The regional draft for V4, basically says that f the MN 
> has a colocated CoA , then it just registers with the 
> GFA. Sounds familiar ! 
> Just something to think about. 
> 
> 
> 
> > -----Original Message----- 
> > From: Glenn Morrow [SMTP:gmorrow@nortelnetworks.com] 
> > Sent: Friday, 16 March 2001 1:59 
> > To:   mobile-ip@sunroof.eng.sun.com 
> > Subject:      RE: [mobile-ip] Re: Comments on Regional Registration 
> > 
> > Hesham and Charlie, 
> > 
> > I'm not too worried about the security association issue with anycast. I think anycast is extremely useful and is here to stay. It is part of IPv6 - might as well take advantage of it. 
> 
> > 
> > I believe the SA establishment and scaling problem for MIP, in general, has scaling and speed issues. It would actually probably be more productive for us to focus on that issue than heirarchical models. It seems people have focused so far on "database in the sky" solutions with AAA protocols to this.
> 
> > 
> > I have an alternate idea which I would like to bring up again. 
> > 
> > Why don't we use a hop by hop option to alert mobile-aware routers to the binding updates. For instance, a mobile could send a binding update to a CN and it would be intercepted by the 1st hop router in the visited domain. 
> 
> > 
> > If the visited domain wanted to support hierarchical, other routers along the natural routing path to the CN would be configured to care as well at whatever topological tier the provider deemed necessary. These hirearchical routers could install a per-host route in the binding cache to achieve route both optimized hierarchical signaling and traffic flow.
> 
> > 
> > These heirarchical routers could rebuild the binding update with a tiered address and use the domains keys i.e. the keys that routers already use to trust each other for the AH. Routers in the visited and in other domains that are not configured to care about mobility binding simply forward the packet towards the CN's address I.e. they are not configured to "recognize" the particular function. 
> 
> > 
> > Only when the binding update exits a domain into another domain i.e. the keys change, the border router again intercepts and recomputes the binding update using the keys appropriate for the particular border. 
> 
> > 
> > This process is continued until the binding update arrives at either the CN itself or a last hop router in the event they want route optimized location privacy. If the BU is sent to the CN, it is assumed that that CN has some security association with the subnet where it resides and it trusts the keys of that subnet. Perhaps the CN can simply trust the subnet routers without an SA - just as it currently does for ICMP singaling.> 
> 
> > 
> > The advantage of this method are: 
> > 
> > - It re-uses the existing binding update i.e. we don't burn more air bandwidth. We leverage the existing binding updates.
> 
> > 
> > - It provides the most route optimal form of hierarchical mobility. 
> > - It re-uses the existing security associations that SHOULD exist between domains, internal routers and hosts.>  
> > - If one heirarchical router dies other communications and hierarchical bindings for other communications that mobile is engaged in continue un-affected. 
> 
> > 
> > - It does not interfere with the natural routing policy of the domains. 
> > - It seems to match up well and re-uses the same mechanisms used to monitor bandwidth and signal CoS. 
> > 
> > The disadvantages that I see is: 
> > 
> > - It makes some of the intermediary routers do extra signaling; however if you really understand what will have to happen for real time communications such as DSCP schema's changing between administrative domains, you will see that this work will be occuring anyway. Why send more than one packet to get the job done? 
> 
> > 
> > - I agree it is not needed for best effort unless the excuse it to solve the security association problems. 
> > 
> > Another approach might be to send binding updates to the visited subnet anycast addresses and chain the message up the network i.e. MN subnet to site, site to site, site to CN subnet and then to CN.> 
> 
> > 
> > Is this clear? It seems to me that doing something like this>  would resolve many issues. 
> > 
> > One thing I really can't understand with both of your proposed hierarchical solutions is why you want to send more than one binding update. This burns the air resources. The whole idea for doing heirarchical was to reduce signaling latency for cellular. These networks are the only networks that I am aware of that someone might be moving so fast as to warrant a heirarchical scheme. The solutions seem to conflict with requirements. 
> 
> > 
> > The last thing I would like to say that it seems we are spending way to much time on something that provides so little gain. Light travels very fast.
> 
> > 
> > Thanks, 
> > 
> > Glenn 
> > 
> > 
> > 
> > 
> > Glenn 
> > 
> > -----Original Message----- 
> > From: Charlie Perkins [ < >] 
> > Sent: Wednesday, March 14, 2001 5:38 PM 
> > To: mobile-ip@sunroof.eng.sun.com 
> > Subject: Re: [mobile-ip] Re: Comments on Regional Registration 
> > 
> > 
> > Hello Hesham, 
> > 
> > We want to get the routing part figured out, and I believe 
> > we have a pretty good handle on it. 
> > 
> > Setting up security will allow a mobile node to provide 
> > authentication data that can be checked by one of the 
> > anycast group members.  I know several ways to do that. 
> > It will be more productive to start on that task once two 
> > other things are out of the way: 
> > - Fixing the authentication mechanism for base Mobile IPv6 
> > - Getting the routing part figured out. 
> > 
> > If you wish to disqualify all anycast-based solutions because 
> > there are no standards for establishing security between a 
> > node and the members of an anycast group, then I would 
> > just prefer to say that we believe the problem is wholly 
> > solvable for the particular anycast group we have designed. 
> > We don't intend to get in the business of solving it for the 
> > general case. 
> > 
> > Regards, 
> > Charlie P. 
> > 
> > 
> > 
> > "Hesham Soliman (ERA)" wrote: 
> > 
> > >         Hello Charlie, 
> > > 
> > > > 
> > > > > GM> I agree, I support anycast too. To vilify a solution which employs 
> > > > > it as magic was wrong and I apologize. 
> > > > 
> > > > No need for apology, but I wanted to point out that this particular 
> > > > use of anycast is easy to implement, assuming that one's IPv6 
> > > > implementation supports anycast at all. 
> > > > 
> > >         => I'm a bit confused by this statement. How can it be easy 
> > >         to implement a BU to an anycast address ? 
> > >         BUs have to be secured with AH, so how can you setup this 
> > >         security association when there are no standards defined 
> > >         to do so ? 
> > > 
> > >         Regards, 
> > >         Hesham 
> > 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 15:26:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22920
	for ; Tue, 20 Mar 2001 15:26:02 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05845;
	Tue, 20 Mar 2001 12:24:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20518;
	Tue, 20 Mar 2001 12:24:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKN5Im020216
	for ; Tue, 20 Mar 2001 12:23:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KKN5dF020215
	for mobile-ip-dist; Tue, 20 Mar 2001 12:23:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKMuIm020208
	for ; Tue, 20 Mar 2001 12:22:56 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28531
	for ; Tue, 20 Mar 2001 12:22:55 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18117
	for ; Tue, 20 Mar 2001 12:22:54 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2KKMqd21034
	for ; Tue, 20 Mar 2001 21:22:52 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA28343
	for ; Tue, 20 Mar 2001 21:22:51 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2KKMpA36623
	for ; Tue, 20 Mar 2001 21:22:51 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103202022.f2KKMpA36623@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6 
In-reply-to: Your message of Tue, 20 Mar 2001 11:51:44 PST.
             <15031.46288.964150.682721@thomasm-u1.cisco.com> 
Date: Tue, 20 Mar 2001 21:22:51 +0100
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   While the too expensive argument (for some metric
   of expensive) has some appeal, the actual serious
   issue is that authentication is not
   *authorization*.

=> this is *not* the issue raised in the IESG security concerns...

  That is, being able to assert an
   identity does not in any way suggest what rights
   and privileges I should gain given that identity.
   
=> for a common correspondent they are to build a pair of SAs in order
to authenticate BUs. Note this can be as small as AH for binding stuff
for this given address (and it is possible to keep the same address
(the home address) from the beginning). This is a very small privilege.

   The former is possibly a solvable (though
   completely unproven),

=> strong authentication seems very hard (PKIs don't work,
DNSsec is not yet usable, AAA is still in the spec phase, ...).

   the latter would require
   global coordination, treaties, etc, etc. I there
   is high amount of desire to avoid those sorts of
   implications if even vaguely plausible.
   
=> I disagree but this is not part of the IESG concerns (nor the
security implications of the home address options).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 15:27:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23031
	for ; Tue, 20 Mar 2001 15:27:53 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07452;
	Tue, 20 Mar 2001 12:26:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20878;
	Tue, 20 Mar 2001 12:26:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKOUIm020229
	for ; Tue, 20 Mar 2001 12:24:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KKOThS020228
	for mobile-ip-dist; Tue, 20 Mar 2001 12:24:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KKOJIm020221
	for ; Tue, 20 Mar 2001 12:24:19 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20443
	for ; Tue, 20 Mar 2001 12:24:18 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18951
	for ; Tue, 20 Mar 2001 12:24:12 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 20 Mar 2001 14:18:04 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 20 Mar 2001 14:23:09 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA0A@crchy271.us.nortel.com>
From: "Rambabu Tummala" 
To: "'mobile-ip@sunroof.eng.sun.com'" ,
        "'Alper.Yegin@eng.sun.com'" 
Subject: RE: [mobile-ip] rfc3012 question
Date: Tue, 20 Mar 2001 14:23:08 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B17B.93B39ED0"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B17B.93B39ED0
Content-Type: text/plain;
	charset="iso-8859-1"

Alper,

I ran into same problem, only way to get around this is by increasing the
CHALLENGE_WINDOW to bigger number.  In my opinion, which defeats the purpose
of the draft (RFC) itself.

Let me know, if you have a solution.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
Sent: Saturday, March 17, 2001 5:54 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] rfc3012 question


Hello,

I have a question about how FA can keep track of valid challenge values.

As I understand, FA keeps track of valid challenges by noting the challenge 
values sent in multicast/broadcast RAs (these are global, received by all
MNs), 
and challenge values sent to individual MNs.

It's easy to keep track of challenge values, when they are sent in a 
registration reply. MN's identity is the key.

But, when challenge values are sent in unicast RAs in response to RS, how
can FA 
keep track of these? FA wouldn't know the identity of the MN. There's no NAI
in 
RS. And the source address of the RS doesn't have to be home address.


If the solicited RA is sent multicast/broadcast, then since there can be too

many MNs sending RS, this would fill up the CHALLENGE_WINDOW very quickly
and 
create unnecessary rejections.

Unless I'm missing something, this seems like a problem.

alper


------_=_NextPart_001_01C0B17B.93B39ED0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] rfc3012 question




Alper,




I ran into same problem, only way to get around this =
is by increasing the CHALLENGE_WINDOW to bigger number.  In my =
opinion, which defeats the purpose of the draft (RFC) =
itself.



Let me know, if you have a solution.




Rambabu Tummala

Nortel Networks

ESN 444-8970

External (972)684-8970






-----Original Message-----

From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]

Sent: Saturday, March 17, 2001 5:54 PM

To: mobile-ip@sunroof.eng.sun.com

Subject: [mobile-ip] rfc3012 question






Hello,




I have a question about how FA can keep track of =
valid challenge values.




As I understand, FA keeps track of valid challenges =
by noting the challenge 

values sent in multicast/broadcast RAs (these are =
global, received by all MNs), 

and challenge values sent to individual MNs.




It's easy to keep track of challenge values, when =
they are sent in a 

registration reply. MN's identity is the key.




But, when challenge values are sent in unicast RAs in =
response to RS, how can FA 

keep track of these? FA wouldn't know the identity =
of the MN. There's no NAI in 

RS. And the source address of the RS doesn't have to =
be home address.






If the solicited RA is sent multicast/broadcast, then =
since there can be too 

many MNs sending RS, this would fill up the =
CHALLENGE_WINDOW very quickly and 

create unnecessary rejections.




Unless I'm missing something, this seems like a =
problem.




alper





------_=_NextPart_001_01C0B17B.93B39ED0--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 16:27:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25971
	for ; Tue, 20 Mar 2001 16:27:44 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27923;
	Tue, 20 Mar 2001 13:26:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20010;
	Tue, 20 Mar 2001 13:26:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KLPDIm020444
	for ; Tue, 20 Mar 2001 13:25:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KLPD8p020443
	for mobile-ip-dist; Tue, 20 Mar 2001 13:25:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KLP4Im020436
	for ; Tue, 20 Mar 2001 13:25:04 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19999
	for ; Tue, 20 Mar 2001 13:25:02 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26331
	for ; Tue, 20 Mar 2001 13:25:01 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA20640
	for ; Tue, 20 Mar 2001 13:25:00 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KLOv118433
	for ; Tue, 20 Mar 2001 13:24:57 -0800
X-mProtect:  Tue, 20 Mar 2001 13:24:57 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdqCpkHX; Tue, 20 Mar 2001 13:24:48 PST
Message-ID: <3AB7CAA2.6DDF9615@cs.ucl.ac.uk>
Date: Tue, 20 Mar 2001 13:24:50 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBCAC@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

>         James,
>
> > >Open the requirements box for hierachical mobility...
> > >
> > >    what is it really...?   In a nutshell.. to provide a local
> > >instantiation of the HA near the MN. How near...??? there can be a
> > >measure for that
> > >
> > >of course this needs to be secure, fault tolerant, low signalling load,
> > >blah blah blah..
> > >
> > >the rest of the so called "requirements" are just trying to make what
> > >people preach about "DIFFERENT" schemes..
> > >
> > >In all honesty....am I wrong here...???   :)))
> > >
> >
> > Actually, I think you are wrong. I think one of the problems is that
> > the two drafts are based on some very fundamental differences in
> > opinion about what the requirements are.
> >
> > Before the working group has agreement on that, I think it's useless
> > to proceed with a solution.
> >
>         => Agreed.
>
>         Hesham

Fair enough..let's get ourselves in that agreement then..

Theo

UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 20 19:05:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02776
	for ; Tue, 20 Mar 2001 19:05:28 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03458;
	Tue, 20 Mar 2001 16:04:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13430;
	Tue, 20 Mar 2001 13:43:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KLfPIm020479
	for ; Tue, 20 Mar 2001 13:41:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2KLfOxH020477
	for mobile-ip-dist; Tue, 20 Mar 2001 13:41:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2KLelIm020469
	for ; Tue, 20 Mar 2001 13:40:47 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13091
	for ; Tue, 20 Mar 2001 13:40:45 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09922
	for ; Tue, 20 Mar 2001 13:40:40 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22053
	for ; Tue, 20 Mar 2001 13:40:37 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2KLeYH11747
	for ; Tue, 20 Mar 2001 13:40:34 -0800
X-mProtect:  Tue, 20 Mar 2001 13:40:34 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd74PHkW; Tue, 20 Mar 2001 13:40:24 PST
Message-ID: <3AB7CE4B.FDEC6906@cs.ucl.ac.uk>
Date: Tue, 20 Mar 2001 13:40:27 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBCAC@esealnt448.al.sw.ericsson.se> <3AB7CAA2.6DDF9615@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Thinking about it again,


   could the HMIP authors provide us with their view of requirements...


This should bring into perspective the deviation of one spec from another based
on the 'apparent'
differences of requirements as opinioned by the two specs..

Theo

Theo Pagtzis wrote:

> "Hesham Soliman (ERA)" wrote:
>
> >         James,
> >
> > > >Open the requirements box for hierachical mobility...
> > > >
> > > >    what is it really...?   In a nutshell.. to provide a local
> > > >instantiation of the HA near the MN. How near...??? there can be a
> > > >measure for that
> > > >
> > > >of course this needs to be secure, fault tolerant, low signalling load,
> > > >blah blah blah..
> > > >
> > > >the rest of the so called "requirements" are just trying to make what
> > > >people preach about "DIFFERENT" schemes..
> > > >
> > > >In all honesty....am I wrong here...???   :)))
> > > >
> > >
> > > Actually, I think you are wrong. I think one of the problems is that
> > > the two drafts are based on some very fundamental differences in
> > > opinion about what the requirements are.
> > >
> > > Before the working group has agreement on that, I think it's useless
> > > to proceed with a solution.
> > >
> >         => Agreed.
> >
> >         Hesham
>
> Fair enough..let's get ourselves in that agreement then..
>
> Theo
>
> UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 00:33:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17708
	for ; Wed, 21 Mar 2001 00:33:06 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA25015;
	Tue, 20 Mar 2001 21:32:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15146;
	Tue, 20 Mar 2001 21:32:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L5VEIm020960
	for ; Tue, 20 Mar 2001 21:31:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2L5VEro020959
	for mobile-ip-dist; Tue, 20 Mar 2001 21:31:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L5UvIm020952
	for ; Tue, 20 Mar 2001 21:31:05 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28605
	for ; Tue, 20 Mar 2001 21:30:56 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23771
	for ; Tue, 20 Mar 2001 21:30:54 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id D3ED272543; Wed, 21 Mar 2001 07:30:48 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 7556CBA08; Wed, 21 Mar 2001 07:30:47 +0200 (EET)
Message-ID: <3AB83D9E.B078FAFB@nomadiclab.com>
Date: Wed, 21 Mar 2001 07:35:26 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Claude Castelluccia 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
References: <3AB63A39.49928755@nomadiclab.com> <3AB75389.25077265@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> The reasons of keeping the Home Address (in cleartext) is:
> - because IPSec uses it to locate the SA...if you remove the Home Address
>   option you basically needs to use the CoA and since this CoA changes you
>   have to reestablished the SA each time you move...

Hmm.  I am unsure about this.  Isn't SAs looked up by the SPI 
and the _destination_ address?  Quoting RFC2401, "A security 
association is uniquely identified by a triple consisting
of a Security Parameter Index (SPI), an IP Destination Address, 
and a security protocol (AH or ESP) identifier. "  The Home
Address Destination Option carries the source address, doen't it?

My understanding is that the home address destination option is
needed _only_ for looking up the right socket, and, as I have
explained, can be done by other means, too.

> - because some firewalls use it to perform some kind of filtering...

Yes, I know.  But, IMHO, that is _completely_ flawed since the
the firewalls cannot verify it's validity in any way.

> In the draft  we suggest to generate the TMI as follows:
> new TMI = MD5 ( Home address | current TMI),
> 
snip
>
> We should probably use something like that:
> 
> new TMI = MD5 ( Home address | current TMI | random value),
> 

Or maybe you can do even better by calculation a few TMIs beforehand
and using them then backwards.  But then you'd come directly to a
solution similar to what I suggest in the forthcoming pbk-addresses 
draft...

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 01:35:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23378
	for ; Wed, 21 Mar 2001 01:35:15 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22187;
	Tue, 20 Mar 2001 22:34:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24838;
	Tue, 20 Mar 2001 22:34:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L6XcIm021049
	for ; Tue, 20 Mar 2001 22:33:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2L6Xb1k021048
	for mobile-ip-dist; Tue, 20 Mar 2001 22:33:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2L6XSIm021041
	for ; Tue, 20 Mar 2001 22:33:28 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14524
	for ; Tue, 20 Mar 2001 22:33:28 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21007
	for ; Tue, 20 Mar 2001 22:33:27 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA29206
	for ; Tue, 20 Mar 2001 22:33:26 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2L6XPg19155
	for ; Tue, 20 Mar 2001 22:33:25 -0800
X-mProtect:  Tue, 20 Mar 2001 22:33:25 -0800 Nokia Silicon Valley Messaging Protection
Received: from nokdab005207.americas.nokia.com (172.18.5.207, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdxKdltY; Tue, 20 Mar 2001 22:33:14 PST
Message-ID: <3AB84B1A.A2232DFA@iprg.nokia.com>
Date: Tue, 20 Mar 2001 22:32:59 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Header Compression overhead in HMIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBCA3@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Hesham,


>         Hello Rajeev,
>
>         IF context transfer is needed for HC, then it's a seamoby
>         issue that I hope we don't get into here.
>

Yes. I agree that context transfer is a seamoby issue. I was just cross
posting the CT comments for FYI.

>
> > traffic, the flow may last as long as only 20 packets,
> >
>         => You probably know HC more than me, but I checked
>         with the HC experts and I was told that this is not
>         true. 3-4 packets in the worste case scenario is
>         what I've been told.
>

Well, you need to set up context and in my analysis, I have shown that
it can take 12 packets before a compressor can transition to the
so-called SO state in which the header overhead is minimal. I would be
glad to know how this could be achieved with fewer packets.
My main point was that some flows are short-lived and thus there is a
trade-off between context establishment overhead and how long the flow
lasts.

Regards,

-Rajeev


>
>         Regards,
>         Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 12:06:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00591
	for ; Wed, 21 Mar 2001 12:06:31 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27101;
	Wed, 21 Mar 2001 09:05:11 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26063;
	Wed, 21 Mar 2001 09:04:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LH30Im021586
	for ; Wed, 21 Mar 2001 09:03:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LH30aJ021585
	for mobile-ip-dist; Wed, 21 Mar 2001 09:03:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LH2pIm021578
	for ; Wed, 21 Mar 2001 09:02:51 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00886
	for ; Wed, 21 Mar 2001 09:02:50 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28429
	for ; Wed, 21 Mar 2001 10:02:47 -0700 (MST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id A0BC872543; Wed, 21 Mar 2001 19:02:44 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id E6DDDBA08; Wed, 21 Mar 2001 19:02:42 +0200 (EET)
Message-ID: <3AB8DFCF.24BDF882@nomadiclab.com>
Date: Wed, 21 Mar 2001 19:07:27 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: KASSI-LAHLOU Mohammed FTRD/DMI/CAE 
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia 
Subject: [mobile-ip] Comments to draft-kassi-mobileip-dmi-00.txt
References: <91A311FF6A85D3118DDF0060080C3D82010DCD0C@lat3721.rd.francetelecom.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

KASSI-LAHLOU Mohammed FTRD/DMI/CAE wrote:

> If the home address belongs to a virtual network or if at every new
> communication it uses the address obtained in the visited network as a
> source address (as specified in draft-kassi-mobileip-dmi-00.txt) you can
> know that the mobile node is in movement but without having a point of

Nice draft.  Very much in line with our Homeless Mobile IPv6 thinking,
but not going quite that far as we attempt to go.

However, I think that even though the Security Considerations section
may be technically correct, in the practise the situation is different.
That is, one may reasonably assume that a MN has a permanent security
association (in some form) with its permanent or real HA.  However,
I have serious doubts about our ability to provide a scaleable solution
for creating security associations between an MN and the temporary
HA used to forward connections opened while at a foreign link.
Yes, I know, with AAA we most probably will be able to do that, but
I don't believe that AAA will ever scale enough to cover all of the
Internet.  (This is not a technical concern but a deployment concern.)

The case of not having a (conceptual) security association between a MN
and its HA is much harder from the security point of view than the case
where you do have such a security association.  Your grounds for providing
authorization evidence to the CN are much slimmer.  

I suggest that you reconsider your draft in the light of the Mobile IPv6
security discussion to be held tomorrow at the Mobileip WG meeting.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 12:47:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02951
	for ; Wed, 21 Mar 2001 12:47:05 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07656;
	Wed, 21 Mar 2001 09:26:15 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08441;
	Wed, 21 Mar 2001 09:17:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LHFmIm021622
	for ; Wed, 21 Mar 2001 09:15:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LHFmAj021621
	for mobile-ip-dist; Wed, 21 Mar 2001 09:15:48 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LHFYIm021614
	for ; Wed, 21 Mar 2001 09:15:34 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07868
	for ; Wed, 21 Mar 2001 09:15:33 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19039
	for ; Wed, 21 Mar 2001 09:15:31 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id 5EB6772543; Wed, 21 Mar 2001 19:15:28 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 1E0B1BA08; Wed, 21 Mar 2001 19:15:26 +0200 (EET)
Message-ID: <3AB8E2CA.1FC340E1@nomadiclab.com>
Date: Wed, 21 Mar 2001 19:20:10 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: MobileIP Mailing List 
Cc: jis@mit.edu
Subject: [mobile-ip] An attempt to classify attacks against Mobile IPv6
Content-Type: multipart/mixed;
 boundary="------------89CD036473A617D22AAB4AD3"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.
--------------89CD036473A617D22AAB4AD3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Now that the discussion about Mobile IPv6 security has been opened,
I think it is very important to explicitly specify the level of 
protection that we want to provide for Mobile IPv6. 

Thus, here is my first attempt to classify various possible attacks
against Mobile IPv6, to compare the attacks with the current situation
of running IPv4 between two stationary hosts, and my understanding of
the level of protection that we should aim for when designing a 
solution to protect Mobile IPv6. 

I've basically written this yesterday, and more work is definitely
needed.  Thus, comments and volunteers are solicited.

--Pekka
--------------89CD036473A617D22AAB4AD3
Content-Type: text/plain; charset=us-ascii;
 name="mip6-attack-scenarios.txt"
Content-Disposition: inline;
 filename="mip6-attack-scenarios.txt"
Content-Transfer-Encoding: 7bit

1. Introduction

As a general statement about protection requirements, the mechanism
MUST protect against completely new risks caused by mobility, SHOULD
protect against existing risks that become more propable, and MAY
protect against existing risks whose probablity is not changed.  In
praticular, if mobility makes a it slightly more likely that an
attacker is able to eavesdrop or modify traffic, the mechanism SHOULD
protect against such an eavesdropper.  On the other hand, if mobility
makes it highly more likely that an attacker is able to eavesdrop or
modify traffic, or creates likely new scenarios where the attacker has
these capabilities, the mechanism MUST provide protection.  What comes
to the circumstances under which an attack may occur, new
circumstances created by mobility REQUIRE modification, while
modification requirement is RECOMMENDED or OPTIONAL in other
scenarios.

2. Attacker capabilities

The may be attackers with various levels of capabilities.  In general,
we assume that all attackers are able to send forged IP packets.  That
is, we assume that the attacker can construct IP level packets and
sent them so that they contain any IP address as their source
address.  

2.1. Attacker cannot eavesdrop any traffic

The attacker is a completely outside node.  It is able to send forged
traffic to the MN, CA and HA, but it is not able to eavesdrop any
traffic between the MN, CA or HA.  The mechanism MUST be able to
protect against attacks launched by these kinds of attackers.
These kinds of attackers are denoted with the capability "NO".

2.2. Attacker can eavesdrop traffic

The attacker is able to eavesdrop some traffic.  It may have this
ability because it is able to eavesdrop a specific link that happens
to be used between the active parties, or because the attacker is on
the same local link as one of the parties, and is therefore able to
eavesdrop to all traffic on that local link.  In general, the
mechanism SHOULD be able to protect against attacks launched by these
kinds of attackers, but there are specific cases where the mechanism
MUST be able to provide protection, and one case where the attacker is
so powerful that it seems sufficient to loose the protection
requirement to OPTIONAL.  This capability is further divided in
subcases as follows.

2.2.1. Eavesdrop traffic between CN and HA only

The attacker is able to eavesdrop flowing between the CN and HA, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "CN<>HA".

2.2.2. Eavesdrop traffic between CN and MN only

The attacker is able to eavesdrop flowing between the CN and MN, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "CN<>MN". 

2.2.3. Eavesdrop traffic between MN and HA only

The attacker is able to eavesdrop flowing between the MN and HA, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "MN<>HA". 

2.2.4. Eavesdrop all traffic sent and received by CN

The attacker is able to eavesdrop all traffic send and received by
CN. For example, the CN might be a mobile host itself, and the
attacker is able to contact the same local link that the CN is
currently using.  The mechanism SHOULD be able to protect against this
kind of attackers.  These kinds of attackers are denoted with the
capability ">CN>". 

2.2.5. Eavesdrop all traffic sent and received by MN

The attacker is able to eavesdrop all traffic send and received by
MN. A typical case of this is the MN and the attacker on the same
wireless link.  The mechanism MUST be able to protect against this
kind of attackers.  These kinds of attackers are denoted with the
capability ">MN>". 

2.2.6. Eavesdrop all traffic sent and received by HA

The attacker is able to eavesdrop all traffic send and received by HA.
For example, the HA is a foreign HA, the MN has moved away from the
link but it is still receiving packets through its previous CoA, and
the attacker is able to contact the link afterwards.  Another case is
the less likely one where the attacker is attached to the same local
link as a long-term permanent HA.  The mechanism SHOULD be able to
protect against this kind of attackers.  These kinds of attackers are
denoted with the capability ">HA>". 

2.2.7. Eavesdrop all traffic sent and received by MN and HA

The attacker is able to eavesdrop all traffic sent and received by MN
or HA.  A typical scenario is the special case where the HA is a
foreign HA, and the MN, HA and attacker are all at the same local
link.  In general, the mechanism SHOULD be able to protect against
this kind of attackers, but it MUST be able to protect against certain
connection hijacking scenarios. These kinds of attackers are denoted
with the capability ">MN,HA>".

[TBD.  This case seems to require additional considerations.]

2.2.8. Eavesdrop all traffic sent or received by CN, MN or HA

The attacker is able to eavesdrop all relevant traffic.  Typically,
this requires co-ordinated attacks.  The mechanism MAY be able to
protect against this kind of attackers.  These kinds of attackers are
denoted with the capability "ALL". 

2.2.9. Eavesdrop traffic on a link where MN is likely to come

This is a case easily overlooked but very relevant.  In mobile
communications, a dedicated attacker can often easily figure out the
usual daily whereabouts of its target.  By acting preactively, it may
be able to connect to a local link where the MN is likely to come
soon, and pre-establish the situation so that it will be able to
launch its attack as soon as the MN arrives.  The mechanism MUST be
able to protect against attackers with this capability.  These kinds
of attackers are denoted with the capability "FUTURE".

2.3. Attacker can eavesdrop and modify traffic

A more capable attacker is not only able to send forged traffic and
eavesdrop some traffic, it is also able to block and thereby modify
some packets.  In general, we do not require that the mechanism
protects against these kinds of attackers, and therefore the
protection is OPTIONAL.  

2.3.1. Eavesdrop/modify traffic send and received by CN

TBD

2.3.2. Eavesdrop/modify traffic send and received by MN

TBD

2.3.3. Eavesdrop/modify traffic send and received by HA

TBD

2.3.4. Eavesdrop/modify all traffic

TBD

2.3.5. Eavesdrop/modify traffic on a link where MN is likely
       to come

TBD

2.4. Attacker capability summary

All attackers are able to send forged packets.  Some attackers are
able to eavesdrop some traffic, and others even block and therefore
modify some traffic.

  Attacker |                    |                  | Protection
  type     | Eavesdropping 	| Modification     | requirement
  ---------+--------------------+------------------+-------------
  NO       | None               | None             | MUST
  CN<>HA   | Between CN and HA  | None             | SHOULD
  CN<>MN   | Between CN and MN  | None             | SHOULD
  MN<>HA   | Between MN and HA  | None             | SHOULD
  >CN>     | CN                 | None             | SHOULD
  >MN>     | MN                 | None             | MUST
  >HA>     | HA                 | None             | SHOULD
  >MN,HA>  | MN and HA          | None             | SHOULD/MUST 1)
  ALL      | MN, CN, HA         | None             | MAY
  FUTURE   | Future MN          | None             | MUST
  ---------+--------------------+------------------+-------------
  MOD-CN   | CN                 | CN               | MAY
  MOD-MN   | MN                 | MN               | MAY/MUST 2)
  MOD-HA   | HA                 | HA               | MAY
  MOD-ALL  | MN, CN, HA         | MN, CN, HA       | MAY
  MOD-FUT  | Future MN          | Future MN        | SHOULD/MAY 3)

  1) MUST protect against TBD
  2) MUST protect against TBD.
  3) SHOULD protect against TBD.

3. CN properties

3.1. CN is a stationary host

3.2. CN is a multi-homed stationary host

3.3. CN is a mobile host

3.4. CN is a multi-home mobile host 


4. HA properties

4.1. Existing security association between MN and HA

Long-term HA.  "MN=HA"

4.2. No existing security associations between MN and HA

Temporary HA, used to forward packets sent to the old CoA.
"MN!HA".

5. Attack skenarios

The number of possible attacks is almost unlimited.  Thus, we do not
try to enumerate all possible attacks, but instead outline a number of
possible attack scenarious, pointing out the probable outcome of an
attack and (some of) the conditions under which the attack could
occur.  We also try to point potential vulnerabilities that could lead
to the realization of real attacks.  Finally, we classify the
scenarious based on their protection needs.

Currently the scenarios are limited to traffic hijacking and
denial-of-servidce only.  Other attacks are probably possible too, and
need to be added to later revisions of this document.

5.1. Hijacking existing Bindings

Traffic hijacking is the primary threat that there is a need to be
protected from.  That is, because mobility signalling effectively
creates local exceptions to the generic routing information, it is a
very potential tool for diverting traffic to an unauthorized
destination.  This, in turn, may lead to other attacks such as
denial-of-service (also covered separately), impersonation, and/or
man-in-the-middle attacks.

5.1.1. Hijacking existing Binding while MN is online and stationary

If an attacker is able to make a CN to believe that a MN has moved to
a new location, even if it has not, the attacker may be able to hijack
all traffic sent by the CN to the MN.  Furthermore, since the attacker
is assumed to be able to forge packets, it can forward all the
hijacked traffic to the MN, potentially leading to an attack where all
traffic passes through the attacker unnoticed.  Clearly, this is a new
threat compared to the non-mobile situation, and in principle the
mechanism MUST provide protection against attacks belonging to this
scenario.  On the other hand, it is already now possible to hijack TCP
connections if an attacker is able to modify traffic flowing between
two stationary hosts, and therefore protection against an attacker
that is able to modify packets flowing between the CN and the MN is
OPTIONAL.  This attack scenario is called "H-STAT".

5.1.2. Hijacking existing Binding while MN is changing it

If an attacker is able to make a CN to believe that a MN has moved to
location A while it is actually moving to location B, the attack may
be able to hijack traffic sent by the CN to the MN.  As a special
case, if an attacker is able to make the CN believe that a MN has NOT
moved while it has, the attacker may be able to hijack traffic sent by
the CN to the MN, depending on its ability to eavesdrop.  Clearly,
these are new threats compared to the non-mobile situation, and
the mechanism MUST provide protection.  This attack scenario is called
"H-MOVE". 

5.1.3. Hijacking existing Binding while MN is temporarily off-line

Another attack scenario applies when the MN is temporarily off-line
due to e.g. being temporarily outside radio coverage.  We take this as
an different scenario beause the situation may be easier for the
attacker.  That is, since the MN is off-line it is not able to receive
any messages sent to it, nor to reply to them.  Therefore the attacker
may have easier time in trying to make the CN to believe that the MN
has moved or that it is still on-line at its previous location.
Clearly, the mechanism MUST protect against the attack where the CN
thinks that the MN has moved to a new location.  What comes to the
case where the attacker continues to communicate with the CN using the
MNs previous location, the mechanism SHOULD provide protection.  This
attack scenario is called "H-OFFL".

5.2. Hijacking a Binding during its first establishment

It may be possible to attack while the MN is first contacting the CN.
Since we do not expect the existence of any global authentication
infrastructure, it may be hard to protect against man-in-the-middle
attacks during connection establishment.  That is, since the CN does
not necessarily have any information that might help it authenticate
the MN, it may be hard to provide protection, especially in the case
where the MN is away from home while first contacting the CN.
However, we strongly feel that the mechanism SHOULD provide protection
if possible at all.  Thus, this RECOMMENDATION should be considered as
an almost REQUIREMENT.  This attack scenario is called "H-INIT".

5.3. Hijacking a Binding before its first establishment

A capable attacker may be able to plan its attack well beforehand, and
try to anticipate the movements of its target.  Doing so, it may
launch an attack before the target has become on-line at all.  For
example, it may move to a local link where it expects the target to
first become on-line.  Since the target MN is off-line, and most
probably the HA does not have a binding for it, the attacker may be
able to play a number of tricks.  In the worst case scenario, there
may be two co-acting attackers, one at the link where the target MN is
likely to become on-line, and one at the same local link with the CN,
which itself may be a mobile node.  Under such circumstances, it may
be quite hard to provide protection.  However, the mechanism SHOULD
provide protection, if possible.  This attack scenari is called
"H-FUT". 

5.4. Blocking traffic (Denial-of-Service)

A threat possibly not as severe as traffic hijacking but worth
separate coverage is denial-of-service (DoS).  Currently, it is fairly
simple to launch various denial-of-service attacks against traffic
flowing between two stationary nodes.  Thus, in general, there are no
hard REQUIREMENTS to protect against DoS.  However, if one mechanism
clearly protects better against various DoS scenarious than another,
and is not otherwise inferior, the one providing better DoS protection
should clearly be preferred.  In order to be able to evaluate between
different DoS protection models, the DoS scenarios are classified as
those where the protection is RECOMMENDED and where it is OPTIONAL.
Furthermore, we discuss the potential severity of the DoS scenarious,
giving us some guidance when evaluating the protection properties.

5.4.1. Blocking traffic while MN is online and stationary

Currently, it is fairly easy to break existing TCP connections between
any two stationary hosts, e.g., by sending TCP RST to the parties.
However, such an attack does not necessarily prevent the parties from
re-establishing the TCP connection immediately and thereby continuing
communications.  On the other hand, combining connection termination
with resource exhausting DoS (such as SYN flooding) may effectively
prevent communication.  Now, from this point of view we may classify
the DoS attacks to two subclasses: those that only cause a temporary
disruption of communication, and those that prevent future
communication.  With regard to the first subclass, protection is
considered OPTIONAL, while protection against the second subclass
is considered RECOMMENDED.  This attack scenario is called "B-STAT".

5.4.2. Blocking traffic while MN is moving and changing its Binding

More severe DoS attacks may be available while the MN is changing its
binding.  For example, if the attacker is able to make the CN to
believe that the MN has not moved, it will continue to send packets to
the old CoA, either degrading or temporarily terminating the service.
(The service is degraded if the MN has registered with a temporary HA
at its old link, and the HA keeps tunneling the packets to the MN.  On
the other hand, if no such forwarding service has been established,
service is termporarily terminated.)  Depending on its capabilities,
the CN may notice that the MN does not seem to get the packets any
more, and expire the binding.  On the other hand, service degradion is
likely to go unnoticed for a while.  Protection against this class of
DoS attacks is RECOMMENDED.  This attack scenario is called "B-MOVE".

5.4.3. Blocking traffic while MN is temporarily off-line

While the MN is temporarily off-line, e.g., due to being outside radio
coverage, an attacker may have more possibilities to block future
traffic.  For example, the attacker may try to make the CN believe
that the CN has moved to an address which does not exist, or that the
CN has altogether terminated communication with the CN may lead to
DoS.  In the latter case, for example, the CN may flush any security
associations that it currently has with the MN, thereby forcing the MN
to re-create them once it becomes back on-line.  Typically, that would
lengthen the period of unablity to communicate by several seconds.  
Currently, protection against these kinds of attacks is considered
OPTIONAL.  This attack scenario is called "B-OFFL".

5.4.4. Blocking traffic while MN is trying to contact CN

The initial contact between the MN and the CN seems like a very
lucrative point to attack.  The MN and the CN don't even really know
yet whether the other party exists, and if the attacker can make the
MN believe that the CN is currently unavailable, or the CN believe
that the MN can't get reply packets sent to it, the attempt to
communicate may fail altogether.  However, such attacks are already
now fairly easy to execute.  Therefore, we consider protection against
this class of attacks as OPTIONAL.  This attack scenario is called
"B-INIT". 

5.4.5. Blocking traffic before MN tries to contact CN

As we discussed in Section 5.3, mobility signalling opens up a
possibility for a class of attacks that are performed before there is
any contact between the MN and the CN.  For example, the attacker may
lead the CN to believe that the MN-to-come is currently at a
non-existing address.  When the MN the contacts the CN, the CN will
send the reply packets to this non-existing address, leading the MN to
believe that the CN is currently unavailable.  

Another possibility may be to make the CN to persistently believe thet
the MN is dishonest and should not be allowed to communicate at all.
For example, the attacker may launch a resource exhausting
denial-of-service attack against the CN, making the CN to believe that
the launcher of the attack is the MN-to-come.  Now, if the CN, based
on its countermeasures, decided to (temporarily) ignore all traffic
originated by the MN, the MN will not get any replies from the CN once
it eventually tries to contact.

These attack possibilities seem to be new, and therefore it is
RECOMMENDED that the mechanism provides some protection against them.
This attack scenario is called "B-FUT".

5.5. Sumary of the attack scenarios

In the table below, "Scenario type" is the name of the attack
scenario, as named in sections above.  The "Attack possible currently"
tries to indicate if there are currently known ways of attacking
communication between two static IPv4 hosts.  "No" means that the
authors are unaware of such an attack, "Yes" that the authors are
aware of such attacks, and "Limited" means that a limited form of an
attack is known, typically depending on the capabilities of the
attacker.  "Protection requirement" gives indication how important it
is for the Mobile IPv6 protection mechanism to provide protection
against attacks belonging to the scenario.

           | Attack    |
  Scenario | possible  | Protection
  type	   | currently | requirement
  ---------+-----------+--------------
  H-STAT   | Limited   | MUST/MAY
  H-MOVE   | No        | MUST
  H-OFFL   | Limited   | MUST/SHOULD
  H-INIT   | Yes       | SHOULD
  H-FUT	   | ??        | SHOULD
  ---------+-----------+--------------
  B-STAT   | Yes       | SHOULD/MAY
  B-MOVE   | No        | SHOULD
  B-OFFL   | Yes       | MAY
  B-INIT   | Yes       | MAY
  B-FUT	   | No        | SHOULD


6. Protection requirement matrix

The following tables summarize the protection requirements
by classifying the attacks along the attack scenarios and attacker
capabilities.  Where deemed illuminating, also other properties such
as the existense of a pre-established security association between the
MN and the HA are considered.  In the table, the following
abbreviations are used.

 Abbr   | Explanation
 -------+---------------------------------------------------------
 MUST   | Protection is REQUIRED.  The mechanism MUST provide
        | protection against this class of attackers and attacks.
 -------+---------------------------------------------------------
 SHOULD | Protection is RECOMMENDED.  The mechanism SHOULD provide
        | protection if possible.
 -------+---------------------------------------------------------
 MAY    | Protection is OPTIONAL (but desired).  If the mechanism
        | does provide protection, it is a definite plus

6.1. Hijacking attacks

  Attacker | 
  type     | H-STAT | H-MOVE | H-OFFL | H-INIT | H-FUT  |
  ---------+--------+--------+--------+--------+--------+
  NO       | MUST   | MUST   | MUST   | MUST   | MUST   |
  CN<>HA   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  CN<>MN   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  MN<>HA   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >CN>     | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >MN>     | MUST   | MUST   | MUST   | MUST   | MUST   |
  >HA>     | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >MN,HA>  | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  ALL      | SHOULD | SHOULD | SHOULD | MAY    | MAY    |
  FUTURE   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  ---------+--------+--------+--------+--------+--------+
  MOD-CN   | SHOULD | SHOULD | MAY    | MAY    | SHOULD |
  MOD-MN   | SHOULD | SHOULD | MAY    | MAY    | SHOULD |
  MOD-HA   | SHOULD | SHOULD | MAY    | KAY    | SHOULD |
  MOD-ALL  | MAY    | SHOULD | MAY    | MAY    | SHOULD |
  MOD-FUT  | SHOULD | SHOULD | MAY    | MAY    | SHOULD |

6.2. Denial-of-service attacks

  Attacker | 
  type     | B-STAT | B-MOVE | B-OFFL | B-INIT | B-FUT  |
  ---------+--------+--------+--------+--------+--------+
  NO       | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD |
  CN<>HA   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  CN<>MN   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  MN<>HA   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  >CN>     | SHOULD | SHOULD | SHOULD | MAY    | MAY    |
  >MN>     | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD |
  >HA>     | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  >MN,HA>  | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  ALL      | MAY    | MAY    | MAY    | MAY    | MAY    |
  FUTURE   | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  ---------+--------+--------+--------+--------+--------+
  MOD-CN   | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-MN   | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-HA   | MAY    | MAY    | MAY    | KAY    | MAY    |
  MOD-ALL  | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-FUT  | MAY    | MAY    | MAY    | MAY    | MAY    |











--------------89CD036473A617D22AAB4AD3--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 14:04:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07371
	for ; Wed, 21 Mar 2001 14:04:11 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09324;
	Wed, 21 Mar 2001 11:02:43 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01509;
	Wed, 21 Mar 2001 11:02:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LJ1BIm021785
	for ; Wed, 21 Mar 2001 11:01:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LJ1BSk021784
	for mobile-ip-dist; Wed, 21 Mar 2001 11:01:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LJ11Im021777
	for ; Wed, 21 Mar 2001 11:01:01 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11801;
	Wed, 21 Mar 2001 11:01:00 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04901;
	Wed, 21 Mar 2001 12:00:39 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA13327;
	Wed, 21 Mar 2001 10:59:42 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2LIxcw10682;
	Wed, 21 Mar 2001 10:59:38 -0800
X-mProtect:  Wed, 21 Mar 2001 10:59:38 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin30.iprg.nokia.com (205.226.20.224, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdeOL5da; Wed, 21 Mar 2001 10:58:40 PST
Message-ID: <3AB8FA22.D232E181@iprg.nokia.com>
Date: Wed, 21 Mar 2001 10:59:46 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill ,
        Mohan Parthasarathy ,
        Michael Thomas 
Subject: [mobile-ip] Drafty draft about key establishment for Binding Update
Content-Type: multipart/mixed;
 boundary="------------AEBC641D4795CA0B8063A13A"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.
--------------AEBC641D4795CA0B8063A13A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello folks,

Here's what I wrote up last night after our
meeting in Salon A.

Regards,
Charlie P.

--------------AEBC641D4795CA0B8063A13A
Content-Type: text/plain; charset=us-ascii;
 name="Draft"
Content-Disposition: inline;
 filename="Draft"
Content-Transfer-Encoding: 7bit

Binding Key Establishment for Mobile IPv6


Abstract

A method is proposed for providing key information for use
between a mobile node and correspondent node, to be used
for the purpose of authenticating Mobile IPv6 Binding Updates.
The key districution is secure except against man-in-the-middle
attacks, when the attacker resides in the routing path between
the correspondent node and the mobile node's home agent.
The key can be used for authenticating subsequent Binding Updates
from the same mobile node, substantially reducing the number
of key establishment cycles needed for maintaining efficient
communication paths between the mobile node and correspondent
node.


Introduction

Mobile IPv6 specifies the use of a Binding Update destination
option for use between a correspondent node and a mobile node.
This Binding Update associates a "care-of address" to the mobile
node's "home address" enabling direct routing of packets to
the current point of attachment in use by the mobile node.
Unfortunately, there may be many instances where no pre-existing
security association is available for use by the correspondent
node to authenticate a Binding Update from the mobile node.

In order to solve this problem, we propose a method by which
a correspondent node supplies some random data for use by the
mobile node as input to an algorithm for creating a security
association.  This security association, once established
between the mobile node and the correspondent node, is then
used to create the authentication data that is required to be
supplied as one of the security fields of the Binding Update
destination option.

Without introducing reliance upon use of certifiable public
keys, it is quite difficult to avoid all attacks against the
correspondent node that might allow some malicious third part
to masquerade as the mobile node.  However, we can at least
make sure that any such malicious node would have to reside
on the routing path between the correspondent node and the
home agent.  This substantially reduces to the vulnerability
to such attacks, since the specific routing path required
amounts to an extremely small proportion of the Internet.

In this protocol specification, several new messages are
introduced:
- Binding Warning, which is sent by a mobile node to a
  correspondent node as an indication that a new care-of
  address should be obtained for the one of the mobile node's
  addresses.
- Binding Request, which is sent by a correspondent node
  to the address of the mobile node in order to elicit
  a Binding Update.

In addition, the following extension is specified for
use in messages to the correspondent node.
- Binding Authentication Key Establishment Extension, which
  supplies a key to be used by the correspondent node when
  verifying authentication data supplied by the mobile node
  to ensure the integrity of the Binding Update data.

Subsequent sections provide an overview of the operation of
the key establishment mechanism, the format of the protocol
messages, and detailed specification for the message formats.
Although a specific authentication algorithm is proposed,
it should be noted that other authentication algorithms
may be proposed in the future.  However, for interoperability,
all correspondent nodes SHOULD implement the algorithm
specified in this document.

NOTE: I don't care what the algorithm is, so if the one
      in this document isn't right, I don't mind taking
      someone's suggestion about using another one.





============================ Terminology ============================


RFC 2119

Cookie

Key

Binding Key

Security Association



============================ Overview ============================

A mobile node MUST have any security association with a correspondent
node before it can securely supply a Binding Update to that correspondent.
If no security association exists for that purpose, the mobile node
SHOULD send a Binding Warning to the correspondent node, asking it to
start the process of establishing the needed security association
with the indicated address of the mobile node.

When a correspondent node receives a Binding Warning message,
it selects an appropriate 64-bit random number and inserts it
into the Cookie field of the Binding Request message.  It then
sends the Binding Request to the home address of the mobile node.
The Binding Request message MUST NOT contain any routing header
entries with any current or previous care-of addresses used to
send packets to the indicated address of the mobile node.

Similarly, if a correspondent node determines for any reason
to establish a Binding Key with the mobild node, it may send
a Binding Request with a newly selected cookie to the mobile
node, even if the mobile node has not issued the Binding
Warning message to the correspondent node.

When the home agent gets the Binding Request, it MUST tunnel
the packet to the mobile node.  The tunneled packet SHOULD
include an IPSec ESP header to assure privacy for the
Cookie data supplied by the correspondent node.

When the mobile node gets the tunneled Binding Request, it
first decapsulates the packet.  Before the mobile node processes
the Binding Request, it SHOULD ensure that the message was
tunneled from its home agent.

If the Binding Request suboption contains the Cookie suboption,
the mobile node creates a key according to the following
algorithm:
	Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)
where "CN IPv6 Address" is the IPv6 address of the correspondent
node sending the Binding Request, available as the Source IP
address from the encapsulated IPv6 header.  The mobile node MUST
create a new security association for the correspondent node,
associate the key with the new security association,
and insert this new security association into its security policy database
with the appropriate indications to enable future use when creating
the Authentication Data for the Binding Update destination option.


The mobile node then uses the key to create the Authentication
Data for the requested Binding Update destination option.  The default
algorithm for creation of the authentication data is as follows:
	Auth_data  :=  HMAC_MD5 (Key  ||  Previous Fields  || Key)
The mobile node then obscures the key according to the following algorithm:
	Hidden_Key  :=  Key XOR Cookie

Finally, the mobile node creates a Binding Key Establishment
suboption for the Binding Update message, and inserts the
Hidden Key into the appropriate field of the suboption.

When the correspondent node receives the Binding Update, it
first checks to see if there is a Binding Key Establishment
suboption.  If so, then it retrieves the hidden key according
the following algorithm:
	Key  :=  Hidden_Key XOR Cookie
The correspondent node then checks the validity of the
Authentication Data by performing the same calculation
with the newly established Key, as was performed by the
mobile node when creating the key data.

===================== Packet Formats ==========================

=================== Security Considerations ==========================

If the home agent does not encrypt the Binding Request packet
when tunneling it to the mobile node (as in section~\xref{over},
the key establishment will be vulnerable to any malicious node
present along the routing path from the home agent to the
mobile node.

--------------AEBC641D4795CA0B8063A13A--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 14:31:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08859
	for ; Wed, 21 Mar 2001 14:31:09 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07990;
	Wed, 21 Mar 2001 11:30:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26183;
	Wed, 21 Mar 2001 11:29:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LJRRIm021830
	for ; Wed, 21 Mar 2001 11:27:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LJRR3R021829
	for mobile-ip-dist; Wed, 21 Mar 2001 11:27:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LJRHIm021822
	for ; Wed, 21 Mar 2001 11:27:18 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07079
	for ; Wed, 21 Mar 2001 11:27:17 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26648
	for ; Wed, 21 Mar 2001 11:27:06 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id 4095B72543; Wed, 21 Mar 2001 21:27:03 +0200 (EET)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 7A5F6BA08; Wed, 21 Mar 2001 21:26:55 +0200 (EET)
Message-ID: <3AB9019B.397D1EB7@nomadiclab.com>
Date: Wed, 21 Mar 2001 21:31:39 +0200
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <3AB8FA22.D232E181@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Charlie Perkins wrote:
>
> Here's what I wrote up last night after our
> meeting in Salon A.

As an immediate response, there seems to be a potential new
DoS attack that may need addressing.  That is, when the CN
receives a Binding Warning, it creates a cookie, and basically
stores either a  or a  pair 
to wait for the Binding Update that it expects to receive from 
the MN.  It must store this pair since otherwise it couldn't 
turn the Hidden_key into the Key etc.  

Now, a potential attacker could easily send zillions of 
Binding Warnings, using different CoA:s and Home Addresses,
leading to a DoS similar to TCP SYN flooding.

Other attacks will follow as soon as I figure out how to do them :-)

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 15:31:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12379
	for ; Wed, 21 Mar 2001 15:31:37 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05562;
	Wed, 21 Mar 2001 12:30:26 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13613;
	Wed, 21 Mar 2001 12:30:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LKSkIm021920
	for ; Wed, 21 Mar 2001 12:28:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LKSjTm021919
	for mobile-ip-dist; Wed, 21 Mar 2001 12:28:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LKSaIm021912
	for ; Wed, 21 Mar 2001 12:28:36 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13161;
	Wed, 21 Mar 2001 12:28:35 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22454;
	Wed, 21 Mar 2001 12:28:34 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2LKSWd50859;
	Wed, 21 Mar 2001 21:28:32 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA02797;
	Wed, 21 Mar 2001 21:26:53 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2LKQqA40104;
	Wed, 21 Mar 2001 21:26:52 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103212026.f2LKQqA40104@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Wed, 21 Mar 2001 10:59:46 PST.
             <3AB8FA22.D232E181@iprg.nokia.com> 
Date: Wed, 21 Mar 2001 21:26:52 +0100
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   The key districution is secure except against man-in-the-middle
   attacks, when the attacker resides in the routing path between
   the correspondent node and the mobile node's home agent.

=> this is enough to assume real trouble if this is used between
two mobile nodes (even I am sceptical some have predicted that
a large part of the Internet will be mobile.

Sorry

Francis.Dupont@enst-bretagne.fr

PS: I believe we need the two essential parts of IKE phase one:
 - shared secret with Diffie-Hellman or similar mechanisms
 - authentication (binding acknowledgement needs symetrical
   authentication)
The first must be end-to-end, the second is the hard part but
easier to provide, for instance if you have a third party (like
between MN-HA using the AAA network, cf draft-perkins-aaav6-03.txt
or instantiation draft-dupont-mipv6-aaa-00.txt).
We can reuse many ideas of the authentication/authorization brain
storming (I have archives). 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 17:12:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17890
	for ; Wed, 21 Mar 2001 17:12:17 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05011;
	Wed, 21 Mar 2001 14:11:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21658;
	Wed, 21 Mar 2001 14:11:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LM9FIm022034
	for ; Wed, 21 Mar 2001 14:09:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LM9Erv022033
	for mobile-ip-dist; Wed, 21 Mar 2001 14:09:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LM95Im022026
	for ; Wed, 21 Mar 2001 14:09:05 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16433
	for ; Wed, 21 Mar 2001 14:09:04 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20700
	for ; Wed, 21 Mar 2001 14:09:00 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2LM8pd22098
	for ; Wed, 21 Mar 2001 23:08:51 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Mar 21 23:08:47 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 21 Mar 2001 23:08:47 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6
Date: Wed, 21 Mar 2001 23:08:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Sorry for the late reply.

> I also think that agreed requirements will help developing the  protocol
> tremendously.
> Unfortunately I don't know all the detailed history of the WG and thus I
> don't know what requirements were used as the base for the existing drafts.
> I'd like to list several requirements that seem to me a sort of minimal
> ones.
> 
> 1) Localizing signaling for intra-domain handoffs
> - Minimizing signaling traffic to HA or CN for intra-domain handoffs
> 2) Minimizing overhead on air-interface and MN
> 3) Reliability
> - Capability to provide connectivity continously to existing or new MNs
> visiting the domain in the case of intermediate node failures
> (the intermedia node would be MAP, GFA, RFA, etc.)
> 4) Minimizing service disruption period in the case of intermediate node
> failures
> 5) Scalability
> 6) Security
> 
	=> Agreed. I think we can also get some things
	for free (relatively!) like location privacy and 
	some level of support for Mobile networks.

> I'd like to point several issues for each proposal (RR, HMIP).
> 
> 
> HMIP:
> In my understanding, the HMIP proposal allows redundant or multiple MAPs
> covering a certain spot (or cell). I see several issues in HMIP regarding
> it. I assume a MN registers with only a MAP at a time.
> - Overhead to the air-interface due to MAP option advertisement
> As the number of MAPs increase, the overhead becomes larger.
> 
	=> We only expect two options at the most for reliability
	or overapping domains. This can be an overhead if RAs 
	are advertised very frequently, but that is not 
	the assumption we're making. The Fast Handoffs
	draft shows that this is not required for mobility.

> - Overhead to the MN
> MN needs to monitor the MAP option advertisement continously to know whether
> the MAP is alive even when the MN has not moved its location
> 
	=> The MN MUST monitor RAs and check if any changes 
	have taken place. This is already a requirement for IPv6
	and MIPv6 in general.
	I don't think this is a new requirement
	due to HMIPv6. Adding one more option will add
	more checks in the MN but I don't see another way
	of informing the MN that a MAP exists/disppeared.
	Perhaps you could suggest a different mechanism
	that we can consider.

> - Connectivity recovery time
> The MN needs to wait for the MAP option advertisements and then do
> re-registration to a new MAP, HA and/or CN. The MN should know the MAP
> option advertisement period and wait for a certain timeout period to find
> out the failure of the MAP. Obviously the advertisement period is related to
> the overhead to the air-interface and thus it is not easy to reduce the
> period.
> 
	=> Detecting a MAP failure can result in triggering an
	RA which does not include that specific MAP's 
	option. This does no require frequent RAs, instead 
	they are advertised only when needed. 

	The trigger can be based on any of the MAP discovery
	mechanisms or another protocol. 
	For example, In the dynamic MAP discovery case
	the MAP can advertise with short intervals, but 
	the ARs do not need to propagate that with 
	the same intervals. 

	Hesham

> ----- Original Message -----
> From: "James Kempf" 
> To: 
> Sent: Saturday, March 17, 2001 2:02 PM
> Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
> 
> 
> > >This is to say that RegReg can come up with another autoconfig scheme for
> the
> > routing
> > >hierarchy that decouples BU signalling and caters for
> > >single points of failures. This can also be expressed as "we are
> supplying a
> > detailed
> > >supplement to the draft that solves this problem" which is
> > >just as good as your statement. What we need to make sure is understand
> that
> > everything
> > >comes at a price. Complex protocol and signalling for> 
> > >really awkward mobility situations that can become the norm, or protocol
> > simplicity for
> > >the base case and addition of optimization that again
> > >bring complications to the signalling design...I cannot see a clear cut
> choice
> > to any of
> > >the two options.
> > >
> > >I feel that the group would benefit infinetely if the specs merge...
> > >
> >
> > I'd like to second this.
> >
> > But first, I think there needs to be some agreement on requirements.
> >
> > jak
> >
> >
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 18:05:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21012
	for ; Wed, 21 Mar 2001 18:05:40 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAB13918;
	Wed, 21 Mar 2001 15:04:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03846;
	Wed, 21 Mar 2001 15:04:09 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LN2UIm022098
	for ; Wed, 21 Mar 2001 15:02:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LN2UGR022097
	for mobile-ip-dist; Wed, 21 Mar 2001 15:02:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LN2KIm022090
	for ; Wed, 21 Mar 2001 15:02:20 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20181;
	Wed, 21 Mar 2001 15:02:18 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21096;
	Wed, 21 Mar 2001 15:02:17 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA22558;
	Wed, 21 Mar 2001 15:02:18 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADB04947;
	Wed, 21 Mar 2001 15:02:12 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00955; Wed, 21 Mar 2001 15:02:12 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15033.13044.349541.483892@thomasm-u1.cisco.com>
Date: Wed, 21 Mar 2001 15:02:12 -0800 (PST)
To: Dan Harkins 
Cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: <200103212253.f2LMrWx52352@potassium.cips.nokia.com>
References: <3AB8FA22.D232E181@iprg.nokia.com>
	<200103212253.f2LMrWx52352@potassium.cips.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Dan Harkins writes:
 >   If the binding updates are important enough to require cryptographic
 > protection then the keys have to be authenticated. 

 What treaty organization did you have in mind to be the
 third party?

       Mike

 > 
 >   Dan.
 > 
 > On Wed, 21 Mar 2001 10:59:46 PST you wrote
 > > 
 > > Hello folks,
 > > 
 > > Here's what I wrote up last night after our
 > > meeting in Salon A.
 > > 
 > > Regards,
 > > Charlie P.
 > > 
 > > --------------AEBC641D4795CA0B8063A13A
 > > Content-Type: text/plain; charset=us-ascii;
 > >  name="Draft"
 > > Content-Transfer-Encoding: 7bit
 > > Content-Disposition: inline;
 > >  filename="Draft"
 > > 
 > > Binding Key Establishment for Mobile IPv6
 > > 
 > > 
 > > Abstract
 > > 
 > > A method is proposed for providing key information for use
 > > between a mobile node and correspondent node, to be used
 > > for the purpose of authenticating Mobile IPv6 Binding Updates.
 > > The key districution is secure except against man-in-the-middle
 > > attacks, when the attacker resides in the routing path between
 > > the correspondent node and the mobile node's home agent.
 > > The key can be used for authenticating subsequent Binding Updates
 > > from the same mobile node, substantially reducing the number
 > > of key establishment cycles needed for maintaining efficient
 > > communication paths between the mobile node and correspondent
 > > node.
 > > 
 > > 
 > > Introduction
 > > 
 > > Mobile IPv6 specifies the use of a Binding Update destination
 > > option for use between a correspondent node and a mobile node.
 > > This Binding Update associates a "care-of address" to the mobile
 > > node's "home address" enabling direct routing of packets to
 > > the current point of attachment in use by the mobile node.
 > > Unfortunately, there may be many instances where no pre-existing
 > > security association is available for use by the correspondent
 > > node to authenticate a Binding Update from the mobile node.
 > > 
 > > In order to solve this problem, we propose a method by which
 > > a correspondent node supplies some random data for use by the
 > > mobile node as input to an algorithm for creating a security
 > > association.  This security association, once established
 > > between the mobile node and the correspondent node, is then
 > > used to create the authentication data that is required to be
 > > supplied as one of the security fields of the Binding Update
 > > destination option.
 > > 
 > > Without introducing reliance upon use of certifiable public
 > > keys, it is quite difficult to avoid all attacks against the
 > > correspondent node that might allow some malicious third part
 > > to masquerade as the mobile node.  However, we can at least
 > > make sure that any such malicious node would have to reside
 > > on the routing path between the correspondent node and the
 > > home agent.  This substantially reduces to the vulnerability
 > > to such attacks, since the specific routing path required
 > > amounts to an extremely small proportion of the Internet.
 > > 
 > > In this protocol specification, several new messages are
 > > introduced:
 > > - Binding Warning, which is sent by a mobile node to a
 > >   correspondent node as an indication that a new care-of
 > >   address should be obtained for the one of the mobile node's
 > >   addresses.
 > > - Binding Request, which is sent by a correspondent node
 > >   to the address of the mobile node in order to elicit
 > >   a Binding Update.
 > > 
 > > In addition, the following extension is specified for
 > > use in messages to the correspondent node.
 > > - Binding Authentication Key Establishment Extension, which
 > >   supplies a key to be used by the correspondent node when
 > >   verifying authentication data supplied by the mobile node
 > >   to ensure the integrity of the Binding Update data.
 > > 
 > > Subsequent sections provide an overview of the operation of
 > > the key establishment mechanism, the format of the protocol
 > > messages, and detailed specification for the message formats.
 > > Although a specific authentication algorithm is proposed,
 > > it should be noted that other authentication algorithms
 > > may be proposed in the future.  However, for interoperability,
 > > all correspondent nodes SHOULD implement the algorithm
 > > specified in this document.
 > > 
 > > NOTE: I don't care what the algorithm is, so if the one
 > >       in this document isn't right, I don't mind taking
 > >       someone's suggestion about using another one.
 > > 
 > > 
 > > 
 > > 
 > > 
 > > ============================ Terminology ============================
 > > 
 > > 
 > > RFC 2119
 > > 
 > > Cookie
 > > 
 > > Key
 > > 
 > > Binding Key
 > > 
 > > Security Association
 > > 
 > > 
 > > 
 > > ============================ Overview ============================
 > > 
 > > A mobile node MUST have any security association with a correspondent
 > > node before it can securely supply a Binding Update to that correspondent.
 > > If no security association exists for that purpose, the mobile node
 > > SHOULD send a Binding Warning to the correspondent node, asking it to
 > > start the process of establishing the needed security association
 > > with the indicated address of the mobile node.
 > > 
 > > When a correspondent node receives a Binding Warning message,
 > > it selects an appropriate 64-bit random number and inserts it
 > > into the Cookie field of the Binding Request message.  It then
 > > sends the Binding Request to the home address of the mobile node.
 > > The Binding Request message MUST NOT contain any routing header
 > > entries with any current or previous care-of addresses used to
 > > send packets to the indicated address of the mobile node.
 > > 
 > > Similarly, if a correspondent node determines for any reason
 > > to establish a Binding Key with the mobild node, it may send
 > > a Binding Request with a newly selected cookie to the mobile
 > > node, even if the mobile node has not issued the Binding
 > > Warning message to the correspondent node.
 > > 
 > > When the home agent gets the Binding Request, it MUST tunnel
 > > the packet to the mobile node.  The tunneled packet SHOULD
 > > include an IPSec ESP header to assure privacy for the
 > > Cookie data supplied by the correspondent node.
 > > 
 > > When the mobile node gets the tunneled Binding Request, it
 > > first decapsulates the packet.  Before the mobile node processes
 > > the Binding Request, it SHOULD ensure that the message was
 > > tunneled from its home agent.
 > > 
 > > If the Binding Request suboption contains the Cookie suboption,
 > > the mobile node creates a key according to the following
 > > algorithm:
 > > 	Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)
 > > where "CN IPv6 Address" is the IPv6 address of the correspondent
 > > node sending the Binding Request, available as the Source IP
 > > address from the encapsulated IPv6 header.  The mobile node MUST
 > > create a new security association for the correspondent node,
 > > associate the key with the new security association,
 > > and insert this new security association into its security policy database
 > > with the appropriate indications to enable future use when creating
 > > the Authentication Data for the Binding Update destination option.
 > > 
 > > 
 > > The mobile node then uses the key to create the Authentication
 > > Data for the requested Binding Update destination option.  The default
 > > algorithm for creation of the authentication data is as follows:
 > > 	Auth_data  :=  HMAC_MD5 (Key  ||  Previous Fields  || Key)
 > > The mobile node then obscures the key according to the following algorithm:
 > > 	Hidden_Key  :=  Key XOR Cookie
 > > 
 > > Finally, the mobile node creates a Binding Key Establishment
 > > suboption for the Binding Update message, and inserts the
 > > Hidden Key into the appropriate field of the suboption.
 > > 
 > > When the correspondent node receives the Binding Update, it
 > > first checks to see if there is a Binding Key Establishment
 > > suboption.  If so, then it retrieves the hidden key according
 > > the following algorithm:
 > > 	Key  :=  Hidden_Key XOR Cookie
 > > The correspondent node then checks the validity of the
 > > Authentication Data by performing the same calculation
 > > with the newly established Key, as was performed by the
 > > mobile node when creating the key data.
 > > 
 > > ===================== Packet Formats ==========================
 > > 
 > > =================== Security Considerations ==========================
 > > 
 > > If the home agent does not encrypt the Binding Request packet
 > > when tunneling it to the mobile node (as in section~\xref{over},
 > > the key establishment will be vulnerable to any malicious node
 > > present along the routing path from the home agent to the
 > > mobile node.
 > > 
 > > --------------AEBC641D4795CA0B8063A13A--
 > > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 18:42:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23321
	for ; Wed, 21 Mar 2001 18:42:15 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22016;
	Wed, 21 Mar 2001 15:40:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28507;
	Wed, 21 Mar 2001 15:40:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNcbIm022256
	for ; Wed, 21 Mar 2001 15:38:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LNcbA5022255
	for mobile-ip-dist; Wed, 21 Mar 2001 15:38:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNcQIm022248
	for ; Wed, 21 Mar 2001 15:38:26 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14218
	for ; Wed, 21 Mar 2001 15:38:26 -0800 (PST)
Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05266
	for ; Wed, 21 Mar 2001 15:38:26 -0800 (PST)
Received: from potassium.cips.nokia.com (localhost [127.0.0.1])
	by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f2LNYMx52544;
	Wed, 21 Mar 2001 15:34:22 -0800 (PST)
	(envelope-from dharkins@potassium.cips.nokia.com)
Message-Id: <200103212334.f2LNYMx52544@potassium.cips.nokia.com>
To: Michael Thomas 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_baaaaaaaaa0"
Content-ID: <52541.985217662.0@potassium.cips.nokia.com>
Date: Wed, 21 Mar 2001 15:34:22 -0800
From: Dan Harkins 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

------- =_baaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"; charset="us-ascii"
Content-ID: <52541.985217662.1@potassium.cips.nokia.com>

  Oh darn, that's right. That pesky authentication stuff. In that case I 
recommend you use the pre-shared key for the Internet. It was an April
Fools draft but it provides you with the level of security you seem to
want and doesn't have any of those nasty scaling problems associated
with public key infrastructure.

  I've attached a copy of it for you.

  Dan.

On Wed, 21 Mar 2001 15:02:12 PST you wrote
> Dan Harkins writes:
>  >   If the binding updates are important enough to require cryptographic
>  > protection then the keys have to be authenticated. 
> 
>  What treaty organization did you have in mind to be the
>  third party?
> 
>        Mike


------- =_baaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"; charset="us-ascii"
Content-ID: <52541.985217662.2@potassium.cips.nokia.com>
Content-Description: crypto-that-scales.txt







Network Working Group                 Derrell Piper, The Electric Loft
INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Company
draft-ieft-ipsec-internet-key-00.txt                     April 1, 1998


              The Pre-Shared Key for the Internet Protocol
                 


                          Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


      0. Table Of Contents
      1. Abstract
      2. Discussion
      3. Terms and Definitions
      4. Pre-Shared Key Definition
      5. Security Considerations
      6. Acknowledgments
      7. References


1. Abstract

   Recent efforts from the IPsec Working Group of the IETF in securing
   the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
   [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
   and [OAKLEY]) imply the continued use of pre-shared keys.  This
   document defines the Pre-Shared Key for the Internet.






Piper, Harkins                                          	[Page 1]

INTERNET DRAFT                                             April 1, 1998


2. Discussion

   Pre-shared keys are normally used for interoperability purposes.  The
   basic idea is that two parties sharing a common secret can
   communicate securely.  This idea has been used since cryptography
   first sprung onto the scene.  For a complete history of cryptography,
   see Wired magazine.

   An additional motivation is that pre-shared keys are, for the most
   part, unencumbered technology.  (It's speculated that RSA Data
   Security, Inc. has made various claims relating to use of pre-shared
   keys, but these claims have not yet been tested in court.)

   In order to validate security implementations it is necessary to
   agree on a pre-shared key in an out-of-band fashion.  Such a
   technique is inherently problematic: the two parties must communicate
   and agree upon a key using a medium which is, itself, probably
   insecure.  By standardizing on a Pre-Shared Key for the Internet,
   such communication is precluded.

   Additionally, the technique of pre-communication apriori to
   subsequent communication has obvious scaling problems.  By
   standardizing on a cannonical Pre-Shared Key for the Internet, pre-
   shared keys now scale.

   Previous, non-standard attempts at agreeing on a pre-shared key were
   deficient in their use of standard English.  For example, the ANX
   sponsored IPSec bakeoffs rather confusingly used both
   "whatcertificatereally" as well as the more standard key, "gwock".
   By standardizing on Pidgin, the Pre-Shared Key for the Internet now
   sounds, like, most cool.

3. Terms and Definitions

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra97].

4. Pre-Shared Key Definition

   All security implementations that include support for pre-shared keys
   MUST be capable of supporting the Pre-Shared Key for the Internet.

   The pre-shared key for the Internet is 14 octets in length.  It is
   represented in ASCII as "mekmitasdigoat" without the accompanying
   quotation marks.  In hexadecimal it is represented as:
   0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
   termination characters (such as a terminating NULL).



Piper, Harkins                                          	[Page 2]

INTERNET DRAFT                                             April 1, 1998


   When used with [HC98], the pre-shared key for the Internet MUST be
   used directly for authentication of the Phase 1 exchange ([HC98],
   Section 5.4).

   When used with [KA98], the manual key for the Internet may need to be
   expanded depending on the actual algorithmic requirements of the
   corresponding security association.  Expansion of the key is
   performed by successive concatenation until the required length has
   been met or exceeded, but never both.

   Other used of pre-shared keys which require greater than 14 octets
   MUST expand the Pre-Shared Key for the Internet in the manner
   described above for use with [KA98]. Other uses which require less
   than 14 octets MUST truncate the key to the required length.  Other
   uses which require exactly 14 octets or have no limit to the length
   of a pre-shared key MUST use the Pre-Shared Key for the Internet in
   the manner described above for use with [HC98].

5. Security Consideration

   The use of pre-shared keys has known security implications. When used
   for authentication, the presentation of a shared secret is proof of
   identity.  When used for datagram authentication, the pre-shared key
   authenticates the content and source of the datagram.  Using the Pre-
   Shared Key for the Internet will, in effect, allow you to
   authenticate everyone.  One drawback is that this will negate the
   effects of all related security protocols.

6. Acknowledgments

   The authors would like to thank Roy Pereira, Steve Sneddon, William
   Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, and
   Randall Atkinson for their encouragement in writing this draft.

10. References

   [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
   Requirement Levels", RFC-2119, March 1997.

   [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
   Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.

   [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
   (ESP)," draft-ietf-ipsec-esp-v2-04.txt.

   [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
   Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.




Piper, Harkins                                          	[Page 3]

INTERNET DRAFT                                             April 1, 1998


   [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its
   Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.

   [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
   With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.

   [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
   bitan-auth-des-mac-00.txt.

   [DOI] Piper, D., "The Internet IP Security Domain of Interpretation
   for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.

   [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and
   AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.

   [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
   and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.

   [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
   draft-ietf-ipsec-isakmp-oakley-06.txt.

   [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
   Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
   protocol-05.txt.

   [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol (ISAKMP),"
   draft-ietf-ipsec-isakmp-09.{ps,txt}.

   [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-
   ietf-ipsec-oakley-02.txt.

   [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
   Interconnection - The Directory:  Models", CCITT/ITU Recommendation
   X.501, 1993.

   [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
   Interconnection - The Directory:  Authentication Framework",
   CCITT/ITU Recommendation X.509, 1993.

Authors' Addresses:

   Derrell Piper
   The Electric Loft
   41 6th Ave
   Santa Cruz, CA 95060
   hobbit@yoyodyne.com




Piper, Harkins                                          	[Page 4]

INTERNET DRAFT                                             April 1, 1998


   Dan Harkins
   The Anvil Brewing Company

















































Piper, Harkins                                          	[Page 5]


------- =_baaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"; charset="us-ascii"
Content-ID: <52541.985217662.3@potassium.cips.nokia.com>

Piper, Harkins                                          	[Page 5]


------- =_aaaaaaaaaa0--

------------- End Forwarded Message -------------


------- =_baaaaaaaaa0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 18:46:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23614
	for ; Wed, 21 Mar 2001 18:46:50 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00427;
	Wed, 21 Mar 2001 15:45:52 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16563;
	Wed, 21 Mar 2001 15:45:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNiMIm022290
	for ; Wed, 21 Mar 2001 15:44:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LNiLpL022289
	for mobile-ip-dist; Wed, 21 Mar 2001 15:44:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNiAIm022282
	for ; Wed, 21 Mar 2001 15:44:10 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29465;
	Wed, 21 Mar 2001 15:44:10 -0800 (PST)
Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21998;
	Wed, 21 Mar 2001 15:44:09 -0800 (PST)
Received: from potassium.cips.nokia.com (localhost [127.0.0.1])
	by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f2LNe5x52590;
	Wed, 21 Mar 2001 15:40:05 -0800 (PST)
	(envelope-from dharkins@potassium.cips.nokia.com)
Message-Id: <200103212340.f2LNe5x52590@potassium.cips.nokia.com>
To: Michael Thomas 
cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: Your message of "Wed, 21 Mar 2001 15:35:05 PST."
             <15033.15017.188437.439579@thomasm-u1.cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <52587.985218005.1@potassium.cips.nokia.com>
Date: Wed, 21 Mar 2001 15:40:05 -0800
From: Dan Harkins 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
  Maybe you can explain to me how this key is being used to provide

_authorization_ then. 

  Note that if you actually read the proposal you'd see that it says:
"A method is proposed for providing key information for use between a
mobile node and correspondent node, to be used for the purpose of
*authenticating* Mobile IPv6 Binding Updates." (emphasis mine).

  Dan.

On Wed, 21 Mar 2001 15:35:05 PST you wrote
> Dan Harkins writes:
>  >   Oh darn, that's right. That pesky authentication stuff. 
> 
>   s/authentication/authorization and get back to me.
> 
> 			Mike
> 
> In that case I 
>  > recommend you use the pre-shared key for the Internet. It was an April
>  > Fools draft but it provides you with the level of security you seem to
>  > want and doesn't have any of those nasty scaling problems associated
>  > with public key infrastructure.
>  > 
>  >   I've attached a copy of it for you.
>  > 
>  >   Dan.
>  > 
>  > On Wed, 21 Mar 2001 15:02:12 PST you wrote
>  > > Dan Harkins writes:
>  > >  >   If the binding updates are important enough to require cryptographi
>c
>  > >  > protection then the keys have to be authenticated. 
>  > > 
>  > >  What treaty organization did you have in mind to be the
>  > >  third party?
>  > > 
>  > >        Mike
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > Network Working Group                 Derrell Piper, The Electric Loft
>  > INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Company
>  > draft-ieft-ipsec-internet-key-00.txt                     April 1, 1998
>  > 
>  > 
>  >               The Pre-Shared Key for the Internet Protocol
>  >                  
>  > 
>  > 
>  >                           Status of this Memo
>  > 
>  >    This document is an Internet Draft. Internet Drafts are working
>  >    documents of the Internet Engineering Task Force (IETF), its areas,
>  >    and working groups.  Note that other groups may also distribute
>  >    working documents as Internet Drafts.
>  > 
>  >    Internet Drafts are draft documents valid for a maximum of six months
>  >    and may be updated, replaced, or obsoleted by other documents at any
>  >    time. It is inappropriate to use Internet Drafts as reference
>  >    material or to cite them other than as "work in progress."
>  > 
>  >    To learn the current status of any Internet Draft, please check the
>  >    "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
>  >    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
>  >    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
>  >    ftp.isi.edu (US West Coast).
>  > 
>  > 
>  >       0. Table Of Contents
>  >       1. Abstract
>  >       2. Discussion
>  >       3. Terms and Definitions
>  >       4. Pre-Shared Key Definition
>  >       5. Security Considerations
>  >       6. Acknowledgments
>  >       7. References
>  > 
>  > 
>  > 1. Abstract
>  > 
>  >    Recent efforts from the IPsec Working Group of the IETF in securing
>  >    the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
>  >    [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
>  >    and [OAKLEY]) imply the continued use of pre-shared keys.  This
>  >    document defines the Pre-Shared Key for the Internet.
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > Piper, Harkins                                          	[Page 1]
>  > 
>  > INTERNET DRAFT                                             April 1, 1998
>  > 
>  > 
>  > 2. Discussion
>  > 
>  >    Pre-shared keys are normally used for interoperability purposes.  The
>  >    basic idea is that two parties sharing a common secret can
>  >    communicate securely.  This idea has been used since cryptography
>  >    first sprung onto the scene.  For a complete history of cryptography,
>  >    see Wired magazine.
>  > 
>  >    An additional motivation is that pre-shared keys are, for the most
>  >    part, unencumbered technology.  (It's speculated that RSA Data
>  >    Security, Inc. has made various claims relating to use of pre-shared
>  >    keys, but these claims have not yet been tested in court.)
>  > 
>  >    In order to validate security implementations it is necessary to
>  >    agree on a pre-shared key in an out-of-band fashion.  Such a
>  >    technique is inherently problematic: the two parties must communicate
>  >    and agree upon a key using a medium which is, itself, probably
>  >    insecure.  By standardizing on a Pre-Shared Key for the Internet,
>  >    such communication is precluded.
>  > 
>  >    Additionally, the technique of pre-communication apriori to
>  >    subsequent communication has obvious scaling problems.  By
>  >    standardizing on a cannonical Pre-Shared Key for the Internet, pre-
>  >    shared keys now scale.
>  > 
>  >    Previous, non-standard attempts at agreeing on a pre-shared key were
>  >    deficient in their use of standard English.  For example, the ANX
>  >    sponsored IPSec bakeoffs rather confusingly used both
>  >    "whatcertificatereally" as well as the more standard key, "gwock".
>  >    By standardizing on Pidgin, the Pre-Shared Key for the Internet now
>  >    sounds, like, most cool.
>  > 
>  > 3. Terms and Definitions
>  > 
>  >    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
>  >    "MAY" that appear in this document are to be interpreted as described
>  >    in [Bra97].
>  > 
>  > 4. Pre-Shared Key Definition
>  > 
>  >    All security implementations that include support for pre-shared keys
>  >    MUST be capable of supporting the Pre-Shared Key for the Internet.
>  > 
>  >    The pre-shared key for the Internet is 14 octets in length.  It is
>  >    represented in ASCII as "mekmitasdigoat" without the accompanying
>  >    quotation marks.  In hexadecimal it is represented as:
>  >    0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
>  >    termination characters (such as a terminating NULL).
>  > 
>  > 
>  > 
>  > Piper, Harkins                                          	[Page 2]
>  > 
>  > INTERNET DRAFT                                             April 1, 1998
>  > 
>  > 
>  >    When used with [HC98], the pre-shared key for the Internet MUST be
>  >    used directly for authentication of the Phase 1 exchange ([HC98],
>  >    Section 5.4).
>  > 
>  >    When used with [KA98], the manual key for the Internet may need to be
>  >    expanded depending on the actual algorithmic requirements of the
>  >    corresponding security association.  Expansion of the key is
>  >    performed by successive concatenation until the required length has
>  >    been met or exceeded, but never both.
>  > 
>  >    Other used of pre-shared keys which require greater than 14 octets
>  >    MUST expand the Pre-Shared Key for the Internet in the manner
>  >    described above for use with [KA98]. Other uses which require less
>  >    than 14 octets MUST truncate the key to the required length.  Other
>  >    uses which require exactly 14 octets or have no limit to the length
>  >    of a pre-shared key MUST use the Pre-Shared Key for the Internet in
>  >    the manner described above for use with [HC98].
>  > 
>  > 5. Security Consideration
>  > 
>  >    The use of pre-shared keys has known security implications. When used
>  >    for authentication, the presentation of a shared secret is proof of
>  >    identity.  When used for datagram authentication, the pre-shared key
>  >    authenticates the content and source of the datagram.  Using the Pre-
>  >    Shared Key for the Internet will, in effect, allow you to
>  >    authenticate everyone.  One drawback is that this will negate the
>  >    effects of all related security protocols.
>  > 
>  > 6. Acknowledgments
>  > 
>  >    The authors would like to thank Roy Pereira, Steve Sneddon, William
>  >    Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, and
>  >    Randall Atkinson for their encouragement in writing this draft.
>  > 
>  > 10. References
>  > 
>  >    [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
>  >    Requirement Levels", RFC-2119, March 1997.
>  > 
>  >    [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
>  >    Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.
>  > 
>  >    [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
>  >    (ESP)," draft-ietf-ipsec-esp-v2-04.txt.
>  > 
>  >    [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
>  >    Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.
>  > 
>  > 
>  > 
>  > 
>  > Piper, Harkins                                          	[Page 3]
>  > 
>  > INTERNET DRAFT                                             April 1, 1998
>  > 
>  > 
>  >    [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its
>  >    Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.
>  > 
>  >    [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
>  >    With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.
>  > 
>  >    [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
>  >    bitan-auth-des-mac-00.txt.
>  > 
>  >    [DOI] Piper, D., "The Internet IP Security Domain of Interpretation
>  >    for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.
>  > 
>  >    [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and
>  >    AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.
>  > 
>  >    [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
>  >    and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.
>  > 
>  >    [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
>  >    draft-ietf-ipsec-isakmp-oakley-06.txt.
>  > 
>  >    [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
>  >    Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
>  >    protocol-05.txt.
>  > 
>  >    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
>  >    "Internet Security Association and Key Management Protocol (ISAKMP),"
>  >    draft-ietf-ipsec-isakmp-09.{ps,txt}.
>  > 
>  >    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-
>  >    ietf-ipsec-oakley-02.txt.
>  > 
>  >    [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
>  >    Interconnection - The Directory:  Models", CCITT/ITU Recommendation
>  >    X.501, 1993.
>  > 
>  >    [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
>  >    Interconnection - The Directory:  Authentication Framework",
>  >    CCITT/ITU Recommendation X.509, 1993.
>  > 
>  > Authors' Addresses:
>  > 
>  >    Derrell Piper
>  >    The Electric Loft
>  >    41 6th Ave
>  >    Santa Cruz, CA 95060
>  >    hobbit@yoyodyne.com
>  > 
>  > 
>  > 
>  > 
>  > Piper, Harkins                                          	[Page 4]
>  > 
>  > INTERNET DRAFT                                             April 1, 1998
>  > 
>  > 
>  >    Dan Harkins
>  >    The Anvil Brewing Company
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > Piper, Harkins                                          	[Page 5]
>  > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 18:49:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23773
	for ; Wed, 21 Mar 2001 18:49:28 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26718;
	Wed, 21 Mar 2001 15:36:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27749;
	Wed, 21 Mar 2001 15:36:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNZJIm022231
	for ; Wed, 21 Mar 2001 15:35:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2LNZJ6i022230
	for mobile-ip-dist; Wed, 21 Mar 2001 15:35:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2LNZAIm022223
	for ; Wed, 21 Mar 2001 15:35:10 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15258;
	Wed, 21 Mar 2001 15:35:09 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03056;
	Wed, 21 Mar 2001 15:35:09 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA10797;
	Wed, 21 Mar 2001 15:35:10 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADB05958;
	Wed, 21 Mar 2001 15:35:05 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00983; Wed, 21 Mar 2001 15:35:05 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15033.15017.188437.439579@thomasm-u1.cisco.com>
Date: Wed, 21 Mar 2001 15:35:05 -0800 (PST)
To: Dan Harkins 
Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: <200103212316.f2LNGpx52447@potassium.cips.nokia.com>
References: <15033.13044.349541.483892@thomasm-u1.cisco.com>
	<200103212316.f2LNGpx52447@potassium.cips.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Dan Harkins writes:
 >   Oh darn, that's right. That pesky authentication stuff. 

  s/authentication/authorization and get back to me.

			Mike

In that case I 
 > recommend you use the pre-shared key for the Internet. It was an April
 > Fools draft but it provides you with the level of security you seem to
 > want and doesn't have any of those nasty scaling problems associated
 > with public key infrastructure.
 > 
 >   I've attached a copy of it for you.
 > 
 >   Dan.
 > 
 > On Wed, 21 Mar 2001 15:02:12 PST you wrote
 > > Dan Harkins writes:
 > >  >   If the binding updates are important enough to require cryptographic
 > >  > protection then the keys have to be authenticated. 
 > > 
 > >  What treaty organization did you have in mind to be the
 > >  third party?
 > > 
 > >        Mike
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Network Working Group                 Derrell Piper, The Electric Loft
 > INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Company
 > draft-ieft-ipsec-internet-key-00.txt                     April 1, 1998
 > 
 > 
 >               The Pre-Shared Key for the Internet Protocol
 >                  
 > 
 > 
 >                           Status of this Memo
 > 
 >    This document is an Internet Draft. Internet Drafts are working
 >    documents of the Internet Engineering Task Force (IETF), its areas,
 >    and working groups.  Note that other groups may also distribute
 >    working documents as Internet Drafts.
 > 
 >    Internet Drafts are draft documents valid for a maximum of six months
 >    and may be updated, replaced, or obsoleted by other documents at any
 >    time. It is inappropriate to use Internet Drafts as reference
 >    material or to cite them other than as "work in progress."
 > 
 >    To learn the current status of any Internet Draft, please check the
 >    "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
 >    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
 >    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
 >    ftp.isi.edu (US West Coast).
 > 
 > 
 >       0. Table Of Contents
 >       1. Abstract
 >       2. Discussion
 >       3. Terms and Definitions
 >       4. Pre-Shared Key Definition
 >       5. Security Considerations
 >       6. Acknowledgments
 >       7. References
 > 
 > 
 > 1. Abstract
 > 
 >    Recent efforts from the IPsec Working Group of the IETF in securing
 >    the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
 >    [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
 >    and [OAKLEY]) imply the continued use of pre-shared keys.  This
 >    document defines the Pre-Shared Key for the Internet.
 > 
 > 
 > 
 > 
 > 
 > 
 > Piper, Harkins                                          	[Page 1]
 > 
 > INTERNET DRAFT                                             April 1, 1998
 > 
 > 
 > 2. Discussion
 > 
 >    Pre-shared keys are normally used for interoperability purposes.  The
 >    basic idea is that two parties sharing a common secret can
 >    communicate securely.  This idea has been used since cryptography
 >    first sprung onto the scene.  For a complete history of cryptography,
 >    see Wired magazine.
 > 
 >    An additional motivation is that pre-shared keys are, for the most
 >    part, unencumbered technology.  (It's speculated that RSA Data
 >    Security, Inc. has made various claims relating to use of pre-shared
 >    keys, but these claims have not yet been tested in court.)
 > 
 >    In order to validate security implementations it is necessary to
 >    agree on a pre-shared key in an out-of-band fashion.  Such a
 >    technique is inherently problematic: the two parties must communicate
 >    and agree upon a key using a medium which is, itself, probably
 >    insecure.  By standardizing on a Pre-Shared Key for the Internet,
 >    such communication is precluded.
 > 
 >    Additionally, the technique of pre-communication apriori to
 >    subsequent communication has obvious scaling problems.  By
 >    standardizing on a cannonical Pre-Shared Key for the Internet, pre-
 >    shared keys now scale.
 > 
 >    Previous, non-standard attempts at agreeing on a pre-shared key were
 >    deficient in their use of standard English.  For example, the ANX
 >    sponsored IPSec bakeoffs rather confusingly used both
 >    "whatcertificatereally" as well as the more standard key, "gwock".
 >    By standardizing on Pidgin, the Pre-Shared Key for the Internet now
 >    sounds, like, most cool.
 > 
 > 3. Terms and Definitions
 > 
 >    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
 >    "MAY" that appear in this document are to be interpreted as described
 >    in [Bra97].
 > 
 > 4. Pre-Shared Key Definition
 > 
 >    All security implementations that include support for pre-shared keys
 >    MUST be capable of supporting the Pre-Shared Key for the Internet.
 > 
 >    The pre-shared key for the Internet is 14 octets in length.  It is
 >    represented in ASCII as "mekmitasdigoat" without the accompanying
 >    quotation marks.  In hexadecimal it is represented as:
 >    0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
 >    termination characters (such as a terminating NULL).
 > 
 > 
 > 
 > Piper, Harkins                                          	[Page 2]
 > 
 > INTERNET DRAFT                                             April 1, 1998
 > 
 > 
 >    When used with [HC98], the pre-shared key for the Internet MUST be
 >    used directly for authentication of the Phase 1 exchange ([HC98],
 >    Section 5.4).
 > 
 >    When used with [KA98], the manual key for the Internet may need to be
 >    expanded depending on the actual algorithmic requirements of the
 >    corresponding security association.  Expansion of the key is
 >    performed by successive concatenation until the required length has
 >    been met or exceeded, but never both.
 > 
 >    Other used of pre-shared keys which require greater than 14 octets
 >    MUST expand the Pre-Shared Key for the Internet in the manner
 >    described above for use with [KA98]. Other uses which require less
 >    than 14 octets MUST truncate the key to the required length.  Other
 >    uses which require exactly 14 octets or have no limit to the length
 >    of a pre-shared key MUST use the Pre-Shared Key for the Internet in
 >    the manner described above for use with [HC98].
 > 
 > 5. Security Consideration
 > 
 >    The use of pre-shared keys has known security implications. When used
 >    for authentication, the presentation of a shared secret is proof of
 >    identity.  When used for datagram authentication, the pre-shared key
 >    authenticates the content and source of the datagram.  Using the Pre-
 >    Shared Key for the Internet will, in effect, allow you to
 >    authenticate everyone.  One drawback is that this will negate the
 >    effects of all related security protocols.
 > 
 > 6. Acknowledgments
 > 
 >    The authors would like to thank Roy Pereira, Steve Sneddon, William
 >    Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, and
 >    Randall Atkinson for their encouragement in writing this draft.
 > 
 > 10. References
 > 
 >    [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
 >    Requirement Levels", RFC-2119, March 1997.
 > 
 >    [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
 >    Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.
 > 
 >    [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
 >    (ESP)," draft-ietf-ipsec-esp-v2-04.txt.
 > 
 >    [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
 >    Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.
 > 
 > 
 > 
 > 
 > Piper, Harkins                                          	[Page 3]
 > 
 > INTERNET DRAFT                                             April 1, 1998
 > 
 > 
 >    [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its
 >    Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.
 > 
 >    [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
 >    With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.
 > 
 >    [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
 >    bitan-auth-des-mac-00.txt.
 > 
 >    [DOI] Piper, D., "The Internet IP Security Domain of Interpretation
 >    for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.
 > 
 >    [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and
 >    AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.
 > 
 >    [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
 >    and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.
 > 
 >    [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
 >    draft-ietf-ipsec-isakmp-oakley-06.txt.
 > 
 >    [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
 >    Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
 >    protocol-05.txt.
 > 
 >    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
 >    "Internet Security Association and Key Management Protocol (ISAKMP),"
 >    draft-ietf-ipsec-isakmp-09.{ps,txt}.
 > 
 >    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-
 >    ietf-ipsec-oakley-02.txt.
 > 
 >    [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
 >    Interconnection - The Directory:  Models", CCITT/ITU Recommendation
 >    X.501, 1993.
 > 
 >    [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
 >    Interconnection - The Directory:  Authentication Framework",
 >    CCITT/ITU Recommendation X.509, 1993.
 > 
 > Authors' Addresses:
 > 
 >    Derrell Piper
 >    The Electric Loft
 >    41 6th Ave
 >    Santa Cruz, CA 95060
 >    hobbit@yoyodyne.com
 > 
 > 
 > 
 > 
 > Piper, Harkins                                          	[Page 4]
 > 
 > INTERNET DRAFT                                             April 1, 1998
 > 
 > 
 >    Dan Harkins
 >    The Anvil Brewing Company
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Piper, Harkins                                          	[Page 5]
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 21 23:00:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08185
	for ; Wed, 21 Mar 2001 23:00:54 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06851;
	Wed, 21 Mar 2001 19:57:10 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16221;
	Wed, 21 Mar 2001 19:57:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2M3ttIm022560
	for ; Wed, 21 Mar 2001 19:55:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2M3ttCf022559
	for mobile-ip-dist; Wed, 21 Mar 2001 19:55:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2M3tjIm022552
	for ; Wed, 21 Mar 2001 19:55:45 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28132;
	Wed, 21 Mar 2001 19:55:43 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA16759;
	Wed, 21 Mar 2001 20:55:42 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA18586;
	Wed, 21 Mar 2001 19:55:51 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADB11772;
	Wed, 21 Mar 2001 19:55:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA01023; Wed, 21 Mar 2001 19:55:28 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15033.30640.461564.221205@thomasm-u1.cisco.com>
Date: Wed, 21 Mar 2001 19:55:28 -0800 (PST)
To: Dan Harkins 
Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: <200103212340.f2LNe5x52590@potassium.cips.nokia.com>
References: <15033.15017.188437.439579@thomasm-u1.cisco.com>
	<200103212340.f2LNe5x52590@potassium.cips.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Well, I didn't write that text but suffice it to
say you still haven't answered my original
question.

		Mike

Dan Harkins writes:
 >   Maybe you can explain to me how this key is being used to provide
 > _authorization_ then. 
 > 
 >   Note that if you actually read the proposal you'd see that it says:
 > "A method is proposed for providing key information for use between a
 > mobile node and correspondent node, to be used for the purpose of
 > *authenticating* Mobile IPv6 Binding Updates." (emphasis mine).
 > 
 >   Dan.
 > 
 > On Wed, 21 Mar 2001 15:35:05 PST you wrote
 > > Dan Harkins writes:
 > >  >   Oh darn, that's right. That pesky authentication stuff. 
 > > 
 > >   s/authentication/authorization and get back to me.
 > > 
 > > 			Mike
 > > 
 > > In that case I 
 > >  > recommend you use the pre-shared key for the Internet. It was an April
 > >  > Fools draft but it provides you with the level of security you seem to
 > >  > want and doesn't have any of those nasty scaling problems associated
 > >  > with public key infrastructure.
 > >  > 
 > >  >   I've attached a copy of it for you.
 > >  > 
 > >  >   Dan.
 > >  > 
 > >  > On Wed, 21 Mar 2001 15:02:12 PST you wrote
 > >  > > Dan Harkins writes:
 > >  > >  >   If the binding updates are important enough to require cryptographi
 > >c
 > >  > >  > protection then the keys have to be authenticated. 
 > >  > > 
 > >  > >  What treaty organization did you have in mind to be the
 > >  > >  third party?
 > >  > > 
 > >  > >        Mike
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Network Working Group                 Derrell Piper, The Electric Loft
 > >  > INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Company
 > >  > draft-ieft-ipsec-internet-key-00.txt                     April 1, 1998
 > >  > 
 > >  > 
 > >  >               The Pre-Shared Key for the Internet Protocol
 > >  >                  
 > >  > 
 > >  > 
 > >  >                           Status of this Memo
 > >  > 
 > >  >    This document is an Internet Draft. Internet Drafts are working
 > >  >    documents of the Internet Engineering Task Force (IETF), its areas,
 > >  >    and working groups.  Note that other groups may also distribute
 > >  >    working documents as Internet Drafts.
 > >  > 
 > >  >    Internet Drafts are draft documents valid for a maximum of six months
 > >  >    and may be updated, replaced, or obsoleted by other documents at any
 > >  >    time. It is inappropriate to use Internet Drafts as reference
 > >  >    material or to cite them other than as "work in progress."
 > >  > 
 > >  >    To learn the current status of any Internet Draft, please check the
 > >  >    "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
 > >  >    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
 > >  >    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
 > >  >    ftp.isi.edu (US West Coast).
 > >  > 
 > >  > 
 > >  >       0. Table Of Contents
 > >  >       1. Abstract
 > >  >       2. Discussion
 > >  >       3. Terms and Definitions
 > >  >       4. Pre-Shared Key Definition
 > >  >       5. Security Considerations
 > >  >       6. Acknowledgments
 > >  >       7. References
 > >  > 
 > >  > 
 > >  > 1. Abstract
 > >  > 
 > >  >    Recent efforts from the IPsec Working Group of the IETF in securing
 > >  >    the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
 > >  >    [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
 > >  >    and [OAKLEY]) imply the continued use of pre-shared keys.  This
 > >  >    document defines the Pre-Shared Key for the Internet.
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Piper, Harkins                                          	[Page 1]
 > >  > 
 > >  > INTERNET DRAFT                                             April 1, 1998
 > >  > 
 > >  > 
 > >  > 2. Discussion
 > >  > 
 > >  >    Pre-shared keys are normally used for interoperability purposes.  The
 > >  >    basic idea is that two parties sharing a common secret can
 > >  >    communicate securely.  This idea has been used since cryptography
 > >  >    first sprung onto the scene.  For a complete history of cryptography,
 > >  >    see Wired magazine.
 > >  > 
 > >  >    An additional motivation is that pre-shared keys are, for the most
 > >  >    part, unencumbered technology.  (It's speculated that RSA Data
 > >  >    Security, Inc. has made various claims relating to use of pre-shared
 > >  >    keys, but these claims have not yet been tested in court.)
 > >  > 
 > >  >    In order to validate security implementations it is necessary to
 > >  >    agree on a pre-shared key in an out-of-band fashion.  Such a
 > >  >    technique is inherently problematic: the two parties must communicate
 > >  >    and agree upon a key using a medium which is, itself, probably
 > >  >    insecure.  By standardizing on a Pre-Shared Key for the Internet,
 > >  >    such communication is precluded.
 > >  > 
 > >  >    Additionally, the technique of pre-communication apriori to
 > >  >    subsequent communication has obvious scaling problems.  By
 > >  >    standardizing on a cannonical Pre-Shared Key for the Internet, pre-
 > >  >    shared keys now scale.
 > >  > 
 > >  >    Previous, non-standard attempts at agreeing on a pre-shared key were
 > >  >    deficient in their use of standard English.  For example, the ANX
 > >  >    sponsored IPSec bakeoffs rather confusingly used both
 > >  >    "whatcertificatereally" as well as the more standard key, "gwock".
 > >  >    By standardizing on Pidgin, the Pre-Shared Key for the Internet now
 > >  >    sounds, like, most cool.
 > >  > 
 > >  > 3. Terms and Definitions
 > >  > 
 > >  >    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
 > >  >    "MAY" that appear in this document are to be interpreted as described
 > >  >    in [Bra97].
 > >  > 
 > >  > 4. Pre-Shared Key Definition
 > >  > 
 > >  >    All security implementations that include support for pre-shared keys
 > >  >    MUST be capable of supporting the Pre-Shared Key for the Internet.
 > >  > 
 > >  >    The pre-shared key for the Internet is 14 octets in length.  It is
 > >  >    represented in ASCII as "mekmitasdigoat" without the accompanying
 > >  >    quotation marks.  In hexadecimal it is represented as:
 > >  >    0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
 > >  >    termination characters (such as a terminating NULL).
 > >  > 
 > >  > 
 > >  > 
 > >  > Piper, Harkins                                          	[Page 2]
 > >  > 
 > >  > INTERNET DRAFT                                             April 1, 1998
 > >  > 
 > >  > 
 > >  >    When used with [HC98], the pre-shared key for the Internet MUST be
 > >  >    used directly for authentication of the Phase 1 exchange ([HC98],
 > >  >    Section 5.4).
 > >  > 
 > >  >    When used with [KA98], the manual key for the Internet may need to be
 > >  >    expanded depending on the actual algorithmic requirements of the
 > >  >    corresponding security association.  Expansion of the key is
 > >  >    performed by successive concatenation until the required length has
 > >  >    been met or exceeded, but never both.
 > >  > 
 > >  >    Other used of pre-shared keys which require greater than 14 octets
 > >  >    MUST expand the Pre-Shared Key for the Internet in the manner
 > >  >    described above for use with [KA98]. Other uses which require less
 > >  >    than 14 octets MUST truncate the key to the required length.  Other
 > >  >    uses which require exactly 14 octets or have no limit to the length
 > >  >    of a pre-shared key MUST use the Pre-Shared Key for the Internet in
 > >  >    the manner described above for use with [HC98].
 > >  > 
 > >  > 5. Security Consideration
 > >  > 
 > >  >    The use of pre-shared keys has known security implications. When used
 > >  >    for authentication, the presentation of a shared secret is proof of
 > >  >    identity.  When used for datagram authentication, the pre-shared key
 > >  >    authenticates the content and source of the datagram.  Using the Pre-
 > >  >    Shared Key for the Internet will, in effect, allow you to
 > >  >    authenticate everyone.  One drawback is that this will negate the
 > >  >    effects of all related security protocols.
 > >  > 
 > >  > 6. Acknowledgments
 > >  > 
 > >  >    The authors would like to thank Roy Pereira, Steve Sneddon, William
 > >  >    Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, and
 > >  >    Randall Atkinson for their encouragement in writing this draft.
 > >  > 
 > >  > 10. References
 > >  > 
 > >  >    [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
 > >  >    Requirement Levels", RFC-2119, March 1997.
 > >  > 
 > >  >    [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
 > >  >    Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.
 > >  > 
 > >  >    [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
 > >  >    (ESP)," draft-ietf-ipsec-esp-v2-04.txt.
 > >  > 
 > >  >    [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
 > >  >    Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Piper, Harkins                                          	[Page 3]
 > >  > 
 > >  > INTERNET DRAFT                                             April 1, 1998
 > >  > 
 > >  > 
 > >  >    [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its
 > >  >    Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.
 > >  > 
 > >  >    [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
 > >  >    With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.
 > >  > 
 > >  >    [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
 > >  >    bitan-auth-des-mac-00.txt.
 > >  > 
 > >  >    [DOI] Piper, D., "The Internet IP Security Domain of Interpretation
 > >  >    for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.
 > >  > 
 > >  >    [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and
 > >  >    AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.
 > >  > 
 > >  >    [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
 > >  >    and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.
 > >  > 
 > >  >    [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
 > >  >    draft-ietf-ipsec-isakmp-oakley-06.txt.
 > >  > 
 > >  >    [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
 > >  >    Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
 > >  >    protocol-05.txt.
 > >  > 
 > >  >    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
 > >  >    "Internet Security Association and Key Management Protocol (ISAKMP),"
 > >  >    draft-ietf-ipsec-isakmp-09.{ps,txt}.
 > >  > 
 > >  >    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-
 > >  >    ietf-ipsec-oakley-02.txt.
 > >  > 
 > >  >    [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
 > >  >    Interconnection - The Directory:  Models", CCITT/ITU Recommendation
 > >  >    X.501, 1993.
 > >  > 
 > >  >    [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
 > >  >    Interconnection - The Directory:  Authentication Framework",
 > >  >    CCITT/ITU Recommendation X.509, 1993.
 > >  > 
 > >  > Authors' Addresses:
 > >  > 
 > >  >    Derrell Piper
 > >  >    The Electric Loft
 > >  >    41 6th Ave
 > >  >    Santa Cruz, CA 95060
 > >  >    hobbit@yoyodyne.com
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Piper, Harkins                                          	[Page 4]
 > >  > 
 > >  > INTERNET DRAFT                                             April 1, 1998
 > >  > 
 > >  > 
 > >  >    Dan Harkins
 > >  >    The Anvil Brewing Company
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Piper, Harkins                                          	[Page 5]
 > >  > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 06:55:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09759
	for ; Thu, 22 Mar 2001 06:55:41 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29737;
	Thu, 22 Mar 2001 03:53:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09985;
	Thu, 22 Mar 2001 03:52:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MBpaIm022969
	for ; Thu, 22 Mar 2001 03:51:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MBpajv022968
	for mobile-ip-dist; Thu, 22 Mar 2001 03:51:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MBpRIm022961
	for ; Thu, 22 Mar 2001 03:51:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09711
	for ; Thu, 22 Mar 2001 03:51:26 -0800 (PST)
Received: from mailgw.cica.es (erika.cica.es [150.214.1.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA01613
	for ; Thu, 22 Mar 2001 04:51:22 -0700 (MST)
Received: from cartuja.us.es (cartuja.us.es [193.147.161.37])
	by mailgw.cica.es (8.9.1/8.9.3) with ESMTP id MAA20500
	for ; Thu, 22 Mar 2001 12:51:20 +0100 (MET)
Received: from cartuja.us.es (esiproxy.us.es [193.147.160.146])
	by cartuja.us.es (8.9.3/8.9.1) with ESMTP id MAA02725
	for ; Thu, 22 Mar 2001 12:51:09 GMT
Message-ID: <3AB9E748.2B33C92B@cartuja.us.es>
Date: Thu, 22 Mar 2001 12:51:36 +0100
From: Susana Troyano 
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi all,


                    I am trying to get some commercial informations
about Mobile IP products.
                    I would be very grateful if someone could point me
towards web resources, contacts, articles...

                    Best regards



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 07:59:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10319
	for ; Thu, 22 Mar 2001 07:59:30 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12533;
	Thu, 22 Mar 2001 04:58:24 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20634;
	Thu, 22 Mar 2001 04:58:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MCv5Im023105
	for ; Thu, 22 Mar 2001 04:57:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MCv5Gs023104
	for mobile-ip-dist; Thu, 22 Mar 2001 04:57:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MCuuIm023097
	for ; Thu, 22 Mar 2001 04:56:56 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20477
	for ; Thu, 22 Mar 2001 04:56:55 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03938
	for ; Thu, 22 Mar 2001 04:56:53 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2MCuqC15206
	for ; Thu, 22 Mar 2001 13:56:52 +0100 (MET)
Received: from trojanhorse by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id NAA14917; Thu, 22 Mar 2001 13:56:51 +0100
Message-ID: <00a101c0b2ce$c22b5240$52b5d693@ericsson.se>
From: =?iso-8859-1?Q?Andr=E1s_M=E9hes?= 
To: 
References: <3AB8FA22.D232E181@iprg.nokia.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
Date: Thu, 22 Mar 2001 13:51:05 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id EAA12533
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA10319

What is the reason for the Hidden_Key
and the Binding Key Establishment suboption?
It seems as if the CN could compute the key itself.

> Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)

Am I missing something?

--andrás



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 10:48:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13424
	for ; Thu, 22 Mar 2001 10:48:24 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17449;
	Thu, 22 Mar 2001 07:44:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22796;
	Thu, 22 Mar 2001 07:23:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MFLgIm023306
	for ; Thu, 22 Mar 2001 07:21:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MFLffu023305
	for mobile-ip-dist; Thu, 22 Mar 2001 07:21:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MFLUIm023298
	for ; Thu, 22 Mar 2001 07:21:30 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21507;
	Thu, 22 Mar 2001 07:21:30 -0800 (PST)
Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06916;
	Thu, 22 Mar 2001 07:21:18 -0800 (PST)
Received: from potassium.cips.nokia.com (localhost [127.0.0.1])
	by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f2MFH2x55009;
	Thu, 22 Mar 2001 07:17:02 -0800 (PST)
	(envelope-from dharkins@potassium.cips.nokia.com)
Message-Id: <200103221517.f2MFH2x55009@potassium.cips.nokia.com>
To: Michael Thomas 
cc: mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: Your message of "Wed, 21 Mar 2001 19:55:28 PST."
             <15033.30640.461564.221205@thomasm-u1.cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <55006.985274222.1@potassium.cips.nokia.com>
Date: Thu, 22 Mar 2001 07:17:02 -0800
From: Dan Harkins 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
  I don't have any particular treaty organizations in mind. Any one will

suffice. Pick your favorite one. 

  My point was that you cannot authenticate a message with unauthenticated
keys and the same people that can muck with a binding update (which I assume
is motivating this) are the people who can play man-in-the-middle against
this scheme. That is regardless of the existence of, or the distaste in
using, some entity to act as a trusted third party.

  Dan.

On Wed, 21 Mar 2001 19:55:28 PST you wrote
> 
> Well, I didn't write that text but suffice it to
> say you still haven't answered my original
> question.
> 
> 		Mike
> 
> Dan Harkins writes:
>  >   Maybe you can explain to me how this key is being used to provide
>  > _authorization_ then. 
>  > 
>  >   Note that if you actually read the proposal you'd see that it says:
>  > "A method is proposed for providing key information for use between a
>  > mobile node and correspondent node, to be used for the purpose of
>  > *authenticating* Mobile IPv6 Binding Updates." (emphasis mine).
>  > 
>  >   Dan.
>  > 
>  > On Wed, 21 Mar 2001 15:35:05 PST you wrote
>  > > Dan Harkins writes:
>  > >  >   Oh darn, that's right. That pesky authentication stuff. 
>  > > 
>  > >   s/authentication/authorization and get back to me.
>  > > 
>  > > 			Mike
>  > > 
>  > > In that case I 
>  > >  > recommend you use the pre-shared key for the Internet. It was an Apri
>l
>  > >  > Fools draft but it provides you with the level of security you seem t
>o
>  > >  > want and doesn't have any of those nasty scaling problems associated
>  > >  > with public key infrastructure.
>  > >  > 
>  > >  >   I've attached a copy of it for you.
>  > >  > 
>  > >  >   Dan.
>  > >  > 
>  > >  > On Wed, 21 Mar 2001 15:02:12 PST you wrote
>  > >  > > Dan Harkins writes:
>  > >  > >  >   If the binding updates are important enough to require cryptog
>raphi
>  > >c
>  > >  > >  > protection then the keys have to be authenticated. 
>  > >  > > 
>  > >  > >  What treaty organization did you have in mind to be the
>  > >  > >  third party?
>  > >  > > 
>  > >  > >        Mike
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Network Working Group                 Derrell Piper, The Electric Lof
>t
>  > >  > INTERNET-DRAFT                      Dan Harkins, Anvil Brewing Compan
>y
>  > >  > draft-ieft-ipsec-internet-key-00.txt                     April 1, 199
>8
>  > >  > 
>  > >  > 
>  > >  >               The Pre-Shared Key for the Internet Protocol
>  > >  >                  
>  > >  > 
>  > >  > 
>  > >  >                           Status of this Memo
>  > >  > 
>  > >  >    This document is an Internet Draft. Internet Drafts are working
>  > >  >    documents of the Internet Engineering Task Force (IETF), its areas
>,
>  > >  >    and 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 mon
>ths
>  > >  >    and may be updated, replaced, or obsoleted by other documents at a
>ny
>  > >  >    time. It is inappropriate to use Internet Drafts as reference
>  > >  >    material or to cite them other than as "work in progress."
>  > >  > 
>  > >  >    To learn the current status of any Internet Draft, please check th
>e
>  > >  >    "1id-abstracts.txt" listing contained in the Internet Drafts Shado
>w
>  > >  >    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
>  > >  >    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
>  > >  >    ftp.isi.edu (US West Coast).
>  > >  > 
>  > >  > 
>  > >  >       0. Table Of Contents
>  > >  >       1. Abstract
>  > >  >       2. Discussion
>  > >  >       3. Terms and Definitions
>  > >  >       4. Pre-Shared Key Definition
>  > >  >       5. Security Considerations
>  > >  >       6. Acknowledgments
>  > >  >       7. References
>  > >  > 
>  > >  > 
>  > >  > 1. Abstract
>  > >  > 
>  > >  >    Recent efforts from the IPsec Working Group of the IETF in securin
>g
>  > >  >    the Internet ([AH], [KA98], [ESP], [ESPCBC], [ESPNULL], [DES],
>  > >  >    [DESMAC], [HMACMD5], [HMACSHA], [HC98], [DOI], [IPCOMP], [ISAKMP],
>  > >  >    and [OAKLEY]) imply the continued use of pre-shared keys.  This
>  > >  >    document defines the Pre-Shared Key for the Internet.
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Piper, Harkins                                          	[Page 1
>]
>  > >  > 
>  > >  > INTERNET DRAFT                                             April 1, 1
>998
>  > >  > 
>  > >  > 
>  > >  > 2. Discussion
>  > >  > 
>  > >  >    Pre-shared keys are normally used for interoperability purposes.  
>The
>  > >  >    basic idea is that two parties sharing a common secret can
>  > >  >    communicate securely.  This idea has been used since cryptography
>  > >  >    first sprung onto the scene.  For a complete history of cryptograp
>hy,
>  > >  >    see Wired magazine.
>  > >  > 
>  > >  >    An additional motivation is that pre-shared keys are, for the most
>  > >  >    part, unencumbered technology.  (It's speculated that RSA Data
>  > >  >    Security, Inc. has made various claims relating to use of pre-shar
>ed
>  > >  >    keys, but these claims have not yet been tested in court.)
>  > >  > 
>  > >  >    In order to validate security implementations it is necessary to
>  > >  >    agree on a pre-shared key in an out-of-band fashion.  Such a
>  > >  >    technique is inherently problematic: the two parties must communic
>ate
>  > >  >    and agree upon a key using a medium which is, itself, probably
>  > >  >    insecure.  By standardizing on a Pre-Shared Key for the Internet,
>  > >  >    such communication is precluded.
>  > >  > 
>  > >  >    Additionally, the technique of pre-communication apriori to
>  > >  >    subsequent communication has obvious scaling problems.  By
>  > >  >    standardizing on a cannonical Pre-Shared Key for the Internet, pre
>-
>  > >  >    shared keys now scale.
>  > >  > 
>  > >  >    Previous, non-standard attempts at agreeing on a pre-shared key we
>re
>  > >  >    deficient in their use of standard English.  For example, the ANX
>  > >  >    sponsored IPSec bakeoffs rather confusingly used both
>  > >  >    "whatcertificatereally" as well as the more standard key, "gwock".
>  > >  >    By standardizing on Pidgin, the Pre-Shared Key for the Internet no
>w
>  > >  >    sounds, like, most cool.
>  > >  > 
>  > >  > 3. Terms and Definitions
>  > >  > 
>  > >  >    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" an
>d
>  > >  >    "MAY" that appear in this document are to be interpreted as descri
>bed
>  > >  >    in [Bra97].
>  > >  > 
>  > >  > 4. Pre-Shared Key Definition
>  > >  > 
>  > >  >    All security implementations that include support for pre-shared k
>eys
>  > >  >    MUST be capable of supporting the Pre-Shared Key for the Internet.
>  > >  > 
>  > >  >    The pre-shared key for the Internet is 14 octets in length.  It is
>  > >  >    represented in ASCII as "mekmitasdigoat" without the accompanying
>  > >  >    quotation marks.  In hexadecimal it is represented as:
>  > >  >    0x6d656b6d697461736469676f6174.  There MUST NOT be any additional
>  > >  >    termination characters (such as a terminating NULL).
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Piper, Harkins                                          	[Page 2
>]
>  > >  > 
>  > >  > INTERNET DRAFT                                             April 1, 1
>998
>  > >  > 
>  > >  > 
>  > >  >    When used with [HC98], the pre-shared key for the Internet MUST be
>  > >  >    used directly for authentication of the Phase 1 exchange ([HC98],
>  > >  >    Section 5.4).
>  > >  > 
>  > >  >    When used with [KA98], the manual key for the Internet may need to
> be
>  > >  >    expanded depending on the actual algorithmic requirements of the
>  > >  >    corresponding security association.  Expansion of the key is
>  > >  >    performed by successive concatenation until the required length ha
>s
>  > >  >    been met or exceeded, but never both.
>  > >  > 
>  > >  >    Other used of pre-shared keys which require greater than 14 octets
>  > >  >    MUST expand the Pre-Shared Key for the Internet in the manner
>  > >  >    described above for use with [KA98]. Other uses which require less
>  > >  >    than 14 octets MUST truncate the key to the required length.  Othe
>r
>  > >  >    uses which require exactly 14 octets or have no limit to the lengt
>h
>  > >  >    of a pre-shared key MUST use the Pre-Shared Key for the Internet i
>n
>  > >  >    the manner described above for use with [HC98].
>  > >  > 
>  > >  > 5. Security Consideration
>  > >  > 
>  > >  >    The use of pre-shared keys has known security implications. When u
>sed
>  > >  >    for authentication, the presentation of a shared secret is proof o
>f
>  > >  >    identity.  When used for datagram authentication, the pre-shared k
>ey
>  > >  >    authenticates the content and source of the datagram.  Using the P
>re-
>  > >  >    Shared Key for the Internet will, in effect, allow you to
>  > >  >    authenticate everyone.  One drawback is that this will negate the
>  > >  >    effects of all related security protocols.
>  > >  > 
>  > >  > 6. Acknowledgments
>  > >  > 
>  > >  >    The authors would like to thank Roy Pereira, Steve Sneddon, Willia
>m
>  > >  >    Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, David Carrel, a
>nd
>  > >  >    Randall Atkinson for their encouragement in writing this draft.
>  > >  > 
>  > >  > 10. References
>  > >  > 
>  > >  >    [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
>  > >  >    Requirement Levels", RFC-2119, March 1997.
>  > >  > 
>  > >  >    [ARCH] Kent, S., Atkinson, R., "Security Architecture for the
>  > >  >    Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt.
>  > >  > 
>  > >  >    [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
>  > >  >    (ESP)," draft-ietf-ipsec-esp-v2-04.txt.
>  > >  > 
>  > >  >    [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
>  > >  >    Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt.
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Piper, Harkins                                          	[Page 3
>]
>  > >  > 
>  > >  > INTERNET DRAFT                                             April 1, 1
>998
>  > >  > 
>  > >  > 
>  > >  >    [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 
>Its
>  > >  >    Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt.
>  > >  > 
>  > >  >    [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
>  > >  >    With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt.
>  > >  > 
>  > >  >    [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
>  > >  >    bitan-auth-des-mac-00.txt.
>  > >  > 
>  > >  >    [DOI] Piper, D., "The Internet IP Security Domain of Interpretatio
>n
>  > >  >    for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt.
>  > >  > 
>  > >  >    [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP a
>nd
>  > >  >    AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt.
>  > >  > 
>  > >  >    [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within 
>ESP
>  > >  >    and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt.
>  > >  > 
>  > >  >    [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
>  > >  >    draft-ietf-ipsec-isakmp-oakley-06.txt.
>  > >  > 
>  > >  >    [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
>  > >  >    Payload Compression Protocol (IPComp)," draft-ietf-ippcp-
>  > >  >    protocol-05.txt.
>  > >  > 
>  > >  >    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.
>,
>  > >  >    "Internet Security Association and Key Management Protocol (ISAKMP
>),"
>  > >  >    draft-ietf-ipsec-isakmp-09.{ps,txt}.
>  > >  > 
>  > >  >    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," dra
>ft-
>  > >  >    ietf-ipsec-oakley-02.txt.
>  > >  > 
>  > >  >    [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
>  > >  >    Interconnection - The Directory:  Models", CCITT/ITU Recommendatio
>n
>  > >  >    X.501, 1993.
>  > >  > 
>  > >  >    [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
>  > >  >    Interconnection - The Directory:  Authentication Framework",
>  > >  >    CCITT/ITU Recommendation X.509, 1993.
>  > >  > 
>  > >  > Authors' Addresses:
>  > >  > 
>  > >  >    Derrell Piper
>  > >  >    The Electric Loft
>  > >  >    41 6th Ave
>  > >  >    Santa Cruz, CA 95060
>  > >  >    hobbit@yoyodyne.com
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Piper, Harkins                                          	[Page 4
>]
>  > >  > 
>  > >  > INTERNET DRAFT                                             April 1, 1
>998
>  > >  > 
>  > >  > 
>  > >  >    Dan Harkins
>  > >  >    The Anvil Brewing Company
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > Piper, Harkins                                          	[Page 5
>]
>  > >  > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 12:27:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15469
	for ; Thu, 22 Mar 2001 12:27:53 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02214;
	Thu, 22 Mar 2001 09:25:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14793;
	Thu, 22 Mar 2001 09:25:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MHNsIm023549
	for ; Thu, 22 Mar 2001 09:23:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MHNsDA023548
	for mobile-ip-dist; Thu, 22 Mar 2001 09:23:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MHNiIm023541
	for ; Thu, 22 Mar 2001 09:23:44 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13535
	for ; Thu, 22 Mar 2001 09:23:44 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05260
	for ; Thu, 22 Mar 2001 09:23:35 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 22 Mar 2001 11:21:39 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 22 Mar 2001 11:21:30 -0600
Message-ID: 
From: "Haseeb Akhtar" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: RE: [mobile-ip] Drafty draft about key establishment for Binding Update
Date: Thu, 22 Mar 2001 11:21:23 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B2F4.84F643F0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B2F4.84F643F0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,

While Pekka's observation is correct, that situation exits today 
irrespective of the Binding Warning message. 
Any potential attacker can send myriad of messages, including 
the Binding Update Option, to the CN.

I have another question. Are we assuming that the route between
the CN and HA is safe from man-in-the-middle?

Regards,

Haseeb



-----Original Message-----
From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]
Sent: Wednesday, March 21, 2001 1:32 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: 'T.J. Kniveton'; Carl Williams; Alper Yegin; Brian Zill; Michael
Thomas
Subject: Re: [mobile-ip] Drafty draft about key establishment for
Binding Update


Charlie Perkins wrote:
>
> Here's what I wrote up last night after our
> meeting in Salon A.

As an immediate response, there seems to be a potential new
DoS attack that may need addressing.  That is, when the CN
receives a Binding Warning, it creates a cookie, and basically
stores either a  or a  pair 
to wait for the Binding Update that it expects to receive from 
the MN.  It must store this pair since otherwise it couldn't 
turn the Hidden_key into the Key etc.  

Now, a potential attacker could easily send zillions of 
Binding Warnings, using different CoA:s and Home Addresses,
leading to a DoS similar to TCP SYN flooding.

Other attacks will follow as soon as I figure out how to do them :-)

--Pekka

------_=_NextPart_001_01C0B2F4.84F643F0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] Drafty draft about key establishment for Binding Update




Hello all,




While Pekka's observation is correct, that situation exits today 

irrespective of the Binding Warning message. 

Any potential attacker can send myriad of messages, including 

the Binding Update Option, to the CN.




I have another question. Are we assuming that the route between

the CN and HA is safe from man-in-the-middle?




Regards,




Haseeb








-----Original Message-----

From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]

Sent: Wednesday, March 21, 2001 1:32 PM

To: mobile-ip@sunroof.eng.sun.com

Cc: 'T.J. Kniveton'; Carl Williams; Alper Yegin; Brian Zill; Michael

Thomas

Subject: Re: [mobile-ip] Drafty draft about key establishment for

Binding Update






Charlie Perkins wrote:

>

> Here's what I wrote up last night after our

> meeting in Salon A.




As an immediate response, there seems to be a potential new

DoS attack that may need addressing.  That is, when the CN

receives a Binding Warning, it creates a cookie, and basically

stores either a <Home Address, Cookie> or a <CoA, Cookie> pair 

to wait for the Binding Update that it expects to receive from 

the MN.  It must store this pair since otherwise it couldn't 

turn the Hidden_key into the Key etc.  




Now, a potential attacker could easily send zillions of 

Binding Warnings, using different CoA:s and Home Addresses,

leading to a DoS similar to TCP SYN flooding.




Other attacks will follow as soon as I figure out how to do them :-)




--Pekka





------_=_NextPart_001_01C0B2F4.84F643F0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 14:40:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18936
	for ; Thu, 22 Mar 2001 14:40:20 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12257;
	Thu, 22 Mar 2001 11:39:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10339;
	Thu, 22 Mar 2001 11:39:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJZxIm024072
	for ; Thu, 22 Mar 2001 11:35:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MJZxNm024071
	for mobile-ip-dist; Thu, 22 Mar 2001 11:35:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJZoIm024064
	for ; Thu, 22 Mar 2001 11:35:50 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09337
	for ; Thu, 22 Mar 2001 11:35:49 -0800 (PST)
Received: from htt-consult.com ([63.82.18.210])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA08501
	for ; Thu, 22 Mar 2001 12:35:40 -0700 (MST)
Received: from rgm.htt-consult.com ([63.82.18.214]) by htt-consult.com ; Thu, 22 Mar 2001 14:35:36 -0500
Message-Id: <5.0.0.25.2.20010322132654.00b16790@localhost>
X-Sender: rgm-ietf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 22 Mar 2001 13:28:26 -0600
To: mobile-ip@sunroof.eng.sun.com
From: Robert Moskowitz 
Subject: RE: [mobile-ip] Drafty draft about key establishment for
  Binding Update
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_310173145==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--=====================_310173145==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:

>I have another question. Are we assuming that the route between
>the CN and HA is safe from man-in-the-middle?

This was NOT the case on the San Diego wireless where we where having 
someone trying to do MITH attacks against SSH.

As wireless deployments go, this becomes more of a problem.



--=====================_310173145==_.ALT
Content-Type: text/html; charset="us-ascii"


At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:




I have another
question. Are we assuming that the route between 

the CN and HA is safe from man-in-the-middle?



This was NOT the case on the San Diego wireless where we where having someone trying to do MITH attacks against SSH.



As wireless deployments go, this becomes more of a problem.







--=====================_310173145==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 15:15:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20138
	for ; Thu, 22 Mar 2001 15:15:42 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08904;
	Thu, 22 Mar 2001 12:14:14 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29915;
	Thu, 22 Mar 2001 12:13:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MK38Im024145
	for ; Thu, 22 Mar 2001 12:03:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MK37qC024144
	for mobile-ip-dist; Thu, 22 Mar 2001 12:03:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MK2xIm024137
	for ; Thu, 22 Mar 2001 12:02:59 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04056;
	Thu, 22 Mar 2001 12:02:53 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA13448;
	Thu, 22 Mar 2001 12:01:43 -0800 (PST)
From: James Kempf 
Message-Id: <200103222001.MAA13448@heliopolis.Eng.Sun.COM>
Date: Thu, 22 Mar 2001 14:02:05 -0700
To: , , ,
        
Subject: [mobile-ip] Re: [seamoby] Header compression context extablishment
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Mike,

Thanx for your response. Two questions.

>1) send a small number of IR packets with a header size roughly similar
>to the header size of uncompressed headers. I expect that most
>implementations will send roughly 3 IR packets.
>
>If operating in U-mode or O-mode, this completes the context
>initialization, and minimal packets will be sent henceforth.
>U-mode can do an exponential backoff when sending IR packets, 
>but the typical transition to O-mode or R-mode will prevent 
>those IR packets from being sent. 
>
>If operation in R-mode is desired, the minimal packets will be
>sent until an acknowledgment (containing a mode transition request)
>reaches the compressor. Then, 
>
>2) during an additional roundtrip, non-minimal headers are sent during
>transition to R-mode. 
>
>
>Some parameters are as follows:
>
>link roundtrip for cellular: 120-200 milliseconds.
>(6-10 packets at 50 packets per second).
>

Does the compressor have to start from scratch if the IP address in the
header changes? The issue here is that on a mobile IP handover, the
care of address will change. The mobile IP group is working hard
on low latency handover protocols. If the mobile node is forced to
go through a 120-200 ms compressor initialization period, the benefits
of low latency handoff will be substantially negated.

>Minimal headers are 1 byte. 
>
>Header size in 2) is rougly 4 bytes.
>
>The header sizes indicated above do not include context identifiers,
>which can be omitted completely for context identifier zero. 
>Nor do they include the two-byte UDP checksum, which will not be sent at
>all if disabled. Nor do they include the two byte IPv4 Identifier, 
>which will be sent as-is if it changes randomly. Reasonable IP stacks
>will have it change in increments of one, and then it will be 
>completely removed. 
>

Does this analysis change at all for IPv6? Most of our discussion
has been about IPv6 since the need for header compression is much
more urgent, due to the large header size.

			jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 18:54:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26513
	for ; Thu, 22 Mar 2001 18:54:13 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05273;
	Thu, 22 Mar 2001 15:53:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05942;
	Thu, 22 Mar 2001 15:53:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNpBIm024565
	for ; Thu, 22 Mar 2001 15:51:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2MNpB52024564
	for mobile-ip-dist; Thu, 22 Mar 2001 15:51:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MNp2Im024557
	for ; Thu, 22 Mar 2001 15:51:02 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05293
	for ; Thu, 22 Mar 2001 15:51:02 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03502
	for ; Thu, 22 Mar 2001 15:51:01 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA06662
	for ; Thu, 22 Mar 2001 15:51:21 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADB28614;
	Thu, 22 Mar 2001 15:51:00 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01310; Thu, 22 Mar 2001 15:51:00 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15034.36836.167049.735679@thomasm-u1.cisco.com>
Date: Thu, 22 Mar 2001 15:51:00 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Drafty draft about key establishment for
  Binding Update
In-Reply-To: <5.0.0.25.2.20010322132654.00b16790@localhost>
References: 
	<5.0.0.25.2.20010322132654.00b16790@localhost>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Robert Moskowitz writes:
 > At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:
 > 
 > >I have another question. Are we assuming that the route between
 > >the CN and HA is safe from man-in-the-middle?
 > 
 > This was NOT the case on the San Diego wireless where we where having 
 > someone trying to do MITH attacks against SSH.

   Is this actually the case? I think that there's
   a difference between a snooper on the edge and
   a true man in the middle. A true man in the 
   middle would be able to spoof both sides completely
   unawares by both parties. A snooper on the edge 
   cannot easily keep this property for more than a
   single message typically -- at least with any of
   the network technologies I can think of off the
   top of my head. 

   In particular for the 802.11 situation in SD, I 
   believe that you'd have to spoof being an 
   802.11 access point which, if nothing else, 
   would require the spoofer to do all the normal
   mac/phy things an AP does including -- hopefully --
   802.1x or some L3 replacement for same.

	     Mike

 > 
 > As wireless deployments go, this becomes more of a problem.
 > 
 > 
 > 
 > At 11:21 AM 3/22/2001 -0600, Haseeb Akhtar wrote:

 > 

 > 
I have another
 > question. Are we assuming that the route between 

 > the CN and HA is safe from man-in-the-middle?
 > 


 > This was NOT the case on the San Diego wireless where we where having someone trying to do MITH attacks against SSH.

 > 

 > As wireless deployments go, this becomes more of a problem.

 > 

 > 

 > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 22 20:32:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29391
	for ; Thu, 22 Mar 2001 20:32:56 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13476;
	Thu, 22 Mar 2001 17:31:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06977;
	Thu, 22 Mar 2001 17:30:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2N1TUIm024929
	for ; Thu, 22 Mar 2001 17:29:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2N1TT3d024928
	for mobile-ip-dist; Thu, 22 Mar 2001 17:29:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2N1TKIm024921
	for ; Thu, 22 Mar 2001 17:29:20 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29140;
	Thu, 22 Mar 2001 17:29:19 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA22400;
	Thu, 22 Mar 2001 17:29:14 -0800 (PST)
From: James Kempf 
Message-Id: <200103230129.RAA22400@heliopolis.Eng.Sun.COM>
Date: Thu, 22 Mar 2001 19:28:28 -0700
To: "Mikael Degermark" 
Cc: , ,
        
Subject: [mobile-ip] Re: [seamoby] Header compression context extablishment
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Michael,

Thanx for your reply.

>We need to talk about exact header formats before I can give
>an exact answer. The answer may be different for IPv4 and IPv6.
>

As we discussed, there will be a difference. For IPv4, the
compressor context will not include the care of address because
the Foreign Agent will strip the tunnel header before compressing. For IPv6,
co-located care-of addresses are implicitly assumed, so 
the care-of address will change.

>Your comment regarding low-latency handoff may be understood to 
>mean that you think that no packet can be sent during the initial 
>120-200 ms. 
>

OK, yes that was a concern, but it will just mean that the first
few packets are uncompressed and so slower. This makes the analysis a bit more
complex, but the upshot is that it would still mean a delay.

>Packets can be sent at any time, it is just that the first 3 are
>normal size packets, without significantly reduced size. After those
>three (or so), headers will be compressed. 
>
>I think we need to talk more. Are you available at 17.30 ?
>Let us meet in the lobby (street level) to talk. Is that 
>possible?
>

Right, as we discussed, I will attempt to locate some
IPv6 headers for you that illustrate the problem.

It would probably be good to co-ordinate between ROHC
and Seamoby context transfer design team so that
we can get this right, since our discussion in the
hotel lobby basically indicated that there may be
some tricky co-ordination issues between the mobile
node and the access router if the CoA header needs
to change.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 08:44:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11523
	for ; Fri, 23 Mar 2001 08:44:13 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25162;
	Fri, 23 Mar 2001 05:41:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24832;
	Fri, 23 Mar 2001 05:41:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NDdKIm025716
	for ; Fri, 23 Mar 2001 05:39:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NDdJ8D025715
	for mobile-ip-dist; Fri, 23 Mar 2001 05:39:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NDdAIm025708
	for ; Fri, 23 Mar 2001 05:39:10 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24544
	for ; Fri, 23 Mar 2001 05:39:10 -0800 (PST)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA23693
	for ; Fri, 23 Mar 2001 05:39:09 -0800 (PST)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Fri, 23 Mar 2001 14:31:57 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD18@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 
To: "'Pekka Nikander'" ,
        KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia
	 
Subject: [mobile-ip] RE: Comments to draft-kassi-mobileip-dmi-00.txt
Date: Fri, 23 Mar 2001 14:12:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2NDdBIm025709
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id FAA25162
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11523

Hello,

I agree with you, the MN must be authenticated by the access network before
it can exchange a traffic with others (HA, CN...). This will be the case for
all visited (foreign) networks of mobile service provider. And it will be
the same for other mobility situation (between company sites...).

For Input connections, the suggestion is to establish the communication
without using Mobile IP. The security issue between MN and CN is not
discussed in this draft. This issue is a common issue for the mobility in IP
networks.

I'm not attending the meeting, thanks for your comments.

Best regards,

-----Message d'origine-----
De : Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]
Envoyé : mercredi 21 mars 2001 18:07
À : KASSI-LAHLOU Mohammed FTRD/DMI/CAE
Cc : mobile-ip@sunroof.eng.sun.com; Claude Castelluccia
Objet : Comments to draft-kassi-mobileip-dmi-00.txt


KASSI-LAHLOU Mohammed FTRD/DMI/CAE wrote:

> If the home address belongs to a virtual network or if at every new
> communication it uses the address obtained in the visited network as a
> source address (as specified in draft-kassi-mobileip-dmi-00.txt) you can
> know that the mobile node is in movement but without having a point of

Nice draft.  Very much in line with our Homeless Mobile IPv6 thinking,
but not going quite that far as we attempt to go.

However, I think that even though the Security Considerations section
may be technically correct, in the practise the situation is different.
That is, one may reasonably assume that a MN has a permanent security
association (in some form) with its permanent or real HA.  However,
I have serious doubts about our ability to provide a scaleable solution
for creating security associations between an MN and the temporary
HA used to forward connections opened while at a foreign link.
Yes, I know, with AAA we most probably will be able to do that, but
I don't believe that AAA will ever scale enough to cover all of the
Internet.  (This is not a technical concern but a deployment concern.)

The case of not having a (conceptual) security association between a MN
and its HA is much harder from the security point of view than the case
where you do have such a security association.  Your grounds for providing
authorization evidence to the CN are much slimmer.  

I suggest that you reconsider your draft in the light of the Mobile IPv6
security discussion to be held tomorrow at the Mobileip WG meeting.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 12:46:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28171
	for ; Fri, 23 Mar 2001 12:46:44 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16491;
	Fri, 23 Mar 2001 09:45:12 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29800;
	Fri, 23 Mar 2001 09:45:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NHhbIm026232
	for ; Fri, 23 Mar 2001 09:43:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NHhajO026231
	for mobile-ip-dist; Fri, 23 Mar 2001 09:43:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NHhRIm026224
	for ; Fri, 23 Mar 2001 09:43:27 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2NHgCs25013;
	Fri, 23 Mar 2001 09:42:12 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103231742.f2NHgCs25013@locked.eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
In-Reply-To: <200103212026.f2LKQqA40104@givry.rennes.enst-bretagne.fr> from Francis
 Dupont at "Mar 21, 2001 09:26:52 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 23 Mar 2001 09:42:11 -0800 (PST)
CC: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I think this discussion will go on and on and we will eventually  end 
up re-inventing IKE. Why can't we just do IKE phase I using self
signed certificates (as suggested by someone...) and use this
shared secret to generate a token (SHA-1(Home address, care of address,
sequence number, Secret) - which will be used to tell the correspondent
node that you have moved. 

I will write up something more formal on this.

-mohan
>    The key districution is secure except against man-in-the-middle
>    attacks, when the attacker resides in the routing path between
>    the correspondent node and the mobile node's home agent.
> 
> => this is enough to assume real trouble if this is used between
> two mobile nodes (even I am sceptical some have predicted that
> a large part of the Internet will be mobile.
> 
> Sorry
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: I believe we need the two essential parts of IKE phase one:
>  - shared secret with Diffie-Hellman or similar mechanisms
>  - authentication (binding acknowledgement needs symetrical
>    authentication)
> The first must be end-to-end, the second is the hard part but
> easier to provide, for instance if you have a third party (like
> between MN-HA using the AAA network, cf draft-perkins-aaav6-03.txt
> or instantiation draft-dupont-mipv6-aaa-00.txt).
> We can reuse many ideas of the authentication/authorization brain
> storming (I have archives). 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 13:48:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00555
	for ; Fri, 23 Mar 2001 13:48:02 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04843;
	Fri, 23 Mar 2001 10:46:12 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13866;
	Fri, 23 Mar 2001 10:45:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NIiQIm026480
	for ; Fri, 23 Mar 2001 10:44:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NIiQuB026479
	for mobile-ip-dist; Fri, 23 Mar 2001 10:44:26 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NIiKIm026472
	for ; Fri, 23 Mar 2001 10:44:21 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05049
	for ; Fri, 23 Mar 2001 13:44:19 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA15022
	for mobile-ip@sunroof.eng.sun.com; Fri, 23 Mar 2001 13:44:27 -0500 (EST)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MJQGIm024031
	for ; Thu, 22 Mar 2001 11:26:16 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14358
	for ; Thu, 22 Mar 2001 11:26:15 -0800 (PST)
From: micke@CS.Arizona.EDU
Received: from optima.CS.Arizona.EDU (optima.CS.Arizona.EDU [192.12.69.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28916
	for ; Thu, 22 Mar 2001 12:26:13 -0700 (MST)
Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35])
	by optima.CS.Arizona.EDU (8.11.1/8.11.1) with ESMTP id f2MJMfl10713;
	Thu, 22 Mar 2001 12:22:41 -0700 (MST)
Received: (from micke@localhost)
	by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f2MJPhM00633;
	Thu, 22 Mar 2001 12:25:43 -0700 (MST)
Date: Thu, 22 Mar 2001 12:25:43 -0700 (MST)
Message-Id: <200103221925.f2MJPhM00633@baskerville.CS.Arizona.EDU>
X-Authentication-Warning: baskerville.CS.Arizona.EDU: micke set sender to micke@cs.arizona.edu using -r
To: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@cdma-2000.org
Subject: [mobile-ip] Header compression context extablishment
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, rohc@cdt.luth.se

Re: Header compression state establishment
==========================================

Folks, 

It has come to my attention that some more or less
informed statements have been made regarding header
compression and how efficient/inefficient (re)establishment
of header compression state might be. 

In particular, the statements made in 

draft-ietf-seamoby-context-transfer-problem-stat-00.txt

are not completely accurate. This is an attempt to clarify the
situation for the header compression methodology developed in the 
ROHC WG.

The typical startup scenario for the ROHC header compression
schemes for telephony streams is as follows:

1) send a small number of IR packets with a header size roughly similar
to the header size of uncompressed headers. I expect that most
implementations will send roughly 3 IR packets.

If operating in U-mode or O-mode, this completes the context
initialization, and minimal packets will be sent henceforth.
U-mode can do an exponential backoff when sending IR packets, 
but the typical transition to O-mode or R-mode will prevent 
those IR packets from being sent. 

If operation in R-mode is desired, the minimal packets will be
sent until an acknowledgment (containing a mode transition request)
reaches the compressor. Then, 

2) during an additional roundtrip, non-minimal headers are sent during
transition to R-mode. 


Some parameters are as follows:

link roundtrip for cellular: 120-200 milliseconds.
(6-10 packets at 50 packets per second).

Minimal headers are 1 byte. 

Header size in 2) is rougly 4 bytes.

The header sizes indicated above do not include context identifiers,
which can be omitted completely for context identifier zero. 
Nor do they include the two-byte UDP checksum, which will not be sent at
all if disabled. Nor do they include the two byte IPv4 Identifier, 
which will be sent as-is if it changes randomly. Reasonable IP stacks
will have it change in increments of one, and then it will be 
completely removed. 

Hope this has helped to clarify the situation with regards to header
compression and its context (re) initialization. 


Mikael Degermark
Co-chair, ROHC WG







From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 13:48:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00590
	for ; Fri, 23 Mar 2001 13:48:57 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16888;
	Fri, 23 Mar 2001 10:47:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15355;
	Fri, 23 Mar 2001 10:47:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NIkSIm026490
	for ; Fri, 23 Mar 2001 10:46:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NIkS0K026489
	for mobile-ip-dist; Fri, 23 Mar 2001 10:46:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NIkLIm026482
	for ; Fri, 23 Mar 2001 10:46:22 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07787
	for ; Fri, 23 Mar 2001 13:46:21 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA15062
	for mobile-ip@sunroof.eng.sun.com; Fri, 23 Mar 2001 13:46:28 -0500 (EST)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2MLqQIm024360
	for ; Thu, 22 Mar 2001 13:52:26 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02909;
	Thu, 22 Mar 2001 13:52:24 -0800 (PST)
Received: from optima.CS.Arizona.EDU (optima.CS.Arizona.EDU [192.12.69.5])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08927;
	Thu, 22 Mar 2001 13:52:23 -0800 (PST)
Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35])
	by optima.CS.Arizona.EDU (8.11.1/8.11.1) with ESMTP id f2MLnDl13015;
	Thu, 22 Mar 2001 14:49:14 -0700 (MST)
Received: (from micke@localhost)
	by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f2MLqGU03116;
	Thu, 22 Mar 2001 14:52:16 -0700 (MST)
Date: Thu, 22 Mar 2001 14:52:16 -0700 (MST)
From: Mikael Degermark 
Message-Id: <200103222152.f2MLqGU03116@baskerville.CS.Arizona.EDU>
To: kempf@heliopolis.eng.sun.com
Subject: [mobile-ip] Re: [seamoby] Header compression context extablishment
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@cdma-2000.org
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi James, 

We need to talk about exact header formats before I can give
an exact answer. The answer may be different for IPv4 and IPv6.

Your comment regarding low-latency handoff may be understood to 
mean that you think that no packet can be sent during the initial 
120-200 ms. 

Packets can be sent at any time, it is just that the first 3 are
normal size packets, without significantly reduced size. After those
three (or so), headers will be compressed. 

I think we need to talk more. Are you available at 17.30 ?
Let us meet in the lobby (street level) to talk. Is that 
possible?

Cheers,

Mikael Degermark


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 16:08:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03825
	for ; Fri, 23 Mar 2001 16:07:59 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03114;
	Fri, 23 Mar 2001 13:06:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20172;
	Fri, 23 Mar 2001 13:06:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NL56Im026872
	for ; Fri, 23 Mar 2001 13:05:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NL55Il026871
	for mobile-ip-dist; Fri, 23 Mar 2001 13:05:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NL4rIm026864
	for ; Fri, 23 Mar 2001 13:04:53 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17241
	for ; Fri, 23 Mar 2001 13:04:48 -0800 (PST)
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04340
	for ; Fri, 23 Mar 2001 13:04:47 -0800 (PST)
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id QAA16792 for ; Fri, 23 Mar 2001 16:04:46 -0500 (EST)
From: "Andrew T. Campbell" 
To: 
Subject: [mobile-ip] Software release of the Columbia IP Micro-Mobility Suite (CIMS)
Date: Fri, 23 Mar 2001 16:03:50 -0800
Message-ID: <000901c0b3f5$e8bbb8f0$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 IP Micro-mobility has been a hot topic over the
Content-Transfer-Encoding: 7bit

the last few years. 

We have released the Columbia IP Micro-Mobility Suite (CIMS) 

http://www.comet.columbia.edu/micromobility/

that includes an ns 2 extension for the 
following IP micro-mobility protocols:

-Cellular IP  (draft-ietf-mobileip-cellularip-00.txt)
-HAWAII  (draft-ietf-mobileip-hawaii-00.txt)
-Hierarchical Mobile IP   (draft-ietf-mobileip-reg-tunnel-04.txt) 

The Cellular IP implementation supports hard and semi-soft handoff, 
and IP paging. The Hawaii implementation supports Unicast 
Non-Forwarding (UNF) and Multiple Stream Forwarding (MSF) schemes. 
Hawaii's IP paging capability is currently not supported. 
In addition, the CIMS implementation of Hierarchical Mobile IP 
currently does not support IP paging. These and other features 
will be added in due course - we would be happy to add any 
extensions worked on by other groups to the next release of CIMS.

Best,
---
Andrew
http://comet.columbia.edu/~campbell



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 17:11:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05049
	for ; Fri, 23 Mar 2001 17:11:26 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00834;
	Fri, 23 Mar 2001 14:10:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05394;
	Fri, 23 Mar 2001 14:10:07 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NM8bIm027144
	for ; Fri, 23 Mar 2001 14:08:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2NM8bEi027143
	for mobile-ip-dist; Fri, 23 Mar 2001 14:08:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2NM8SIm027136
	for ; Fri, 23 Mar 2001 14:08:28 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2NM6wP25186;
	Fri, 23 Mar 2001 14:06:58 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103232206.f2NM6wP25186@locked.eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
In-Reply-To: <3AB9019B.397D1EB7@nomadiclab.com> from Pekka Nikander at "Mar 21,
 2001 09:31:39 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 23 Mar 2001 14:06:58 -0800 (PST)
CC: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Charlie Perkins wrote:
> >
> > Here's what I wrote up last night after our
> > meeting in Salon A.
> 
> As an immediate response, there seems to be a potential new
> DoS attack that may need addressing.  That is, when the CN
> receives a Binding Warning, it creates a cookie, and basically
> stores either a  or a  pair 
> to wait for the Binding Update that it expects to receive from 
> the MN.  It must store this pair since otherwise it couldn't 
> turn the Hidden_key into the Key etc.  
> 
> Now, a potential attacker could easily send zillions of 
> Binding Warnings, using different CoA:s and Home Addresses,
> leading to a DoS similar to TCP SYN flooding.
> 
> Other attacks will follow as soon as I figure out how to do them :-)
>
Even IKE stores state before responding to the first packet from
the initiator. Only Photuris does not have this by negotiating
cookies separately. We can use similar mechanisms to achieve
the same here. I think we need requirements before discussing
a solution.

-mohan


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 19:45:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06784
	for ; Fri, 23 Mar 2001 19:44:59 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17771;
	Fri, 23 Mar 2001 16:42:30 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04850;
	Fri, 23 Mar 2001 16:42:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O0efIm027333
	for ; Fri, 23 Mar 2001 16:40:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O0efxl027331
	for mobile-ip-dist; Fri, 23 Mar 2001 16:40:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O0eWIm027324
	for ; Fri, 23 Mar 2001 16:40:32 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04546
	for ; Fri, 23 Mar 2001 16:40:32 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07067
	for ; Fri, 23 Mar 2001 16:40:30 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2O0eTd19468
	for ; Sat, 24 Mar 2001 01:40:29 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat Mar 24 01:40:29 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Sat, 24 Mar 2001 01:40:28 +0100
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.
	txt
Date: Sat, 24 Mar 2001 01:40:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Another late reply

> >         Your proposal relies on using the GMA's address
> >         which is the same address management as the MAP
> >         in Extended mode.
> > 
> > > >         So what's the justification for the additional cost
> > > >         and overriding the routing protocols ?
> 
> I believe we are not overriding routing protocols any more than you
> are, once we compare with your extended mode.
> 
	=> ??? I don't get that. Multi-level hierarchy forces packets
	into a fixed route between levels. I don't know what you mean ??
	Extended mode != multi-level hierarchy.

> > > Better optimization of last hop bandwidth usage, network-controlled
> > > load balancing (your scheme has hop count and priority in a MAP
> > > option, these trust MN does something it may not be designed to
> > > do and require more than one MAP options to make a choice even
> > > possible).
> > >
> >         => Are you referring to the MAP option ?
> >         I hope this is not the BW argument. This argument is
> >         not valid IMO. RAs are designed to have several
> >         options regardless of the use of MIP. I hope we can agree on that.
> 
> We can still try to reduce the size of the RA, i.e. number of extensions
> needed for a load-balancing network.
> 
	=> Jari, have you read the draft ? What load balancing 
	extensions are you referring to ? The load balancig described
	in the draft is something else. Have a look at rev 2 or 3.

> >         Now regarding the parameters in the MAP option,
> >         I don't see what the MN would have difficulty with.
> >         If the MN supports HMIPv6 then it MUST understand
> >         the option. If it does something wrong, like choosing
> >         a MAP with a 255 preference (indicating that it should
> >         not be used), the MAP will simply reject the BU.
> >         What's the problem with that ?
> 
> You rely on the MN to behave correctly. Also, you do not specify
> the load balancing, you need external box to do that. 
> 
	=> See above

	regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 19:57:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06888
	for ; Fri, 23 Mar 2001 19:57:17 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20870;
	Fri, 23 Mar 2001 16:55:26 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12368;
	Fri, 23 Mar 2001 16:55:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O0roIm027370
	for ; Fri, 23 Mar 2001 16:53:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O0rocl027369
	for mobile-ip-dist; Fri, 23 Mar 2001 16:53:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O0rfIm027362
	for ; Fri, 23 Mar 2001 16:53:41 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06912
	for ; Fri, 23 Mar 2001 16:53:41 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07404
	for ; Fri, 23 Mar 2001 16:53:41 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA22528
	for ; Fri, 23 Mar 2001 16:53:40 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O0rbJ08048
	for ; Fri, 23 Mar 2001 16:53:37 -0800
X-mProtect:  Fri, 23 Mar 2001 16:53:37 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin12.iprg.nokia.com (205.226.20.242, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdVr0qXH; Fri, 23 Mar 2001 16:42:23 PST
Message-ID: <3ABBEDB1.EF2AAA75@iprg.nokia.com>
Date: Fri, 23 Mar 2001 16:43:29 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <200103232206.f2NM6wP25186@locked.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Mohan,

>          I think we need requirements before discussing
> a solution.

I think the requirements can be stated as,
"First, do no harm".  Translated into Internet
terms, this means that our solution should not
introduce any vulnerability beyond what would
be experienced by a stationary node on its
IPv4 network.  This is an approximation, of
course, to be adjusted according to whatever
understanding we might develop.

There are two major problems identified by the
recent security discussants that are preventing
Mobile IPv6 from becoming Proposed Standard.
First is to eliminate reliance on AH, since the common
deployment model(s) for AH is not precisely
compatible with the usage envisioned with the
Binding Update.  There are various small problems,
which are all solvable by adding more security
related fields to the Binding Update, and then
just not using AH (or ESP) for doing the authentication.
But this isn't the biggest source of our pain.

The other major problem has to do with key
establishment between the mobile node and the
correspondent node.  The dictum to "do no harm"
that we should try to get a key between the nodes
without creating vulnerabilities to any attackers,
except _perhaps_ those that might be posed by a
malicious node between the correspondent
node and the home network.  This is a solvable
problem.

Placing ever more subtle requirements on the
problem may be satisfying for the perceptive
individuals who can thus demonstrate the depth
of their understanding, but it isn't doing to help us
get to Proposed Standard.

Is my statement of requirements sharp enough?
If not, can you suggest an improvement?

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 20:35:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07278
	for ; Fri, 23 Mar 2001 20:35:49 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01798;
	Fri, 23 Mar 2001 17:34:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15376;
	Fri, 23 Mar 2001 17:34:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1WqIm027433
	for ; Fri, 23 Mar 2001 17:32:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O1WqJX027432
	for mobile-ip-dist; Fri, 23 Mar 2001 17:32:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1WhIm027425
	for ; Fri, 23 Mar 2001 17:32:43 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15860
	for ; Fri, 23 Mar 2001 17:32:43 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18710
	for ; Fri, 23 Mar 2001 17:32:43 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA25692
	for ; Fri, 23 Mar 2001 17:32:43 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O1Wf621911
	for ; Fri, 23 Mar 2001 17:32:41 -0800
X-mProtect:  Fri, 23 Mar 2001 17:32:41 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdg7S3GA; Fri, 23 Mar 2001 17:32:36 PST
Message-ID: <3ABBF935.8638F9FB@iprg.nokia.com>
Date: Fri, 23 Mar 2001 17:32:37 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <3AB8FA22.D232E181@iprg.nokia.com> <3AB9019B.397D1EB7@nomadiclab.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

So, have you figured out how to do them?

vijay

Pekka Nikander wrote:
> 
> Charlie Perkins wrote:
> >
> > Here's what I wrote up last night after our
> > meeting in Salon A.
> 
> As an immediate response, there seems to be a potential new
> DoS attack that may need addressing.  That is, when the CN
> receives a Binding Warning, it creates a cookie, and basically
> stores either a  or a  pair
> to wait for the Binding Update that it expects to receive from
> the MN.  It must store this pair since otherwise it couldn't
> turn the Hidden_key into the Key etc.
> 
> Now, a potential attacker could easily send zillions of
> Binding Warnings, using different CoA:s and Home Addresses,
> leading to a DoS similar to TCP SYN flooding.
> 
> Other attacks will follow as soon as I figure out how to do them :-)
> 
> --Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 20:57:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07529
	for ; Fri, 23 Mar 2001 20:57:25 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02392;
	Fri, 23 Mar 2001 17:55:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21709;
	Fri, 23 Mar 2001 17:55:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1s8Im027476
	for ; Fri, 23 Mar 2001 17:54:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O1s77Z027475
	for mobile-ip-dist; Fri, 23 Mar 2001 17:54:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1rxIm027468
	for ; Fri, 23 Mar 2001 17:53:59 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2O1qjV25296
	for mobile-ip@sunroof.eng.sun.com; Fri, 23 Mar 2001 17:52:45 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103240152.f2O1qjV25296@locked.eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
In-Reply-To: <3ABBEDB1.EF2AAA75@iprg.nokia.com> from Charlie Perkins at "Mar
 23, 2001 04:43:29 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 23 Mar 2001 17:52:44 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Hello Mohan,
> 
> >          I think we need requirements before discussing
> > a solution.
> 
> I think the requirements can be stated as,
> "First, do no harm".  Translated into Internet
> terms, this means that our solution should not
> introduce any vulnerability beyond what would
> be experienced by a stationary node on its
> IPv4 network.  This is an approximation, of
> course, to be adjusted according to whatever
> understanding we might develop.
> 
> There are two major problems identified by the
> recent security discussants that are preventing
> Mobile IPv6 from becoming Proposed Standard.
> First is to eliminate reliance on AH, since the common
> deployment model(s) for AH is not precisely
> compatible with the usage envisioned with the
> Binding Update.  There are various small problems,
> which are all solvable by adding more security
> related fields to the Binding Update, and then
> just not using AH (or ESP) for doing the authentication.
> But this isn't the biggest source of our pain.
> 
> The other major problem has to do with key
> establishment between the mobile node and the
> correspondent node.  The dictum to "do no harm"
> that we should try to get a key between the nodes
> without creating vulnerabilities to any attackers,
> except _perhaps_ those that might be posed by a
> malicious node between the correspondent
> node and the home network.  This is a solvable
> problem.
>
Key management itself does not have any major issues (all
of them are minor) as it is possible to achieve
what we want if the MN is communicating with HA.
Two main problems are :

1) Authorization problem.
2) IPsec AH does not seem to scale as we need to maintain one IPsec
   SA per MN on the CN.

If we are not going to solve (1) and we don't like (2), we need
a new mechanism all we need is to establish a shared secret and authenticate.
All the mechanisms are in IKE for doing this. The
shortcomings discussed before are not valid anymore. Once the secret
is established, as MN moves, all we need is a token to send a new
binding update. We can construct the token in such a way that replay
attacks etc. can be avoided. Wouldn't this move it to proposed
standard faster than any other solution ? If there is a possibility
to avoid some attacks, then we should seek that approach. Otherwise,
there will be too many opinions and we will spend a lot of time
discussing about it in the mailing list.

-mohan

> Placing ever more subtle requirements on the
> problem may be satisfying for the perceptive
> individuals who can thus demonstrate the depth
> of their understanding, but it isn't doing to help us
> get to Proposed Standard.
> 
> Is my statement of requirements sharp enough?
> If not, can you suggest an improvement?
> 
> Regards,
> Charlie P.
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 21:01:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07632
	for ; Fri, 23 Mar 2001 21:01:00 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10491;
	Fri, 23 Mar 2001 17:57:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21735;
	Fri, 23 Mar 2001 17:57:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1uLIm027486
	for ; Fri, 23 Mar 2001 17:56:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O1uLNP027485
	for mobile-ip-dist; Fri, 23 Mar 2001 17:56:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O1uBIm027478
	for ; Fri, 23 Mar 2001 17:56:11 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03290
	for ; Fri, 23 Mar 2001 17:56:10 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25001
	for ; Fri, 23 Mar 2001 17:56:06 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA26540
	for ; Fri, 23 Mar 2001 17:56:05 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O1u2326543
	for ; Fri, 23 Mar 2001 17:56:02 -0800
X-mProtect:  Fri, 23 Mar 2001 17:56:02 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdwYiJvc; Fri, 23 Mar 2001 17:55:45 PST
Message-ID: <3ABBFEA4.4790951E@iprg.nokia.com>
Date: Fri, 23 Mar 2001 17:55:48 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <3AB8FA22.D232E181@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Why not just store the key in the Binding Update List 
entry maintained by the MN and in the Binding Cache Entry
maintained by the CN. This way you can have MIPv6 running
on a node completely independent of IKE/SPD/IPsec?

Vijay


Charlie Perkins wrote:
> 
> Hello folks,
> 
> Here's what I wrote up last night after our
> meeting in Salon A.
> 
> Regards,
> Charlie P.
> 
>   ------------------------------------------------------------------------
> Binding Key Establishment for Mobile IPv6
> 
> Abstract
> 
> A method is proposed for providing key information for use
> between a mobile node and correspondent node, to be used
> for the purpose of authenticating Mobile IPv6 Binding Updates.
> The key districution is secure except against man-in-the-middle
> attacks, when the attacker resides in the routing path between
> the correspondent node and the mobile node's home agent.
> The key can be used for authenticating subsequent Binding Updates
> from the same mobile node, substantially reducing the number
> of key establishment cycles needed for maintaining efficient
> communication paths between the mobile node and correspondent
> node.
> 
> Introduction
> 
> Mobile IPv6 specifies the use of a Binding Update destination
> option for use between a correspondent node and a mobile node.
> This Binding Update associates a "care-of address" to the mobile
> node's "home address" enabling direct routing of packets to
> the current point of attachment in use by the mobile node.
> Unfortunately, there may be many instances where no pre-existing
> security association is available for use by the correspondent
> node to authenticate a Binding Update from the mobile node.
> 
> In order to solve this problem, we propose a method by which
> a correspondent node supplies some random data for use by the
> mobile node as input to an algorithm for creating a security
> association.  This security association, once established
> between the mobile node and the correspondent node, is then
> used to create the authentication data that is required to be
> supplied as one of the security fields of the Binding Update
> destination option.
> 
> Without introducing reliance upon use of certifiable public
> keys, it is quite difficult to avoid all attacks against the
> correspondent node that might allow some malicious third part
> to masquerade as the mobile node.  However, we can at least
> make sure that any such malicious node would have to reside
> on the routing path between the correspondent node and the
> home agent.  This substantially reduces to the vulnerability
> to such attacks, since the specific routing path required
> amounts to an extremely small proportion of the Internet.
> 
> In this protocol specification, several new messages are
> introduced:
> - Binding Warning, which is sent by a mobile node to a
>   correspondent node as an indication that a new care-of
>   address should be obtained for the one of the mobile node's
>   addresses.
> - Binding Request, which is sent by a correspondent node
>   to the address of the mobile node in order to elicit
>   a Binding Update.
> 
> In addition, the following extension is specified for
> use in messages to the correspondent node.
> - Binding Authentication Key Establishment Extension, which
>   supplies a key to be used by the correspondent node when
>   verifying authentication data supplied by the mobile node
>   to ensure the integrity of the Binding Update data.
> 
> Subsequent sections provide an overview of the operation of
> the key establishment mechanism, the format of the protocol
> messages, and detailed specification for the message formats.
> Although a specific authentication algorithm is proposed,
> it should be noted that other authentication algorithms
> may be proposed in the future.  However, for interoperability,
> all correspondent nodes SHOULD implement the algorithm
> specified in this document.
> 
> NOTE: I don't care what the algorithm is, so if the one
>       in this document isn't right, I don't mind taking
>       someone's suggestion about using another one.
> 
> ============================ Terminology ============================
> 
> RFC 2119
> 
> Cookie
> 
> Key
> 
> Binding Key
> 
> Security Association
> 
> ============================ Overview ============================
> 
> A mobile node MUST have any security association with a correspondent
> node before it can securely supply a Binding Update to that correspondent.
> If no security association exists for that purpose, the mobile node
> SHOULD send a Binding Warning to the correspondent node, asking it to
> start the process of establishing the needed security association
> with the indicated address of the mobile node.
> 
> When a correspondent node receives a Binding Warning message,
> it selects an appropriate 64-bit random number and inserts it
> into the Cookie field of the Binding Request message.  It then
> sends the Binding Request to the home address of the mobile node.
> The Binding Request message MUST NOT contain any routing header
> entries with any current or previous care-of addresses used to
> send packets to the indicated address of the mobile node.
> 
> Similarly, if a correspondent node determines for any reason
> to establish a Binding Key with the mobild node, it may send
> a Binding Request with a newly selected cookie to the mobile
> node, even if the mobile node has not issued the Binding
> Warning message to the correspondent node.
> 
> When the home agent gets the Binding Request, it MUST tunnel
> the packet to the mobile node.  The tunneled packet SHOULD
> include an IPSec ESP header to assure privacy for the
> Cookie data supplied by the correspondent node.
> 
> When the mobile node gets the tunneled Binding Request, it
> first decapsulates the packet.  Before the mobile node processes
> the Binding Request, it SHOULD ensure that the message was
> tunneled from its home agent.
> 
> If the Binding Request suboption contains the Cookie suboption,
> the mobile node creates a key according to the following
> algorithm:
>         Key := HMAC_MD5 (Cookie || CN IPv6 Address || Cookie)
> where "CN IPv6 Address" is the IPv6 address of the correspondent
> node sending the Binding Request, available as the Source IP
> address from the encapsulated IPv6 header.  The mobile node MUST
> create a new security association for the correspondent node,
> associate the key with the new security association,
> and insert this new security association into its security policy database
> with the appropriate indications to enable future use when creating
> the Authentication Data for the Binding Update destination option.
> 
> The mobile node then uses the key to create the Authentication
> Data for the requested Binding Update destination option.  The default
> algorithm for creation of the authentication data is as follows:
>         Auth_data  :=  HMAC_MD5 (Key  ||  Previous Fields  || Key)
> The mobile node then obscures the key according to the following algorithm:
>         Hidden_Key  :=  Key XOR Cookie
> 
> Finally, the mobile node creates a Binding Key Establishment
> suboption for the Binding Update message, and inserts the
> Hidden Key into the appropriate field of the suboption.
> 
> When the correspondent node receives the Binding Update, it
> first checks to see if there is a Binding Key Establishment
> suboption.  If so, then it retrieves the hidden key according
> the following algorithm:
>         Key  :=  Hidden_Key XOR Cookie
> The correspondent node then checks the validity of the
> Authentication Data by performing the same calculation
> with the newly established Key, as was performed by the
> mobile node when creating the key data.
> 
> ===================== Packet Formats ==========================
> 
> =================== Security Considerations ==========================
> 
> If the home agent does not encrypt the Binding Request packet
> when tunneling it to the mobile node (as in section~\xref{over},
> the key establishment will be vulnerable to any malicious node
> present along the routing path from the home agent to the
> mobile node.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 21:14:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07794
	for ; Fri, 23 Mar 2001 21:14:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05438;
	Fri, 23 Mar 2001 18:12:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03855;
	Fri, 23 Mar 2001 18:12:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O2AdIm027562
	for ; Fri, 23 Mar 2001 18:10:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O2AdsG027561
	for mobile-ip-dist; Fri, 23 Mar 2001 18:10:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O2ADIm027554
	for ; Fri, 23 Mar 2001 18:10:14 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03449
	for ; Fri, 23 Mar 2001 18:10:13 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21024
	for ; Fri, 23 Mar 2001 19:10:11 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA27549
	for ; Fri, 23 Mar 2001 18:10:10 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O2A8122818
	for ; Fri, 23 Mar 2001 18:10:08 -0800
X-mProtect:  Fri, 23 Mar 2001 18:10:08 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.139.225, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdlzOcCH; Fri, 23 Mar 2001 18:09:56 PST
Message-ID: <3ABC01CB.536B2C00@iprg.nokia.com>
Date: Fri, 23 Mar 2001 18:09:15 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <200103240152.f2O1qjV25296@locked.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Mohan,

just one comment with one of the statements you made..

Mohan Parthasarathy wrote:

> 2) IPsec AH does not seem to scale as we need to maintain one IPsec
>    SA per MN on the CN.

I dont understand what you mean by it doesnt scale. if a million
nodes are connected to a CN, it has to maintain a million binding 
cache entries. it has to maintain a million bits of other info
(could be anything) for each MN.

vijay

> 
> If we are not going to solve (1) and we don't like (2), we need
> a new mechanism all we need is to establish a shared secret and authenticate.
> All the mechanisms are in IKE for doing this. The
> shortcomings discussed before are not valid anymore. Once the secret
> is established, as MN moves, all we need is a token to send a new
> binding update. We can construct the token in such a way that replay
> attacks etc. can be avoided. Wouldn't this move it to proposed
> standard faster than any other solution ? If there is a possibility
> to avoid some attacks, then we should seek that approach. Otherwise,
> there will be too many opinions and we will spend a lot of time
> discussing about it in the mailing list.
> 
> -mohan
> 
> > Placing ever more subtle requirements on the
> > problem may be satisfying for the perceptive
> > individuals who can thus demonstrate the depth
> > of their understanding, but it isn't doing to help us
> > get to Proposed Standard.
> >
> > Is my statement of requirements sharp enough?
> > If not, can you suggest an improvement?
> >
> > Regards,
> > Charlie P.
> >
> >


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 23 22:09:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09466
	for ; Fri, 23 Mar 2001 22:09:38 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12832;
	Fri, 23 Mar 2001 19:08:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18037;
	Fri, 23 Mar 2001 19:08:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O35kIm027626
	for ; Fri, 23 Mar 2001 19:05:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2O35kdf027625
	for mobile-ip-dist; Fri, 23 Mar 2001 19:05:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2O35AIm027618
	for ; Fri, 23 Mar 2001 19:05:10 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15514
	for ; Fri, 23 Mar 2001 19:05:10 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02892
	for ; Fri, 23 Mar 2001 19:05:09 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA29673;
	Fri, 23 Mar 2001 19:04:55 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2O34ra26997;
	Fri, 23 Mar 2001 19:04:53 -0800
X-mProtect:  Fri, 23 Mar 2001 19:04:53 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdZi5K5s; Fri, 23 Mar 2001 19:04:46 PST
Message-ID: <3ABC0ECD.2787DA19@iprg.nokia.com>
Date: Fri, 23 Mar 2001 19:04:46 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: micke@CS.Arizona.EDU
CC: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@cdma-2000.org
Subject: [mobile-ip] Re: [seamoby] Header compression context extablishment
References: <200103221925.f2MJPhM00633@baskerville.CS.Arizona.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Mikael,

thanks for your e-mail. The text proposed in the CT problem statement draft,
which I contributed to, may not be complete. I think it was considered
adequate for -00.txt version of the draft. We could always use help from rohc
experts like yourself to improve upon.

Having said this, I don't agree with your overall characterization of the text
that it is not completely accurate. It perhaps needs to be elaborated for
U-mode and O-mode.  Even for these modes, I have questions for you to explain
why my text does not sufficiently capture the motivation needed for a CT
problem statement, which was its purpose to begin with!

I think it is pretty accurate for R-mode.

Regards,

-Rajeev

ps. there is a summary at the end of this e-mail :-)


micke@CS.Arizona.EDU wrote:

> To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, rohc@cdt.luth.se
>
> Re: Header compression state establishment
> ==========================================
>
> Folks,
>
> It has come to my attention that some more or less
> informed statements have been made regarding header
> compression and how efficient/inefficient (re)establishment
> of header compression state might be.
>
> In particular, the statements made in
>
> draft-ietf-seamoby-context-transfer-problem-stat-00.txt
>
> are not completely accurate. This is an attempt to clarify the
> situation for the header compression methodology developed in the
> ROHC WG.
>

Reading your description below, it appears to me that the proposed text is
accurate for the R-mode, with the exception that the FO packet size would be 4
bytes. So, instead of characterizing the text as "not completely accurate", I
hope you would agree if it instead said "it is applicable to R-mode" (using
rohc terms). I appreciate your input so that we could cover all rohc cases
when we take up detailed work.


>
> The typical startup scenario for the ROHC header compression
> schemes for telephony streams is as follows:
>
> 1) send a small number of IR packets with a header size roughly similar
> to the header size of uncompressed headers. I expect that most
> implementations will send roughly 3 IR packets.

If I have voice packets to send at 20 ms intervals, and the link latency is 60
ms one-way, how is it that 3 IR packets are sufficient before I can receive an
Ack ?
Assuming that one of the 3 IR packets establishes "Static Context" at the
decompressor, that would take 3 IR packets worth of time. In order for the Ack
to reach the compressor, that would be another 3 IR packets worth of time. So
the total number of packets is 6 when link RTT is 120 ms, and 10 when link RTT
is 200 ms.  Isn't this correct ?

>
> If operating in U-mode or O-mode, this completes the context
> initialization, and minimal packets will be sent henceforth.
> U-mode can do an exponential backoff when sending IR packets,
> but the typical transition to O-mode or R-mode will prevent
> those IR packets from being sent.
>

What do you mean by saying that after sending 3 IR packets, context
initialization is completed ? Do you mean that the decompressor can transition
from

     No Context -> Static Context -> Full Context

in 3 IR packets ?

For U-mode, this is what the rohc draft says:

5.3.1.1.1
"The compressor normally obtains its confidence about decompressor
   status by sending several packets with the same information according
   to the lower compression state. If the decompressor receives any of
   these packets, it will be in sync with the compressor. The number of
   consecutive packets to send for confidence is not defined in this
   document."

I assume that you think sending 3 IR packets is sufficient for the compressor
to gain confidence to transition all the way to SO state. I cannot comment on
this in U-mode, however, I do have some input for the O-mode later.

Simply for everyone's convenience, I include the paragraph from the rohc draft
for U-mode, in which feedback channel from the decompressor to compressor is
not available.

5.3.1.1.2
"When the optimistic approach is taken as described above, there will
   always be a possibility of failure since the decompressor may not
   have received sufficient information for correct decompression.
   Therefore, the compressor MUST periodically transit to lower
   compression states. Periodic transition to the IR state SHOULD be
   carried out less often than transition to the FO state. Two different
   timeouts SHOULD therefore be used for these transitions. For an
   example of how to implement periodic refreshes, see [IPHC] chapters
   3.3.1-3.3.2."

Reading the above, it appears to me that in the U-mode, the compressor ends up
(re)initializing the context several times according to the period chosen. I
suppose it is ok to say that this does not favor better compression
efficiency, e.g., in cellular links.

Now to the O-mode. You mention that 3 IR packets are sufficient for the
compressor to ascertain that the decompressor has transitioned from "No
Context" to "Static Context" to "Full Context". When I read Section 5.4.2.2
(Feedback Logic (O-mode)), I observed that when the decompressor receives an
IR packet, it always sends an ACK.

"State Actions

   NC:  - When an IR packet passes the CRC check, send an ACK(O).
   ...

 SC:  - When an IR packet is correctly decompressed, send an ACK(O).
 ....

 FC:  - When an IR packet is correctly decompressed, send an ACK(O)."


What would be the purpose of sending this ACK for IR packets ? Perhaps to help
the compressor positively determine that the decompressor has received and
processed the IR packet ? If that is the case, then the compressor has to
obtain the ACK before transitioning to better state. Going with 120 ms RTT, in
order for this ACK to come back, it would take _6_ packets (IR). Isn't this
right ?
Also, I don't know if the ACK gives sufficient confidence for the compressor
to jump from IR state directly to SO state without going through the FO
state..


>
> If operation in R-mode is desired, the minimal packets will be
> sent until an acknowledgment (containing a mode transition request)
> reaches the compressor. Then,
>
> 2) during an additional roundtrip, non-minimal headers are sent during
> transition to R-mode.
>

The R-mode works in lockstep with ACKs. So, the text in the CT problem
statement is right.

>
> Some parameters are as follows:
>
> link roundtrip for cellular: 120-200 milliseconds.
> (6-10 packets at 50 packets per second).
>
> Minimal headers are 1 byte.
>
> Header size in 2) is rougly 4 bytes.
>

Thanks for clarifying that size in 2) is 4 bytes. Thanks also for pointing out
the higher link latency (200 ms).


>
> The header sizes indicated above do not include context identifiers,
> which can be omitted completely for context identifier zero.
> Nor do they include the two-byte UDP checksum, which will not be sent at
> all if disabled. Nor do they include the two byte IPv4 Identifier,
> which will be sent as-is if it changes randomly. Reasonable IP stacks
> will have it change in increments of one, and then it will be
> completely removed.
>
> Hope this has helped to clarify the situation with regards to header
> compression and its context (re) initialization.
>

> Mikael Degermark
> Co-chair, ROHC WG

In summary,

1. I think that given the intent of the problem statement for HC context
relocation, the text served the purpose. It may not have been perfect,
however.

2. Context initialization is expensive in unreliable links. Since this has to
be done for _each_ packet stream individually, it gets worse with multiple
packets streams (such as with multimedia streams). It further exacerbates with
frequent handovers.

3. Context relocation, typically performed over high-speed wireline links,
provides a feasible alternative to context re-establishment during handovers.
It provides a mechanism to _seamlessly_ continue _all_ the compression
contexts belonging to the MN, along with performance benefits. I think this is
just right for seamoby to tackle!





From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 25 10:45:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17142
	for ; Sun, 25 Mar 2001 10:45:39 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20047;
	Sun, 25 Mar 2001 07:44:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04838;
	Sun, 25 Mar 2001 07:44:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PFgpIm029382
	for ; Sun, 25 Mar 2001 07:42:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PFgpfO029381
	for mobile-ip-dist; Sun, 25 Mar 2001 07:42:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PFggIm029374
	for ; Sun, 25 Mar 2001 07:42:42 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04754
	for ; Sun, 25 Mar 2001 07:42:42 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13294
	for ; Sun, 25 Mar 2001 07:42:42 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA00978
	for ; Sun, 25 Mar 2001 07:43:02 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC03569;
	Sun, 25 Mar 2001 07:42:40 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02181; Sun, 25 Mar 2001 07:42:40 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15038.4592.707333.845845@thomasm-u1.cisco.com>
Date: Sun, 25 Mar 2001 07:42:40 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Re: Comments on Regional Registration
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBC8B@esealnt448.al.sw.ericsson.se>
References: <034BEFD03799D411A59F00508BDF7546013DBC8B@esealnt448.al.sw.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


Hesham Soliman  (ERA) writes:
 > 	Hello Charlie,
 > > Do you _really_ not at all understand the need for multiple
 > > levels of hierarchy? 
 > > 
 > 	=> Yes. I'm sorry if this is a trivial question but I
 > 	honestly don't see why it's needed and would 
 > 	appreciate an explanation. 

One quick note that occurred to me at the meeting
on this subject. We are not the protocol police,
so if there is a way protocolwise to do it, people
can do it and that is that. Frankly, I find the
admonitions against multiple levels of hierarchy
somewhat hollow: MIP at least has a basic
connectivity problem; all the rest of the *MIP's
floating around are for optimization and they all
have single point of failure issues. If you're
willing to live with one failure point for
optimization -- which you've assumedly made
backhoe-proof somehow -- I don't know why you
can't make an induction on all the rest. If you
find that unsettling, well... I can't help you
there.

		 Mike
 


From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 25 10:50:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17514
	for ; Sun, 25 Mar 2001 10:50:34 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20593;
	Sun, 25 Mar 2001 07:48:53 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05053;
	Sun, 25 Mar 2001 07:48:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PFljIm029420
	for ; Sun, 25 Mar 2001 07:47:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PFliOd029419
	for mobile-ip-dist; Sun, 25 Mar 2001 07:47:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PFlZIm029412
	for ; Sun, 25 Mar 2001 07:47:35 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05652
	for ; Sun, 25 Mar 2001 07:47:36 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15304
	for ; Sun, 25 Mar 2001 07:47:35 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13973
	for ; Sun, 25 Mar 2001 07:47:39 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC03577;
	Sun, 25 Mar 2001 07:47:33 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02184; Sun, 25 Mar 2001 07:47:33 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15038.4884.923206.617754@thomasm-u1.cisco.com>
Date: Sun, 25 Mar 2001 07:47:32 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...)
In-Reply-To: <200103160040.QAA07905@heliopolis.Eng.Sun.COM>
References: <200103160040.QAA07905@heliopolis.Eng.Sun.COM>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > We would like to see elimination of *all* tunnelling overhead over
 > the air (and that includes HA overhead folks) if possible. For example,
 > by stripping it on at the last hop router, where it is no longer 
 > needed.
 > 
 > Barring that, we would like to see an analysis that indicates header
 > compression will work to eliminate tunnelling overhead, and that
 > it can be moved quickly enough during handover that it will not
 > negate the gains of the low latency handover protocol. I do not
 > get the feeling from the Seamoby context transfer problem statement
 > draft that this is possible.

In particular, I think that the case of mobile
routers needs to be considered closely. The
likelihood of the need for many compression
contexts (which I don't _think_ is possible in
CRTP/ROHC, but could be wrong) may be problematic.
   
	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 25 16:04:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12688
	for ; Sun, 25 Mar 2001 16:04:15 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23537;
	Sun, 25 Mar 2001 13:02:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18271;
	Sun, 25 Mar 2001 13:01:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PKwwIm029802
	for ; Sun, 25 Mar 2001 12:58:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PKwv5m029799
	for mobile-ip-dist; Sun, 25 Mar 2001 12:58:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PKwjIm029783
	for ; Sun, 25 Mar 2001 12:58:46 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11434
	for ; Sun, 25 Mar 2001 15:58:35 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA04777
	for mobile-ip@sunroof.eng.sun.com; Sun, 25 Mar 2001 15:58:43 -0500 (EST)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PIj4Im029586
	for ; Sun, 25 Mar 2001 10:45:04 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27795
	for ; Sun, 25 Mar 2001 10:45:04 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28086
	for ; Sun, 25 Mar 2001 10:44:48 -0800 (PST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2PIieg01522
	for ; Sun, 25 Mar 2001 12:44:50 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Sun, 25 Mar 2001 12:44:34 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Sun, 25 Mar 2001 12:44:34 -0600
Message-ID: 
To: micke@cs.arizona.edu, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        seamoby@cdma-2000.org
Subject: [mobile-ip] RE: [rohc] Compression startup behavior
Date: Sun, 25 Mar 2001 12:44:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Mikael,

thanks for the clarification. I have more questions below.

I get the feeling that if my text portrayed the compression initialization
behavior to be worse than the actual, your input seems to be inclining
towards the opposite! 

Regards,

-Rajeev

> 
> 
> To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, 
> rohc@cdt.luth.se
> 
> Hi Rajeev, 
> 
> You are right that the text is a reasonable first approximation, 
> but as it portrayed the situation to be somewhat worse than it
> really is, I felt that it was prudent to help make it more accurate.
> 
> The reality of ROHC context establishment, according to the ROHC
> spec, is as follows:
> 
> 1) All new contexts MUST start out in U-mode. Thus, it is the U-mode
>    rules that govern compressor behavior until feedback reaches the
>    compressor. The ROHC spec says that the U-mode startup behavior
>    is to send a small number of IR packets, followed by periodic
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, the rohc draft mentions "several packets". 

Section 5.3.1.1.1
"The compressor normally obtains its confidence about decompressor
   status by sending several packets with the same information according
   to the lower compression state. If the decompressor receives any of
   these packets, it will be in sync with the compressor. The number of
   consecutive packets to send for confidence is not defined in this
   document. "

The basic problem is: how does the compressor know that the decompressor has
the Full Context ? If the answer is it need not, then you take a chance
after sending "pre-defined" number of packets, and roll-back with costly
operations when the decompressor does not have the Full Context (in the
U-mode you simply repeat the IR packets). If the answer requires that it has
to, then you wait for an ACK. 

>    repetition of IR packets. The period should be rather long. 
>    The compressor MAY use an exponential backoff until the 
>    periodic interval is reached. 
> 
>    The small number I picked, three, will be different for different
>    implementations but is not completely unrealistic. 
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In other words, 3 is the best case with rather low probability of being
feasible in practice  ? You say here clearly that the initial number of IR
packets is implementation-dependent. Is there any consensus in rohc that
sending 3 IR packets is sufficient, especially in those links with high
error probabilities ? If yes, could you point me to any relevant document ? 


>It has nothing to do with whether an ack is received or not. This is
U-mode.
> 
> 2) Swithcing to R-mode or O-mode cannot happen until feedback 
>    indicating that a mode switch is desired is received from the 
>    decompressor. Thus, it can happen at the earliest after a
>    roundtrip time, and so can happen after 6-10 packets with a 
>    roundtrip of 120-200 milliseconds.
> 

An observation I have with your text here is that you don't mention when the
compressor transitions to FO/SO state after starting out in IR state in
U-mode. Could you please clarify ?


> 3) The decompressor will move to full-context state as soon as it
>    receives any IR packet with complete information. 
>    The default values for slopes, etc, have been picked such that
>    telephony streams only need one such packet before minimal 
> headers can 
>    be decompressed correctly. 

Could you explain to me how you can establish a slope with one packet ?


>If the actual values deviate 
> from what is
>    expected for telephony, two IR packets need to be received 
>    before minimal headers can be decompressed correctly. 
> 

Again, the problem is how does the compressor know that decompressor has the
required state ? In the rohc draft, the same is stated as "the compressor
must have sufficient confidence" or something alike.. I guess two approaches
discussed in rohc draft are

1. send several packets, transition to higher compression state, and repeat
IR packets (U-mode), or revert back to lower compression state when
compressor determines (through a NACK e.g.) that decompressor does not have
the required state (O-mode). 

2. compressor uses an ACK to gain the required confidence (R-mode). 

In both cases above, it appears that in order for the compressor to gain the
required confidence, several packets are needed, especially in a link with
higher error probabilities.
 

> 4) It *is* possible for the compressor to go to SO state after
>    sending only IR packets. Transition to SO state is governed by 
>    whether a pattern has been established, and also IR packets can
>    establish patterns as they can contain the dynamic part of the
>    header. 
>

Exactly the same point again: How does the compressor know that the IR
packets it transmitted definitively or almost certainly established the Full
Context at the decompressor ? 

I guess it is possible. I can also imagine when it is also *not* possible,
especially when you are operating under high error links such as those found
in cellular. 

 
> OK?
> 

Well somewhat.. I still have unanswered points above. Also, could you answer
the questions I had in my previous e-mail as well ?
 
> I think that the problems with the text was that it assumed that
> the compressor started out in R-mode, and that IR packets could not
> establish a pattern. Under those conditions, the text is correct.
> Those are not the actual conditions, however.
> 

Thanks for the clarification regarding every mode starting out in U-mode. 
Could you care to explain _what_ are the actual conditions (other than every
rohc implementation starting out in U-mode) ?

Do you agree with items 2 and 3 in my summary in the previous e-mail ? Here
they are again!

2. Context initialization is expensive in unreliable links. Since this has
to
be done for _each_ packet stream individually, it gets worse with multiple
packets streams (such as with multimedia streams). It further exacerbates
with
frequent handovers.

3. Context relocation, typically performed over high-speed wireline links,
provides a feasible alternative to context re-establishment during
handovers.
It provides a mechanism to _seamlessly_ continue _all_ the compression
contexts belonging to the MN, along with performance benefits. I think this
is
just right for seamoby to tackle!


> Cheers, 
> 
> Micke
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 


From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 25 18:31:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24244
	for ; Sun, 25 Mar 2001 18:31:24 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20609;
	Sun, 25 Mar 2001 15:30:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11419;
	Sun, 25 Mar 2001 15:30:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PNT9Im000072
	for ; Sun, 25 Mar 2001 15:29:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PNT8jo000071
	for mobile-ip-dist; Sun, 25 Mar 2001 15:29:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PNSxIm000064
	for ; Sun, 25 Mar 2001 15:29:00 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11259
	for ; Sun, 25 Mar 2001 15:29:00 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06767
	for ; Sun, 25 Mar 2001 16:28:59 -0700 (MST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2PNSvd18454
	for ; Mon, 26 Mar 2001 01:28:57 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Mar 26 01:28:57 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 26 Mar 2001 01:24:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCB9@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Re: Comments on Regional Registration
Date: Mon, 26 Mar 2001 01:28:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	Mike, 

>  > > Do you _really_ not at all understand the need for multiple
>  > > levels of hierarchy? 
>  > > 
>  > 	=> Yes. I'm sorry if this is a trivial question but I
>  > 	honestly don't see why it's needed and would 
>  > 	appreciate an explanation. 
> 
> One quick note that occurred to me at the meeting
> on this subject. We are not the protocol police,
> so if there is a way protocolwise to do it, people
> can do it and that is that. 
> 
	=> Yes, but there is a way to stop it. You 
	can easily configure a MAP to not receive a BU
	that requests traffic to be forwarded to "certain"
	MAPs. But the best way to stop it is to design
	your network in such a way. That is also very 
	easy, just put overlapping MAP domains if you 
	need more than one. 

	I agree that people will use it if they see the need, 
	but what's that need ?

> Frankly, I find the
> admonitions against multiple levels of hierarchy
> somewhat hollow: MIP at least has a basic
> connectivity problem; all the rest of the *MIP's
> floating around are for optimization and they all
> have single point of failure issues. If you're
> willing to live with one failure point for
> optimization -- which you've assumedly made
> backhoe-proof somehow -- 
> 
	=> If you want one node to be redundant 
	that will cost you X $$, if you want 
	3 nodes to be redudant it will probably cost you  
	3 X, so you can do it of course but what would 
	you do that for ? There are no less states 
	kept in the top MAP anyway, so what's the 
	point ?

	Even the IPv4 RR kept that solution (multi-level)
	in the appendix and it is not part of the main
	draft. They limited it to 2 levels because in V4 
	you have an FA, in V6 you don't so one level 
	is enough.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Sun Mar 25 18:34:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24513
	for ; Sun, 25 Mar 2001 18:34:12 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20978;
	Sun, 25 Mar 2001 15:32:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24830;
	Sun, 25 Mar 2001 15:32:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PNV0Im000085
	for ; Sun, 25 Mar 2001 15:31:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2PNUxwh000084
	for mobile-ip-dist; Sun, 25 Mar 2001 15:30:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2PNUnIm000077
	for ; Sun, 25 Mar 2001 15:30:49 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11467
	for ; Sun, 25 Mar 2001 15:30:49 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27893
	for ; Sun, 25 Mar 2001 15:30:48 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2PNUld18623
	for ; Mon, 26 Mar 2001 01:30:47 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Mar 26 01:30:47 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 26 Mar 2001 01:30:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCBA@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Simplified Hierarchical MIPv6 (was...)
Date: Mon, 26 Mar 2001 01:30:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

>  > We would like to see elimination of *all* tunnelling overhead over
>  > the air (and that includes HA overhead folks) if possible. For example,
>  > by stripping it on at the last hop router, where it is no longer 
>  > needed.
>  > 
>  > Barring that, we would like to see an analysis that indicates header
>  > compression will work to eliminate tunnelling overhead, and that
>  > it can be moved quickly enough during handover that it will not
>  > negate the gains of the low latency handover protocol. I do not
>  > get the feeling from the Seamoby context transfer problem statement
>  > draft that this is possible.
> 
> In particular, I think that the case of mobile
> routers needs to be considered closely. The
> likelihood of the need for many compression
> contexts (which I don't _think_ is possible in
> CRTP/ROHC, but could be wrong) may be problematic.
> 
	=> In the MR case there is no need to tunnel
	over the last hop. We've considered it carefully
	already, but we'd still like to know if you see any
	problems in it. 

	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 03:55:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10258
	for ; Mon, 26 Mar 2001 03:55:49 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23588;
	Mon, 26 Mar 2001 00:54:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20376;
	Mon, 26 Mar 2001 00:54:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q8r4Im000607
	for ; Mon, 26 Mar 2001 00:53:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2Q8r3qg000606
	for mobile-ip-dist; Mon, 26 Mar 2001 00:53:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q8qsIm000599
	for ; Mon, 26 Mar 2001 00:52:54 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03639;
	Mon, 26 Mar 2001 00:52:54 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07188;
	Mon, 26 Mar 2001 00:52:52 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2Q8qod32235;
	Mon, 26 Mar 2001 09:52:50 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA04874;
	Mon, 26 Mar 2001 10:51:16 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2Q8pEA70687;
	Mon, 26 Mar 2001 10:51:15 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103260851.f2Q8pEA70687@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Fri, 23 Mar 2001 09:42:11 PST.
             <200103231742.f2NHgCs25013@locked.eng.sun.com> 
Date: Mon, 26 Mar 2001 10:51:14 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   I think this discussion will go on and on and we will eventually  end 
   up re-inventing IKE. Why can't we just do IKE phase I using self
   signed certificates (as suggested by someone...)

=> me... Self signed certificates is in IKE the weakest form of
authentication.

   and use this
   shared secret to generate a token (SHA-1(Home address, care of address,
   sequence number, Secret) - which will be used to tell the correspondent
   node that you have moved. 
   
=> there are many good ideas in IKE (at least for the crypto part).

   I will write up something more formal on this.
   
=> I have thought more about mobile IPv6 security:
 - the home registration must use the best security available,
   ie. strong authentication.
 - section 10.9 (smooth handoff) is a bit special and is easy to do
   if it is prepared before the handoff (after it is a real security mess).
 - with a smart use of nonces the CN should be able to verify both the
   home address and the care-of address (by sending crypto messages to both).
   This makes the security scheme weak only to MITM attacks on both
   CN-HA and CN-MN paths: in general this implies the MITM is closed to
   the CN and is able to use any kinds of attack (including attacks against
   PKIs and/or DNS).
   This idea is the only case where we can find something better than raw IKE.

Regards

Francis.Dupont@enst-bretagne.fr

PS: about home address option: I believe the firewall of the visited network
must be mobility aware: don't think a security manager will authorize
source routing through his domain without notice! So we need a security
of the visited domain too, to leave the home address option in the cleartext
of every packets or fragments (as in ID 13) is a good point but we need more,
for instance a standard way to give mobility parameters (home address and
home agent address) to local AAA...


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 04:22:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16652
	for ; Mon, 26 Mar 2001 04:22:44 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07811;
	Mon, 26 Mar 2001 01:20:52 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22292;
	Mon, 26 Mar 2001 01:20:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q9IqIm000683
	for ; Mon, 26 Mar 2001 01:18:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2Q9Iqw1000682
	for mobile-ip-dist; Mon, 26 Mar 2001 01:18:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2Q9IfIm000675
	for ; Mon, 26 Mar 2001 01:18:41 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00968;
	Mon, 26 Mar 2001 01:18:40 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21120;
	Mon, 26 Mar 2001 01:18:39 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2Q9Ibd37884;
	Mon, 26 Mar 2001 10:18:37 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA05311;
	Mon, 26 Mar 2001 11:17:03 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2Q9H2A70950;
	Mon, 26 Mar 2001 11:17:02 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103260917.f2Q9H2A70950@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill , Michael Thomas 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Fri, 23 Mar 2001 14:06:58 PST.
             <200103232206.f2NM6wP25186@locked.eng.sun.com> 
Date: Mon, 26 Mar 2001 11:17:02 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Even IKE stores state before responding to the first packet from
   the initiator. Only Photuris does not have this by negotiating
   cookies separately.

=> and only Photuris has no DoS problem with cookies (ie. Photuris
is right and IKE wrong about this).

   I think we need requirements before discussing a solution.
   
=> another vote to finish draft-glass-mobileip-security-issues ASAP?

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 07:35:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06931
	for ; Mon, 26 Mar 2001 07:35:21 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24075;
	Mon, 26 Mar 2001 04:32:43 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13597;
	Mon, 26 Mar 2001 04:32:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QCV9Im000833
	for ; Mon, 26 Mar 2001 04:31:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QCV8VR000832
	for mobile-ip-dist; Mon, 26 Mar 2001 04:31:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QCUxIm000825
	for ; Mon, 26 Mar 2001 04:31:00 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18378
	for ; Mon, 26 Mar 2001 04:30:58 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12166
	for ; Mon, 26 Mar 2001 04:30:57 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2QCUud53927
	for ; Mon, 26 Mar 2001 13:30:56 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA10553
	for ; Mon, 26 Mar 2001 14:30:49 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2QCUmA71428
	for ; Mon, 26 Mar 2001 14:30:48 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103261230.f2QCUmA71428@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Fri, 23 Mar 2001 18:09:15 PST.
             <3ABC01CB.536B2C00@iprg.nokia.com> 
Date: Mon, 26 Mar 2001 14:30:48 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Mohan Parthasarathy wrote:
   
   > 2) IPsec AH does not seem to scale as we need to maintain one IPsec
   >    SA per MN on the CN.
   
   I dont understand what you mean by it doesnt scale. if a million
   nodes are connected to a CN, it has to maintain a million binding 
   cache entries. it has to maintain a million bits of other info
   (could be anything) for each MN.
   
=> Vijay, Mohan did say this is his opinion: this is one of the arguments
against the current Mobile IPv6 security...

Regards

Francis.Dupont@enst-bretagne.fr

PS: any deduction about my own opinion from this is likely correct... (:-)



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 11:12:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10684
	for ; Mon, 26 Mar 2001 11:12:49 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10483;
	Mon, 26 Mar 2001 08:11:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13807;
	Mon, 26 Mar 2001 08:11:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QG9GIm001339
	for ; Mon, 26 Mar 2001 08:09:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QG9GqY001338
	for mobile-ip-dist; Mon, 26 Mar 2001 08:09:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QG96Im001328
	for ; Mon, 26 Mar 2001 08:09:06 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13192
	for ; Mon, 26 Mar 2001 08:09:06 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA26087
	for ; Mon, 26 Mar 2001 09:09:05 -0700 (MST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Mon, 26 Mar 2001 18:08:55 +0200
Received: from rd.francetelecom.fr (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id G3RXQCTA; Mon, 26 Mar 2001 16:25:40 +0200
Message-ID: <3ABF50FB.737C92AC@rd.francetelecom.fr>
Date: Mon, 26 Mar 2001 16:23:55 +0200
From: Jean-Michel COMBES 
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Claude Castelluccia 
Subject: Re: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
References: <3AB63A39.49928755@nomadiclab.com> <3AB75389.25077265@inrialpes.fr> <3AB83D9E.B078FAFB@nomadiclab.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id IAA10483
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10684

Hi,

sorry for the delay ...

Pekka Nikander a écrit :

> > The reasons of keeping the Home Address (in cleartext) is:
> > - because IPSec uses it to locate the SA...if you remove the Home Address
> >   option you basically needs to use the CoA and since this CoA changes you
> >   have to reestablished the SA each time you move...
>
> Hmm.  I am unsure about this.  Isn't SAs looked up by the SPI
> and the _destination_ address?  Quoting RFC2401, "A security
> association is uniquely identified by a triple consisting
> of a Security Parameter Index (SPI), an IP Destination Address,
> and a security protocol (AH or ESP) identifier. "  The Home
> Address Destination Option carries the source address, doen't it?

JMC :
yes ... but most of IPsec implementations need to have it (SPD) ...

>
>
> My understanding is that the home address destination option is
> needed _only_ for looking up the right socket, and, as I have
> explained, can be done by other means, too.
>
> > - because some firewalls use it to perform some kind of filtering...
>
> Yes, I know.  But, IMHO, that is _completely_ flawed since the
> the firewalls cannot verify it's validity in any way.

JMC :
I don't think that a firewall have to verify the validity ... but to manage IP
traffic :
so you need Home-Address ...

>
>
> > In the draft  we suggest to generate the TMI as follows:
> > new TMI = MD5 ( Home address | current TMI),
> >
> snip
> >
> > We should probably use something like that:
> >
> > new TMI = MD5 ( Home address | current TMI | random value),
> >
>
> Or maybe you can do even better by calculation a few TMIs beforehand
> and using them then backwards.  But then you'd come directly to a
> solution similar to what I suggest in the forthcoming pbk-addresses
> draft...
>
> --Pekka

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 12:16:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12570
	for ; Mon, 26 Mar 2001 12:16:45 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21276;
	Mon, 26 Mar 2001 09:14:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18803;
	Mon, 26 Mar 2001 09:14:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QHCqIm001539
	for ; Mon, 26 Mar 2001 09:12:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QHCpKi001538
	for mobile-ip-dist; Mon, 26 Mar 2001 09:12:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QHChIm001531
	for ; Mon, 26 Mar 2001 09:12:43 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26986
	for ; Mon, 26 Mar 2001 09:12:42 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA00764
	for ; Mon, 26 Mar 2001 09:12:41 -0800 (PST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Mon, 26 Mar 2001 19:12:30 +0200
Received: from rd.francetelecom.fr (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id G3RXQC41; Mon, 26 Mar 2001 17:01:00 +0200
Message-ID: <3ABF5943.3858302C@rd.francetelecom.fr>
Date: Mon, 26 Mar 2001 16:59:15 +0200
From: Jean-Michel COMBES 
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id JAA21276
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12570

Hi,

sorry for the delay ...

Thomas Narten a écrit :

> This is a note to summarize some security-related concerns that the
> IESG has with the Mobile IP v6 Draft
> (draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
> follows:
>
> The IESG has concerns about the draft's dependency on IPSEC AH to
> authenticate Binding Updates. There are several issues here.
>
>    a) There is significant overhead associated with building and
>       maintaining AH/IPsec SAs (both in terms of state that needs to
>       be maintained, but also in terms of required message flows, and
>       the processing required to implement those flows). This has
>       negative implications for larger servers that process many 100s
>       of thousands of connections at a time.
>
>    b) The processing rules for authenticating a Binding Update with AH
>       are complex and are apparently not readily supported by the
>       current generation of IPsec/IKE implementations

JMC :
I don't agree : I'm used MobileIPv6+IPsec/IKE implementations (INRIA and
Bull) and all BU/BAck are authenticated with AH (using IKE) ...

> (e.g., the IPsec
>       policies are needed that specify sufficient granularity about
>       IPv6 packets containing binding updates).

JMC :
Agree (maximum granurality is Next Header number) . A solution, perhaps,
would be to allow a different Next Header number to BU and BAck
Destinations Options. Is it possible ?

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 12:41:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12953
	for ; Mon, 26 Mar 2001 12:41:31 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04676;
	Mon, 26 Mar 2001 09:40:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02590;
	Mon, 26 Mar 2001 09:39:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QHcIIm001580
	for ; Mon, 26 Mar 2001 09:38:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QHcHHe001579
	for mobile-ip-dist; Mon, 26 Mar 2001 09:38:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QHc9Im001572
	for ; Mon, 26 Mar 2001 09:38:09 -0800 (PST)
Received: from jurassic.eng.sun.com (localhost [::1])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with ESMTP id f2QHc7xe133082
	for ; Mon, 26 Mar 2001 09:38:07 -0800 (PST)
Received: (from mohanp@localhost)
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) id f2QHc5NI133071
	for mobile-ip@sunroof.eng.sun.com; Mon, 26 Mar 2001 09:38:05 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
In-Reply-To: <200103261230.f2QCUmA71428@givry.rennes.enst-bretagne.fr> from Francis
 Dupont at "Mar 26, 2001 02:30:48 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Mon, 26 Mar 2001 09:38:03 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>    Mohan Parthasarathy wrote:
>    
>    > 2) IPsec AH does not seem to scale as we need to maintain one IPsec
>    >    SA per MN on the CN.
>    
>    I dont understand what you mean by it doesnt scale. if a million
>    nodes are connected to a CN, it has to maintain a million binding 
>    cache entries. it has to maintain a million bits of other info
>    (could be anything) for each MN.
>    
> => Vijay, Mohan did say this is his opinion: this is one of the arguments
> against the current Mobile IPv6 security...
>
Sorry for the confusion. I was summarizing the IESG (and others) concerns
about using AH for solving the mobile IPv6 security problem.
I did not mean to use the word "scale". Hence, if we don't want to use AH
and not solve the authorization problem, why can't we just use the IKE
part alone ? If this is also considered heavy weight, all new solutions
should be compared against this. 

-mohan


-mohan
 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: any deduction about my own opinion from this is likely correct... (:-)
> 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:11:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13458
	for ; Mon, 26 Mar 2001 13:11:20 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00791;
	Mon, 26 Mar 2001 10:07:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09424;
	Mon, 26 Mar 2001 10:07:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QI5dIm001673
	for ; Mon, 26 Mar 2001 10:05:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QI5d4P001672
	for mobile-ip-dist; Mon, 26 Mar 2001 10:05:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QI5TIm001665
	for ; Mon, 26 Mar 2001 10:05:29 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09192
	for ; Mon, 26 Mar 2001 10:05:28 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA15758
	for ; Mon, 26 Mar 2001 10:05:28 -0800 (PST)
Message-Id: <200103261805.KAA15758@heliopolis.Eng.Sun.COM>
Date: Mon, 26 Mar 2001 10:05:28 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: nR2/VbnR9zZjIL7GoHrrMA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mohan,


>Sorry for the confusion. I was summarizing the IESG (and others) concerns
>about using AH for solving the mobile IPv6 security problem.
>I did not mean to use the word "scale". Hence, if we don't want to use AH
>and not solve the authorization problem, why can't we just use the IKE
>part alone ? If this is also considered heavy weight, all new solutions
>should be compared against this. 
>

I won't presume to say I can contribute much to the security discussion, but
one concern with IKE is deployment. Some network operators may not
want to deploy IKE. Alternative solutions for key distribution (such
as AAA) may be more desirable.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:17:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13575
	for ; Mon, 26 Mar 2001 13:17:11 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08644;
	Mon, 26 Mar 2001 10:15:53 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03066;
	Mon, 26 Mar 2001 10:15:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIEUIm001764
	for ; Mon, 26 Mar 2001 10:14:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIETG2001763
	for mobile-ip-dist; Mon, 26 Mar 2001 10:14:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIEFIm001756
	for ; Mon, 26 Mar 2001 10:14:15 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28482
	for ; Mon, 26 Mar 2001 10:14:14 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21321
	for ; Mon, 26 Mar 2001 11:14:13 -0700 (MST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id 7211272543; Mon, 26 Mar 2001 21:14:11 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id 9B1BFBA08; Mon, 26 Mar 2001 21:14:10 +0300 (EEST)
Message-ID: <3ABF8825.8E51BE6E@nomadiclab.com>
Date: Mon, 26 Mar 2001 21:19:17 +0300
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: Mohan Parthasarathy 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Mohan,

> Sorry for the confusion. I was summarizing the IESG (and others) concerns
> about using AH for solving the mobile IPv6 security problem.
> I did not mean to use the word "scale". Hence, if we don't want to use AH
> and not solve the authorization problem, why can't we just use the IKE
> part alone ?

If I read correctly the IESG statement (I might be misreading it),
the concern is not about using AH per se but about "[the] significant 
overhead associated with building and maintaining AH/IPsec SAs", 
where "building" basically means running IKE.  I certainly agree 
that building a large number of AH SAs does require a lot of 
messages and a heavy daemon (the IKE deamon).   However, I am not 
so sure about the cost of "maintaining" a large number of SAs,
especially if the traffic flowing over those SAs is so small that
rekeying is not needed.  Thus, if we can establish some "special
purpose" AH SAs using some lighther protocol than IKE, I still think that
it might be a good idea to use AH or even integrity preserving ESP to 
protect the actual BUs.

By the way, if somebody has good numbers about the typical memory
print of an AH or ESP SA, it would be very interesting to see them.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:17:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13596
	for ; Mon, 26 Mar 2001 13:17:37 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24837;
	Mon, 26 Mar 2001 10:15:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02828;
	Mon, 26 Mar 2001 10:14:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIDmIm001754
	for ; Mon, 26 Mar 2001 10:13:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIDlZQ001753
	for mobile-ip-dist; Mon, 26 Mar 2001 10:13:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIDcIm001746
	for ; Mon, 26 Mar 2001 10:13:39 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02504
	for ; Mon, 26 Mar 2001 10:13:38 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02327
	for ; Mon, 26 Mar 2001 10:13:38 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id KAA12499
	for ; Mon, 26 Mar 2001 10:12:20 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC12104;
	Mon, 26 Mar 2001 10:13:35 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02501; Mon, 26 Mar 2001 10:13:35 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.34511.324164.457274@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 10:13:35 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)
In-Reply-To: <200103261805.KAA15758@heliopolis.Eng.Sun.COM>
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Mohan,
 > 
 > 
 > >Sorry for the confusion. I was summarizing the IESG (and others) concerns
 > >about using AH for solving the mobile IPv6 security problem.
 > >I did not mean to use the word "scale". Hence, if we don't want to use AH
 > >and not solve the authorization problem, why can't we just use the IKE
 > >part alone ? If this is also considered heavy weight, all new solutions
 > >should be compared against this. 
 > >
 > 
 > I won't presume to say I can contribute much to the security discussion, but
 > one concern with IKE is deployment. Some network operators may not
 > want to deploy IKE. Alternative solutions for key distribution (such
 > as AAA) may be more desirable.


   Whatever the solution is, it better not rely on
   AAA exclusively. There is no requirement that AAA
   be run uniformly. In fact, a pretty large percentage
   of the devices on the net in the here and now do 
   not use AAA _at all_. The one I'm typing on right 
   now is a fine example.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:28:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13747
	for ; Mon, 26 Mar 2001 13:28:56 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00811;
	Mon, 26 Mar 2001 10:25:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14001;
	Mon, 26 Mar 2001 10:25:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIMjIm001841
	for ; Mon, 26 Mar 2001 10:22:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIMjhP001840
	for mobile-ip-dist; Mon, 26 Mar 2001 10:22:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIMTIm001829
	for ; Mon, 26 Mar 2001 10:22:30 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00393
	for ; Mon, 26 Mar 2001 10:22:29 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA16261
	for ; Mon, 26 Mar 2001 10:22:29 -0800 (PST)
Message-Id: <200103261822.KAA16261@heliopolis.Eng.Sun.COM>
Date: Mon, 26 Mar 2001 10:22:29 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: NX4Mw2OkKLxpD5JOIeYXWA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mike,


> > >Sorry for the confusion. I was summarizing the IESG (and others) concerns
> > >about using AH for solving the mobile IPv6 security problem.
> > >I did not mean to use the word "scale". Hence, if we don't want to use AH
> > >and not solve the authorization problem, why can't we just use the IKE
> > >part alone ? If this is also considered heavy weight, all new solutions
> > >should be compared against this. 
> > >
> > 
> > I won't presume to say I can contribute much to the security discussion, but
> > one concern with IKE is deployment. Some network operators may not
> > want to deploy IKE. Alternative solutions for key distribution (such
> > as AAA) may be more desirable.
>
>
>   Whatever the solution is, it better not rely on
>   AAA exclusively. There is no requirement that AAA
>   be run uniformly. In fact, a pretty large percentage
>   of the devices on the net in the here and now do 
>   not use AAA _at all_. The one I'm typing on right 
>   now is a fine example.
>

I did not say that it should be used exclusively, only that IKE should
not be the only solution due to concerns about widespread
deployment.

With regard to how many devices will use AAA, both
3GPP and 3GPP2 have recently standardized on the IETF AAA architecture
for their all IP core networks. 3GPP2 is in the process of deploying
AAA for mobile IPv4 in their current IOS v4.x with Radius as the protocol,
and in Version C, to be standardized this summer, they intend to
employ Diameter. I believe it is a fair assessment to say that AAA will likely
be widely deployed in telephony networks in the future. 

Perhaps you have some information about similar deployment plans for IKE
that motivated your statement? If so, perhaps you could share it?

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:30:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13794
	for ; Mon, 26 Mar 2001 13:30:56 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20603;
	Mon, 26 Mar 2001 10:29:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05887;
	Mon, 26 Mar 2001 10:29:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QISbIm001892
	for ; Mon, 26 Mar 2001 10:28:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QISb2o001891
	for mobile-ip-dist; Mon, 26 Mar 2001 10:28:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QISSIm001884
	for ; Mon, 26 Mar 2001 10:28:28 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14939
	for ; Mon, 26 Mar 2001 10:28:27 -0800 (PST)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09439
	for ; Mon, 26 Mar 2001 10:28:26 -0800 (PST)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP id CDCC572543
	for ; Mon, 26 Mar 2001 21:28:24 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP id 3D53BBA08
	for ; Mon, 26 Mar 2001 21:28:24 +0300 (EEST)
Message-ID: <3ABF8B7B.238EDF74@nomadiclab.com>
Date: Mon, 26 Mar 2001 21:33:31 +0300
From: Pekka Nikander 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fi
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key 
 establishment for Binding Update)
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> James Kempf writes:
>  > I won't presume to say I can contribute much to the security discussion, but
>  > one concern with IKE is deployment. Some network operators may not
>  > want to deploy IKE. Alternative solutions for key distribution (such
>  > as AAA) may be more desirable.
> 
Michael Thomas wrote:
>    Whatever the solution is, it better not rely on
>    AAA exclusively. There is no requirement that AAA
>    be run uniformly. In fact, a pretty large percentage
>    of the devices on the net in the here and now do
>    not use AAA _at all_. The one I'm typing on right
>    now is a fine example.

To add a tidbit.  In order to cover all cases _really_ securely,
IKE would require a global PKI that contains information about
who "owns" which address, i.e., what is the home address of a
given MN.  In technical terms, the PKI would have to include
information to securely bind a home address and a public key together.

The same applies to AAA.  When you scale up AAA, at some point you
must stop assuming that all parties in the AAA are honest.  Once you
do this, you must start including authorization information for the
AAA parties, basically saying "this ISP owns this block of IP addresses"
for each ISP.  AFAIK, such the current AAA architecture does not fully
cover that, not discussing about the associated deployment problems.

Thus, in both cases, establishing the required infrastructure would be 
quite hard and expensive.  

http://www.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt
tries to clarify this and other related problems.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:33:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13892
	for ; Mon, 26 Mar 2001 13:33:38 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22539;
	Mon, 26 Mar 2001 10:31:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02656;
	Mon, 26 Mar 2001 10:31:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIUkIm001913
	for ; Mon, 26 Mar 2001 10:30:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIUj3S001911
	for mobile-ip-dist; Mon, 26 Mar 2001 10:30:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIUaIm001904
	for ; Mon, 26 Mar 2001 10:30:36 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06147
	for ; Mon, 26 Mar 2001 10:30:36 -0800 (PST)
Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA15684
	for ; Mon, 26 Mar 2001 10:30:33 -0800 (PST)
Received: (cpmta 8449 invoked from network); 26 Mar 2001 10:30:30 -0800
Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.64) with SMTP; 26 Mar 2001 10:30:30 -0800
X-Sent: 26 Mar 2001 18:30:30 GMT
Message-ID: <015c01c0b622$c59cba20$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: ,
        "Mohan Parthasarathy" 
References: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com> <3ABF8825.8E51BE6E@nomadiclab.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
Date: Mon, 26 Mar 2001 10:30:02 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> If I read correctly the IESG statement (I might be misreading it),

Where can I find the IESG statement?  I don't see it at
http://www.ietf.org/IESG/actions.html.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:39:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13946
	for ; Mon, 26 Mar 2001 13:39:29 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27735;
	Mon, 26 Mar 2001 10:38:00 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16747;
	Mon, 26 Mar 2001 10:37:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIaUIm001944
	for ; Mon, 26 Mar 2001 10:36:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIaUBq001943
	for mobile-ip-dist; Mon, 26 Mar 2001 10:36:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIaLIm001936
	for ; Mon, 26 Mar 2001 10:36:21 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03847
	for ; Mon, 26 Mar 2001 10:36:21 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA16547
	for ; Mon, 26 Mar 2001 10:36:21 -0800 (PST)
Message-Id: <200103261836.KAA16547@heliopolis.Eng.Sun.COM>
Date: Mon, 26 Mar 2001 10:36:21 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key  establishment for Binding Update)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pCThrcv6JgsGF/QGplSe2g==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Pekka,

>To add a tidbit.  In order to cover all cases _really_ securely,
>IKE would require a global PKI that contains information about
>who "owns" which address, i.e., what is the home address of a
>given MN.  In technical terms, the PKI would have to include
>information to securely bind a home address and a public key together.
>
>The same applies to AAA.  When you scale up AAA, at some point you
>must stop assuming that all parties in the AAA are honest.  Once you
>do this, you must start including authorization information for the
>AAA parties, basically saying "this ISP owns this block of IP addresses"
>for each ISP.  AFAIK, such the current AAA architecture does not fully
>cover that, not discussing about the associated deployment problems.
>
>Thus, in both cases, establishing the required infrastructure would be 
>quite hard and expensive.  
>
>http://www.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.tx
t
>tries to clarify this and other related problems.

Like I said, I haven't looked at this problem in detail. I was merely
arguing from an "installed base" perspective. Acceptance of AAA by the
3Gs is further along than IKE, so deployment seems certain. Ultimately,
as you point out, there may be similar problems in global deployment.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:44:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13980
	for ; Mon, 26 Mar 2001 13:44:38 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03157;
	Mon, 26 Mar 2001 10:43:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17942;
	Mon, 26 Mar 2001 10:43:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIffIm001998
	for ; Mon, 26 Mar 2001 10:41:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIfe3A001997
	for mobile-ip-dist; Mon, 26 Mar 2001 10:41:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QIfVIm001989
	for ; Mon, 26 Mar 2001 10:41:31 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17585
	for ; Mon, 26 Mar 2001 10:41:31 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22055
	for ; Mon, 26 Mar 2001 10:41:26 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 26 Mar 2001 12:29:09 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 26 Mar 2001 12:34:16 -0600
Message-ID: 
From: "Haseeb Akhtar" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key es 
         tablishment for Binding Update)
Date: Mon, 26 Mar 2001 12:34:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B623.5D29E070"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B623.5D29E070
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

In addition, the 3GPP has also decided to deploy a AAA protocol 
between the call servers (known as x-CSCF) and the users info
center (termed HSS for Home Subscriber Server). The current
leaning is heavily toward Diameter.

Regards,

Haseeb
 

-----Original Message-----
From: James Kempf [mailto:kempf@heliopolis.eng.sun.com]
Sent: Monday, March 26, 2001 12:22 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key
establishment for Binding Update)


Mike,


> > >Sorry for the confusion. I was summarizing the IESG (and others)
concerns
> > >about using AH for solving the mobile IPv6 security problem.
> > >I did not mean to use the word "scale". Hence, if we don't want to use
AH
> > >and not solve the authorization problem, why can't we just use the IKE
> > >part alone ? If this is also considered heavy weight, all new solutions
> > >should be compared against this. 
> > >
> > 
> > I won't presume to say I can contribute much to the security discussion,
but
> > one concern with IKE is deployment. Some network operators may not
> > want to deploy IKE. Alternative solutions for key distribution (such
> > as AAA) may be more desirable.
>
>
>   Whatever the solution is, it better not rely on
>   AAA exclusively. There is no requirement that AAA
>   be run uniformly. In fact, a pretty large percentage
>   of the devices on the net in the here and now do 
>   not use AAA _at all_. The one I'm typing on right 
>   now is a fine example.
>

I did not say that it should be used exclusively, only that IKE should
not be the only solution due to concerns about widespread
deployment.

With regard to how many devices will use AAA, both
3GPP and 3GPP2 have recently standardized on the IETF AAA architecture
for their all IP core networks. 3GPP2 is in the process of deploying
AAA for mobile IPv4 in their current IOS v4.x with Radius as the protocol,
and in Version C, to be standardized this summer, they intend to
employ Diameter. I believe it is a fair assessment to say that AAA will
likely
be widely deployed in telephony networks in the future. 

Perhaps you have some information about similar deployment plans for IKE
that motivated your statement? If so, perhaps you could share it?

		jak


------_=_NextPart_001_01C0B623.5D29E070
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key  establishment for Binding Update)




Folks,




In addition, the 3GPP has also decided to deploy a AAA protocol 

between the call servers (known as x-CSCF) and the users info

center (termed HSS for Home Subscriber Server). The current

leaning is heavily toward Diameter.




Regards,




Haseeb

 




-----Original Message-----

From: James Kempf [mailto:kempf@heliopolis.eng.sun.com]

Sent: Monday, March 26, 2001 12:22 PM

To: mobile-ip@sunroof.eng.sun.com

Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key

establishment for Binding Update)






Mike,






> > >Sorry for the confusion. I was summarizing the IESG (and others) concerns

> > >about using AH for solving the mobile IPv6 security problem.

> > >I did not mean to use the word "scale". Hence, if we don't want to use AH

> > >and not solve the authorization problem, why can't we just use the IKE

> > >part alone ? If this is also considered heavy weight, all new solutions

> > >should be compared against this. 

> > >

> > 

> > I won't presume to say I can contribute much to the security discussion, but

> > one concern with IKE is deployment. Some network operators may not

> > want to deploy IKE. Alternative solutions for key distribution (such

> > as AAA) may be more desirable.

>

>

>   Whatever the solution is, it better not rely on

>   AAA exclusively. There is no requirement that AAA

>   be run uniformly. In fact, a pretty large percentage

>   of the devices on the net in the here and now do 

>   not use AAA _at all_. The one I'm typing on right 

>   now is a fine example.

>




I did not say that it should be used exclusively, only that IKE should

not be the only solution due to concerns about widespread

deployment.




With regard to how many devices will use AAA, both

3GPP and 3GPP2 have recently standardized on the IETF AAA architecture

for their all IP core networks. 3GPP2 is in the process of deploying

AAA for mobile IPv4 in their current IOS v4.x with Radius as the protocol,

and in Version C, to be standardized this summer, they intend to

employ Diameter. I believe it is a fair assessment to say that AAA will likely

be widely deployed in telephony networks in the future. 




Perhaps you have some information about similar deployment plans for IKE

that motivated your statement? If so, perhaps you could share it?




                jak





------_=_NextPart_001_01C0B623.5D29E070--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:50:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14089
	for ; Mon, 26 Mar 2001 13:50:58 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08641;
	Mon, 26 Mar 2001 10:49:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06984;
	Mon, 26 Mar 2001 10:49:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QImZIm002079
	for ; Mon, 26 Mar 2001 10:48:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QImZ8h002078
	for mobile-ip-dist; Mon, 26 Mar 2001 10:48:35 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QImQIm002071
	for ; Mon, 26 Mar 2001 10:48:27 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2QIlCl00511;
	Mon, 26 Mar 2001 10:47:12 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103261847.f2QIlCl00511@locked.eng.sun.com>
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
In-Reply-To: <3ABF8825.8E51BE6E@nomadiclab.com> from Pekka Nikander at "Mar 26,
 2001 09:19:17 pm"
To: Pekka Nikander 
Date: Mon, 26 Mar 2001 10:47:12 -0800 (PST)
CC: mobile-ip@sunroof.eng.sun.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Mohan,
> 
> > Sorry for the confusion. I was summarizing the IESG (and others) concerns
> > about using AH for solving the mobile IPv6 security problem.
> > I did not mean to use the word "scale". Hence, if we don't want to use AH
> > and not solve the authorization problem, why can't we just use the IKE
> > part alone ?
> 
> If I read correctly the IESG statement (I might be misreading it),
> the concern is not about using AH per se but about "[the] significant 
> overhead associated with building and maintaining AH/IPsec SAs", 
> where "building" basically means running IKE.  I certainly agree 

I think the concern was more than that.

     a) There is significant overhead associated with building and 
      maintaining AH/IPsec SAs (both in terms of state that needs to
      be maintained, but also in terms of required message flows, and
      the processing required to implement those flows). This has
      negative implications for larger servers that process many 100s
      of thousands of connections at a time.

This talks about building and maintaining AH/IPsec SAs though i
don't understand the maintenance part :-)

b) The processing rules for authenticating a Binding Update with AH
      are complex and are apparently not readily supported by the
      current generation of IPsec/IKE implementations (e.g., the IPsec
      policies are needed that specify sufficient granularity about
      IPv6 packets containing binding updates). There is a concern
      that this will not be rectified in the short term or that
      providing this level of granularity is even approriate for
      IPsec, leading to a possible result that the Binding Update
      won't be implemented/supported at all, (or even worse) that it
      will be used without proper authentication.

This essentially talks about the lack of selectors for specific destination
options and the inability to negotiate one using IKE. I don't think
this is really that big a serious issue when compared to others.

> that building a large number of AH SAs does require a lot of 
> messages and a heavy daemon (the IKE deamon).   However, I am not 
> so sure about the cost of "maintaining" a large number of SAs,
> especially if the traffic flowing over those SAs is so small that
> rekeying is not needed.  Thus, if we can establish some "special
> purpose" AH SAs using some lighther protocol than IKE, I still think that
> it might be a good idea to use AH or even integrity preserving ESP to 
> protect the actual BUs.
>
We need to define what lighter protocol is ? Less secure (this needs
to be broken down further e.g. Is man in the middle attack ok ?
Is DoS attack ok ?), fewer roundtrips, less computational overhead
etc. This is the draft i was mentioning earlier at the IETF :

draft-snoeren-tcp-migrate-00.txt

which essentially does a diffie-hellman exchange and establishes
a shared secret. When the connection needs to be migrated, it
provides a token (HMAC of sequence numbers etc.). A similar one
can be done here. I think there is no authentication in this.
We can get it by routing packets through Home Agent if we feel
that it is sufficient.

-mohan

> By the way, if somebody has good numbers about the typical memory
> print of an AH or ESP SA, it would be very interesting to see them.
> 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 13:58:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14149
	for ; Mon, 26 Mar 2001 13:58:05 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15131;
	Mon, 26 Mar 2001 10:57:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11961;
	Mon, 26 Mar 2001 10:56:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QItiIm002150
	for ; Mon, 26 Mar 2001 10:55:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QIthcK002149
	for mobile-ip-dist; Mon, 26 Mar 2001 10:55:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QItYIm002139
	for ; Mon, 26 Mar 2001 10:55:34 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2QItVxf148753;
	Mon, 26 Mar 2001 10:55:31 -0800 (PST)
Message-Id: <200103261855.f2QItVxf148753@jurassic.eng.sun.com>
Date: Mon, 26 Mar 2001 10:56:32 -0800 (PST)
From: Samita Chakrabarti 
Subject: [mobile-ip] Comments on hmipv6 draft and a proposal on a third mode
To: Hesham.Soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr, Karim.El-Malki@era.ericsson.se,
        ludovic.bellier@inria.fr, james.kempf@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: U5u2jvg4OtL/jFqQJI0vyg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Sorry for the late posting... But  most of the comments have been discussed with
hmipv6 authors in private emails. 

The comments are based  mostly on hmipv6 version 2 draft.
Also, I'd like to propose a third mode in hmipv6 especially
for those systems which do not have ROHC implementation
at their network.
Thus this proposed mode will save 40 bytes of tunnel overhead
between MAP and mobile node in the basic mode. I understand that
this would be useful for IPRAN  as James Kempf had pointed out 
earlier in the list.



Editorial comments:

section 3.0 : one or two word description of 'B' flag would be helpful

section 3.1 : Load-balancing sub-option : needs more clarification as to where the
              sub-option is sent ( to MAP only or CN as well ?)
              Load-balancing may be a misnomer, perhaps a more suitable name should
              be used as this option basically is used by the MN for balancing load
              over different interfaces. But the load-balancing is dependent on the
              flow policies. So, how about "Policy" sub-option or other suitable names ?

              How about changing 'prot number' to 'proto number' ?
              Needs description for dest-port, r and Destination address, I suppose
              destination address should be LCOA

              'P' bit description should clarify which "ip-address" (LCOA?) is used
               to identify flow.

               Since checking for flow-label or port-ipaddr pair also involve checking
               each packet at MAP, 'per-packet' load balancing description is a bit
               confusing in this context. Since 'per-packet' load-balancing refers to
               'A' bit only, another beeter name or more clarification required here.




Section 4.0    An example of 'T' bit would help

Section 5.0    A little more detailed analysis of choices of MAP discovery will be
               a good guide for implementors and users to pick which one to pick
               in their implementation/operating environment.
               

Section 5.4:   3rd paragraph mentions :
               "If a MN has access to several ARs.......it's current MAP"
               an example will be helpful in order to describe this scenario.
Section 11:    Needs more clarification ( I was told that version 3 has improved texts)

Section 15:   Reference for AAAv6 should be recorded.


Technical :
----------
 (Some of the following are discussed with hmipv6 authors)

Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
               Next version of draft should also specify possible error codes--
               at least the 'errors in text form'.

Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP discovery
              and specify one or two options as 'MUST' to implement. Otherwise,
              implementations either will become too complex or will not interoperate.

Section 6.1 : Please specify that alternate COA sub-option is optional when RCOA is
              used as source address of the BU. (for location privacy)

Section 11 : This section should also mention that the hierarchical network between
             MAP and MNs must be a trusted network and no src-address filtering is done
             on the outging packets from the mobile nodes.

Section 7.1 and 7.2 :
              Added operation in HA can be easily avoided if :
              A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
              uses for connection.

              But I think, having HA to add RH in the outer IP layer, has two
              advantages:

              1) less signalling between MN and AR ( this is probably desirable by
                 wirelss vendors)
      
              2) Supporting site-local addressed home-addr in the foreign domain.
              
Load Balancing in general:              
BTW, a detailed load balancing scheme for fault-tolerance for MAP should be schetched
out so that the backup MAP can takes over when the orginial MAP goes down. Perhaps the
policy and MAP load babalncing scenarios should be discussed in a separate draft to
keep this draft simple. But we can toss ideas and discuss more on that in the 
discussion team.



Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical network where
ROHC is not available.

Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels between MAP and MN
         
MAP Operation: 
           In this mode, MAP recives BU and sends BAck after performing DAD operation
           as described in basic mode. A new bit will be introduced in the MAP advertisement
           to distinguish "Basic non-tunnel" mode service from other two modes.

      The new MAP option format ( as per discussion with Hesham Soliman):


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Distance     |  Pref         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Plen      |R|M|T|N|            Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                  Global IP Address for MAP                    +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          N  - Indicates that the MN MUST be able to replace the destination
               address of incoming packet from LCOA to RCOA when the packets
               are coming from either a correspondent node or it's home agent.
               R bit MUST be set when N bit is set. N bit MUST not be set
               when M is bit is set. Basicaly N bit is an indication of MAP
               supporting basic-non-tunnel mode.

           The MAP keeps a binding cache containing association
           of RCOA, LCOA and MN's home-addr. It intercepts the packets that are destined
           to RCOA (either from HA or from CN. Note that in basic mode RCOA is different
           from MAP's own address.) MAP then replaces the destination IP-address RCOA by
           LCOA after looking up the binding cache, and simply forwards the packet to
           the topologically correct router in the hierarchy.

MN Operations:
         
           MN forms LCOA and RCOA exactly the same way as described in basic mode. It also
           sends BU to MAP and home agent subsequently exactly the same way as described
           in 6.1 (Basic mode MN operations). MN may also send BU to CN informing RCOA as
           it's new COA ( same as in basic-mode operation).

           MN receives packets addressed to MN's LCOA address, MN replaces the LCOA address
           by the corresponding RCOA address after determining that this packet is
           coming from either it's home agent or correspondent node. MN then proceeds
           with normal processing of packets as described in base mobile IPv6 draft.

           The differnce between basic mode MN and basic-non-tunnel mode MN is that
           the latter, does not need to detunnel the packet from MAP at all. Instead it
           swaps the destination address of the incoming  packet when the
           source address is home agent address or  correspondent node address.
           Thus a mobile node implementation may maintain a list of CNs and
           Home agents for address verification.

HA Operation:
           No change from basic mode operation.

----------------------------------------------------------------------------------------

Thanks,
-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:03:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14267
	for ; Mon, 26 Mar 2001 14:03:47 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21239;
	Mon, 26 Mar 2001 11:02:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22994;
	Mon, 26 Mar 2001 11:02:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ0TIm002186
	for ; Mon, 26 Mar 2001 11:00:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJ0Shg002185
	for mobile-ip-dist; Mon, 26 Mar 2001 11:00:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ0IIm002176
	for ; Mon, 26 Mar 2001 11:00:18 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09549
	for ; Mon, 26 Mar 2001 11:00:17 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03882
	for ; Mon, 26 Mar 2001 11:00:16 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22910
	for ; Mon, 26 Mar 2001 11:00:16 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC13769;
	Mon, 26 Mar 2001 11:00:14 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02508; Mon, 26 Mar 2001 11:00:14 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.37310.549710.664479@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 11:00:14 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key es 
         tablishment for Binding Update)
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Haseeb Akhtar writes:
 > Folks,
 > 
 > In addition, the 3GPP has also decided to deploy a AAA protocol 
 > between the call servers (known as x-CSCF) and the users info
 > center (termed HSS for Home Subscriber Server). The current
 > leaning is heavily toward Diameter.

   1) IETF doesn't do architectures

   2) This is pretty much a faithful recreation
      of the PSTN with all of its inherent problems

   3) Public Cellular is not the only user of mobility. 
      In fact, it may very well be fairly far down on
      the list of deployments given the cost and ease
      of other wireless technologies

   4) That 3GPP has decided to use AAA at SIP proxies
      is pretty out there on its own as far as SIP goes.
      The current reality is HTTP basic/digest authentication; I
      place no value judgement on that. In fact, there is no
      standard way in SIP to deliver CHAP-like credentials at all.

   Not that this has anything to do with mobile IP. What does
   have to do with Mobile IP is that it MUST be authentication
   system neutral instead of trying to pick favorites.

		  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:06:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14362
	for ; Mon, 26 Mar 2001 14:06:18 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21089;
	Mon, 26 Mar 2001 11:03:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23355;
	Mon, 26 Mar 2001 11:03:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ20Im002205
	for ; Mon, 26 Mar 2001 11:02:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJ20lw002204
	for mobile-ip-dist; Mon, 26 Mar 2001 11:02:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJ1oIm002197
	for ; Mon, 26 Mar 2001 11:01:51 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22721
	for ; Mon, 26 Mar 2001 11:01:50 -0800 (PST)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19065
	for ; Mon, 26 Mar 2001 12:01:48 -0700 (MST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 26 Mar 2001 13:56:48 -0500
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] new contact info
Date: Mon, 26 Mar 2001 13:56:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi folks,

    Please note my new email address: proberts@megisto.com.

Phil



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:27:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14713
	for ; Mon, 26 Mar 2001 14:27:13 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10331;
	Mon, 26 Mar 2001 11:26:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16099;
	Mon, 26 Mar 2001 11:25:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJOUIm002354
	for ; Mon, 26 Mar 2001 11:24:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJOTUQ002353
	for mobile-ip-dist; Mon, 26 Mar 2001 11:24:29 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJOLIm002346
	for ; Mon, 26 Mar 2001 11:24:21 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19155
	for ; Mon, 26 Mar 2001 11:24:20 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08977
	for ; Mon, 26 Mar 2001 11:24:19 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04162
	for ; Mon, 26 Mar 2001 11:24:22 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC14599;
	Mon, 26 Mar 2001 11:24:18 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02512; Mon, 26 Mar 2001 11:24:18 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.38754.398599.433366@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 11:24:18 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)
In-Reply-To: <200103261822.KAA16261@heliopolis.Eng.Sun.COM>
References: <200103261822.KAA16261@heliopolis.Eng.Sun.COM>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Mike,
 > 
 > 
 > > > >Sorry for the confusion. I was summarizing the IESG (and others) concerns
 > > > >about using AH for solving the mobile IPv6 security problem.
 > > > >I did not mean to use the word "scale". Hence, if we don't want to use AH
 > > > >and not solve the authorization problem, why can't we just use the IKE
 > > > >part alone ? If this is also considered heavy weight, all new solutions
 > > > >should be compared against this. 
 > > > >
 > > > 
 > > > I won't presume to say I can contribute much to the security discussion, but
 > > > one concern with IKE is deployment. Some network operators may not
 > > > want to deploy IKE. Alternative solutions for key distribution (such
 > > > as AAA) may be more desirable.
 > >
 > >
 > >   Whatever the solution is, it better not rely on
 > >   AAA exclusively. There is no requirement that AAA
 > >   be run uniformly. In fact, a pretty large percentage
 > >   of the devices on the net in the here and now do 
 > >   not use AAA _at all_. The one I'm typing on right 
 > >   now is a fine example.
 > >
 > 
 > I did not say that it should be used exclusively, only that IKE should
 > not be the only solution due to concerns about widespread
 > deployment.

   What do you plan to use to key other SA's?
   AAA as well? If so, I sure hope that somebody
   has got the green light from the AAA chair and
   AD's, not to mention the security AD's.
 
 > Perhaps you have some information about similar deployment plans for IKE
 > that motivated your statement? If so, perhaps you could share it?

   I'm not a huge IKE fan, but I do know that the
   cable MSO's are using Kerberos to key SA's for
   MGCP/SIP, and that there's a real working group
   to really standardize Kerberized IPsec in IETF.
   Using (or not) AAA for a similar general
   purpose keying mechanism really should not be
   done piece meal, and *especially* from MIP WG. 
   If people think that AAA is a good way to key
   SA's, we ought to have a BOF and a real WG to
   set the charter and requirements. As it is
   right, now using AAA to key SA's is an
   amorphous requirementless free for all. Since
   it's a security protocol, that should frighten
   everybody.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:42:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14886
	for ; Mon, 26 Mar 2001 14:42:40 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12752;
	Mon, 26 Mar 2001 11:41:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22973;
	Mon, 26 Mar 2001 11:41:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJdlIm002376
	for ; Mon, 26 Mar 2001 11:39:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJdk7R002375
	for mobile-ip-dist; Mon, 26 Mar 2001 11:39:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJdbIm002368
	for ; Mon, 26 Mar 2001 11:39:37 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02406
	for ; Mon, 26 Mar 2001 11:39:36 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11773
	for ; Mon, 26 Mar 2001 12:39:35 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18093
	for ; Mon, 26 Mar 2001 11:39:31 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2QJdT512671
	for ; Mon, 26 Mar 2001 11:39:29 -0800
X-mProtect:  Mon, 26 Mar 2001 11:39:29 -0800 Nokia Silicon Valley Messaging Protection
Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdWiogCz; Mon, 26 Mar 2001 11:37:59 PST
Message-ID: <3ABF9A98.6671761A@Kniveton.com>
Date: Mon, 26 Mar 2001 11:38:00 -0800
From: "T.J. Kniveton" 
Organization: NOKIA Research
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Renumbering Slides
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi folks,

Anyone who is interested in taking another look at the Network
Renumbering & Tunneled RA/RS slides I presented in Minneapolis can go to
this URL:

http://www.kniveton.com/tj/specs/IETF_Renum.ppt

As I mentioned in the talk, I have already done some work on updating
the renumbering sections of the draft, but have not yet added the new
ICMP types proposed. Comments on this work are still welcomed.

-- 
T.J. Kniveton
NOKIA Research


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:44:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14953
	for ; Mon, 26 Mar 2001 14:44:26 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12848;
	Mon, 26 Mar 2001 11:41:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23037;
	Mon, 26 Mar 2001 11:41:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJdxIm002386
	for ; Mon, 26 Mar 2001 11:39:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJdxsA002385
	for mobile-ip-dist; Mon, 26 Mar 2001 11:39:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJdlIm002377
	for ; Mon, 26 Mar 2001 11:39:48 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22435
	for ; Mon, 26 Mar 2001 11:39:47 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA18602
	for ; Mon, 26 Mar 2001 11:39:47 -0800 (PST)
Message-Id: <200103261939.LAA18602@heliopolis.Eng.Sun.COM>
Date: Mon, 26 Mar 2001 11:39:47 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xUTv3hissCjyVABEchv9sw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mike,


>   I'm not a huge IKE fan, but I do know that the
>   cable MSO's are using Kerberos to key SA's for
>   MGCP/SIP, and that there's a real working group
>   to really standardize Kerberized IPsec in IETF.
>   Using (or not) AAA for a similar general
>   purpose keying mechanism really should not be
>   done piece meal, and *especially* from MIP WG. 
>   If people think that AAA is a good way to key
>   SA's, we ought to have a BOF and a real WG to
>   set the charter and requirements. As it is
>   right, now using AAA to key SA's is an
>   amorphous requirementless free for all. Since
>   it's a security protocol, that should frighten
>   everybody.

Sounds like you have identified a topic for a BOF at the London meeting.
I'll post the idea to aaa-wg and see what they think.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 14:58:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15180
	for ; Mon, 26 Mar 2001 14:58:23 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20300;
	Mon, 26 Mar 2001 11:56:30 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27048;
	Mon, 26 Mar 2001 11:56:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJstIm002415
	for ; Mon, 26 Mar 2001 11:54:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QJssuP002414
	for mobile-ip-dist; Mon, 26 Mar 2001 11:54:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QJsjIm002407
	for ; Mon, 26 Mar 2001 11:54:45 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26692;
	Mon, 26 Mar 2001 11:54:43 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20566;
	Mon, 26 Mar 2001 12:54:42 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06815;
	Mon, 26 Mar 2001 11:54:42 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC15497;
	Mon, 26 Mar 2001 11:54:37 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02523; Mon, 26 Mar 2001 11:54:37 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.40573.248580.812108@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 11:54:37 -0800 (PST)
To: Dan Harkins 
Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com,
        "'T.J. Kniveton'" ,
        Carl Williams ,
        Alper Yegin ,
        Brian Zill 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-Reply-To: <200103221517.f2MFH2x55009@potassium.cips.nokia.com>
References: <15033.30640.461564.221205@thomasm-u1.cisco.com>
	<200103221517.f2MFH2x55009@potassium.cips.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Dan Harkins writes:
 >   I don't have any particular treaty organizations in mind. Any one will
 > suffice. Pick your favorite one. 
 > 
 >   My point was that you cannot authenticate a message with unauthenticated
 > keys and the same people that can muck with a binding update (which I assume
 > is motivating this) are the people who can play man-in-the-middle against
 > this scheme. That is regardless of the existence of, or the distaste in
 > using, some entity to act as a trusted third party.

   You'll get no argument from me on this account.
   However this is all about picking one's poison. 
   If you think that the MIM attack is credible 
   enough that this is all loony-toon, by all means
   say so, and more importantly show some credible
   attack scenarios. It serves nobody to rehash old
   ground if we're headed for another unacceptible 
   dead end.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 15:48:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16083
	for ; Mon, 26 Mar 2001 15:48:21 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13126;
	Mon, 26 Mar 2001 12:47:17 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03315;
	Mon, 26 Mar 2001 12:47:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKiWIm002594
	for ; Mon, 26 Mar 2001 12:44:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QKiW8N002593
	for mobile-ip-dist; Mon, 26 Mar 2001 12:44:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKiJIm002586
	for ; Mon, 26 Mar 2001 12:44:21 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06881
	for ; Mon, 26 Mar 2001 12:43:43 -0800 (PST)
Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA14860
	for ; Mon, 26 Mar 2001 12:43:42 -0800 (PST)
Received: (cpmta 25949 invoked from network); 26 Mar 2001 12:43:42 -0800
Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.71) with SMTP; 26 Mar 2001 12:43:42 -0800
X-Sent: 26 Mar 2001 20:43:42 GMT
Message-ID: <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com>
Subject: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 12:43:02 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

May I suggest a proposal on how to progress standardization of MIPv6?

Take out all of the "route optimization" parts and run it basically like
RFC2002 is run today, including the ability to assign a local home address
to a mobile node in a visited domain.  This is basically what Mohan
suggested in an earlier email (and perhaps others), but I would like to add
my voice to that sentiment.

This would allow us to move forward with standardization of MIPv6 while
giving us time to sort out the security issues of route optimization without
a huge panic.

Not having route optimization (for the time being) is not necessarily that
big a deal.  If you have something akin to the Home Domain Allocation
Function (HDAF), then a mobile can get a new home address when it roams
(powers up in a new location), and any mobility in that region will be
pretty efficient by virtue of proximity to the (visited) home agent.  (This
at least is my understanding of HDAF from reading RFC2794).

Once assigned a (visited) home address, the mobile can use SIP to register
its location with its SIP proxy.  For other applications (web browsing), it
just works as a client as usual.

I suspect that this will cover 90-some % of "optimization" requirements.

PF






From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 15:53:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16310
	for ; Mon, 26 Mar 2001 15:53:42 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20339;
	Mon, 26 Mar 2001 12:52:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09391;
	Mon, 26 Mar 2001 12:52:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKpRIm002613
	for ; Mon, 26 Mar 2001 12:51:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QKpRtc002612
	for mobile-ip-dist; Mon, 26 Mar 2001 12:51:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QKpIIm002605
	for ; Mon, 26 Mar 2001 12:51:18 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16917
	for ; Mon, 26 Mar 2001 12:51:17 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18436
	for ; Mon, 26 Mar 2001 12:51:13 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16352
	for ; Mon, 26 Mar 2001 12:51:13 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC17116;
	Mon, 26 Mar 2001 12:51:11 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02548; Mon, 26 Mar 2001 12:51:11 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.43967.633458.666356@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 12:51:11 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com>
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM>
	<15039.34511.324164.457274@thomasm-u1.cisco.com>
	<021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Paul Francis writes:
 > Once assigned a (visited) home address, the mobile can use SIP to register
 > its location with its SIP proxy.  For other applications (web browsing), it
 > just works as a client as usual.

   How do you deal with in-progress RTP streams? What
   about their QoS requirements?

	       Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 16:25:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16849
	for ; Mon, 26 Mar 2001 16:25:37 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16229;
	Mon, 26 Mar 2001 13:24:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23678;
	Mon, 26 Mar 2001 13:24:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLM7Im002688
	for ; Mon, 26 Mar 2001 13:22:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QLM7i2002687
	for mobile-ip-dist; Mon, 26 Mar 2001 13:22:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLLwIm002680
	for ; Mon, 26 Mar 2001 13:21:58 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24837
	for ; Mon, 26 Mar 2001 13:21:56 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14192
	for ; Mon, 26 Mar 2001 13:21:56 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14543;
	Mon, 26 Mar 2001 13:22:17 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADC18029;
	Mon, 26 Mar 2001 13:21:54 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02558; Mon, 26 Mar 2001 13:21:54 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15039.45809.955541.938221@thomasm-u1.cisco.com>
Date: Mon, 26 Mar 2001 13:21:53 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekka.nikander@nomadiclab.com
Subject: Re: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
In-Reply-To: <3AB75389.25077265@inrialpes.fr>
References: <3AB63A39.49928755@nomadiclab.com>
	<3AB75389.25077265@inrialpes.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Claude Castelluccia writes:
 > 
 > Hello Pekka and thanks for your comments.
 > 
 > Pekka Nikander wrote:
 > 
 > > Claude,
 > >
 > > Here are some half-baked comments to your draft
 > > draft-castelluccia-mobileip-privacy-00.txt
 > >
 > > Firstly, I don't immediately see the usability of TMI instead
 > > of just dropping the Home Address altogether, as I suggest
 > > (among other things) in my Homeless Mobile IPv6 draft,
 > >   draft-nikander-mobileip-homelessv6-01.txt
 > 
 > The reasons for not dropping the Home Address altogether
 > are the same that the reasons why we do not encrypt the Home Address
 > option.
 > There were some discussions about this issues few weeks ago on the
 > mailing list...
 > The reasons of keeping the Home Address (in cleartext) is:
 > - because IPSec uses it to locate the SA...if you remove the Home
 > Address
 > option you basically needs to use the CoA and since this CoA changes you
 > 
 > have to reestablished the SA each time you move...
 > - because some firewalls use it to perform some kind of filtering...

   You could do the same thing by placing the
   home address in the source address too. 

   In general, I think we need to be very careful
   about requiring intermediate routers to inspect
   things that are explicitly intended to be end
   to end. There are performance issues to be 
   considered when requiring routers to chase down 
   IP header chains. I'm aware that transport
   headers are in the same predicament, but that's
   a bug, not a feature in my mind.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 16:51:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17555
	for ; Mon, 26 Mar 2001 16:51:02 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12995;
	Mon, 26 Mar 2001 13:49:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15868;
	Mon, 26 Mar 2001 13:49:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLlhIm002735
	for ; Mon, 26 Mar 2001 13:47:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QLlhdg002734
	for mobile-ip-dist; Mon, 26 Mar 2001 13:47:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLlYIm002727
	for ; Mon, 26 Mar 2001 13:47:34 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2QLkJX00602
	for mobile-ip@sunroof.eng.sun.com; Mon, 26 Mar 2001 13:46:19 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103262146.f2QLkJX00602@locked.eng.sun.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com> from Paul
 Francis at "Mar 26, 2001 12:43:02 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Mon, 26 Mar 2001 13:46:19 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> May I suggest a proposal on how to progress standardization of MIPv6?
> 
> Take out all of the "route optimization" parts and run it basically like
> RFC2002 is run today, including the ability to assign a local home address
> to a mobile node in a visited domain.  This is basically what Mohan
> suggested in an earlier email (and perhaps others), but I would like to add
> my voice to that sentiment.
>
I am not sure whether i suggested that or not :-) But what i have
been trying to find out is the usefulness of sending a binding
update if i am just going to exchange a few packets. Then, the
overhead of setting up the SA becomes important. I am not sure
how many packets you need to amortize the cost of setting up
the SA. So, would MN make any discretion (using other information)
in when to send the binding update ? If so, the overhead part
is not an issue.


> This would allow us to move forward with standardization of MIPv6 while
> giving us time to sort out the security issues of route optimization without
> a huge panic.
>
I don't think this will fly. I think one of the main features is route
optimization, at least from all disucssions that i have seen.

> Not having route optimization (for the time being) is not necessarily that
> big a deal.  If you have something akin to the Home Domain Allocation
> Function (HDAF), then a mobile can get a new home address when it roams
> (powers up in a new location), and any mobility in that region will be
> pretty efficient by virtue of proximity to the (visited) home agent.  (This
> at least is my understanding of HDAF from reading RFC2794).
> 
> Once assigned a (visited) home address, the mobile can use SIP to register
> its location with its SIP proxy.  For other applications (web browsing), it
> just works as a client as usual.
>
How secure is the SIP registration part ?

-mohan
 
> I suspect that this will cover 90-some % of "optimization" requirements.
> 
> PF
> 
> 
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 16:58:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18024
	for ; Mon, 26 Mar 2001 16:58:36 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16993;
	Mon, 26 Mar 2001 13:57:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17624;
	Mon, 26 Mar 2001 13:57:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLuCIm002814
	for ; Mon, 26 Mar 2001 13:56:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QLuChD002813
	for mobile-ip-dist; Mon, 26 Mar 2001 13:56:12 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLu1Im002806
	for ; Mon, 26 Mar 2001 13:56:01 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01235
	for ; Mon, 26 Mar 2001 13:56:00 -0800 (PST)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA01720
	for ; Mon, 26 Mar 2001 13:55:58 -0800 (PST)
Date: Mon, 26 Mar 2001 13:55:57 -0800 (PST)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <200103262146.f2QLkJX00602@locked.eng.sun.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> > May I suggest a proposal on how to progress standardization of MIPv6?
> > 
> > Take out all of the "route optimization" parts and run it basically like
> > RFC2002 is run today, including the ability to assign a local home address
> > to a mobile node in a visited domain.  This is basically what Mohan
> > suggested in an earlier email (and perhaps others), but I would like to add
> > my voice to that sentiment.
> >
> I am not sure whether i suggested that or not :-) But what i have
> been trying to find out is the usefulness of sending a binding
> update if i am just going to exchange a few packets. Then, the
> overhead of setting up the SA becomes important. I am not sure
> how many packets you need to amortize the cost of setting up
> the SA. So, would MN make any discretion (using other information)
> in when to send the binding update ? If so, the overhead part
> is not an issue.

Just to play the Devil's advocate, is mobility important by itself, or only
with route optimization? (btw, I've heard from folks that route optimization
is less important than getting base Mobile IP out there).

If so, then I agree with Paul's proposal to move the route opt work to a
separate I-D, as it is done in the v4 world. This way, Mobile IPv6 can move
ahead, while the important security aspects of route optimization can be
ironed out.

(btw, I am assuming that such an editorial change is even possible, and not
having read the document, my comments above may be pointless).

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 17:59:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20063
	for ; Mon, 26 Mar 2001 17:59:13 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02114;
	Mon, 26 Mar 2001 14:58:07 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15258;
	Mon, 26 Mar 2001 14:57:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QMuNIm002920
	for ; Mon, 26 Mar 2001 14:56:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QMuMbJ002919
	for mobile-ip-dist; Mon, 26 Mar 2001 14:56:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QMuDIm002912
	for ; Mon, 26 Mar 2001 14:56:14 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14819;
	Mon, 26 Mar 2001 14:56:14 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17631;
	Mon, 26 Mar 2001 14:56:14 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA08218;
	Mon, 26 Mar 2001 14:56:13 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2QMuAd26414;
	Mon, 26 Mar 2001 14:56:10 -0800
X-mProtect:  Mon, 26 Mar 2001 14:56:10 -0800 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdaLCZ5K; Mon, 26 Mar 2001 14:55:45 PST
Message-ID: <3ABFC93F.C87E4EC6@iprg.nokia.com>
Date: Mon, 26 Mar 2001 14:57:03 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Pat,


> Just to play the Devil's advocate, is mobility important by itself, or only
> with route optimization?

"Mobility" is "more important" than "route optimization".  But allowing
the correspondent node to send packets to a mobile node, and (just as
important) getting the home agent out of the typical routing path, is an
important aspect of the scalability of the protocol.

> If so, then I agree with Paul's proposal to move the route opt work to a
> separate I-D, as it is done in the v4 world. This way, Mobile IPv6 can move
> ahead, while the important security aspects of route optimization can be
> ironed out.

I think this is premature.  We have only just recently gotten a clear picture
about what is needed from the standpoint of the IESG.  The Binding Update
message is, after all, what the mobile node sends to the Home Agent.

I did, in fact, suggest that we should move forward without specifying
a method by which the mobile node and correspondent node would
develop a security association.  That suggestion was denied.  To change
the specification by eliminating the Binding Update would be very hard,
and almost pointless since it's needed for the home agent.

Again, a good solution is, I think, within reach.

Regards,
Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 18:55:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21162
	for ; Mon, 26 Mar 2001 18:55:04 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11913;
	Mon, 26 Mar 2001 15:54:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17591;
	Mon, 26 Mar 2001 15:54:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QNqaIm003071
	for ; Mon, 26 Mar 2001 15:52:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QNqanI003070
	for mobile-ip-dist; Mon, 26 Mar 2001 15:52:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QNqRIm003063
	for ; Mon, 26 Mar 2001 15:52:27 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2QNqQxf210620;
	Mon, 26 Mar 2001 15:52:27 -0800 (PST)
Message-Id: <200103262352.f2QNqQxf210620@jurassic.eng.sun.com>
Date: Mon, 26 Mar 2001 15:53:28 -0800 (PST)
From: Samita Chakrabarti 
Subject: RE: [mobile-ip] rfc3012 question
To: mobile-ip@sunroof.eng.sun.com
Cc: Alper.Yegin@eng.sun.com, tummala@nortelnetworks.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: moioWOyHJI80LUP/eMgMnw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

As Alper brought this issue, it's a hard problem on specifying
the window size. Mostly the problem will appear in shared media like
wireless or wired LAN.

The scenario :  1. FA does unsolicited adv with challenge C1
                 2. 5 MNs solicit and gets different Challenge
                     numbers (C2, C3....C6)
                 3. Now FA again sends unsolicited adv with C7,
                 4. Now MN1 sends request with C2 value, if your
                    windowsize is 3(for example), the registration
                    will fail due to incorrect authorization.
                    
                    
How do we set a limit on the window size to minimize the
risk in security in the shared media as well as make the implementation
not so complex?

Two thoughts:

One simple idea is to not change challenge value during solicitation,
only change during unsolicited advertisements. This will work very well
in point-to-point connection between MN and FA, but will open security
holes in the shared media, especially when the advertisement interval
is large. The RFC then should specify a MAX (small value) time interval 
between two unsolicited advertisements (to reduce risks of attacks),
when challenge response mechanism is used.

 Another idea is  having a "minimum" window size
specification for challenge value, where:

Minimum window size = Time interval in sec between two periodic 
                      unsolicited advertisements.
                      
In this case, we can allow solicitation to send a new challenge value
with 'at least' one second of granularity. Comments ?



Anyway, RFC3012 should put some text in the RFC to clarify the challenge
values in case of solicitation.

Regards,
-Samita

> 
> I ran into same problem, only way to get around this is by increasing the
> CHALLENGE_WINDOW to bigger number.  In my opinion, which defeats the purpose
> of the draft (RFC) itself.
> 
> Let me know, if you have a solution.
> 
> Rambabu Tummala
> Nortel Networks
> ESN 444-8970
> External (972)684-8970
> 
> 
> -----Original Message-----
> From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com]
> Sent: Saturday, March 17, 2001 5:54 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] rfc3012 question
> 
> 
> Hello,
> 
> I have a question about how FA can keep track of valid challenge values.
> 
> As I understand, FA keeps track of valid challenges by noting the challenge 
> values sent in multicast/broadcast RAs (these are global, received by all
> MNs), 
> and challenge values sent to individual MNs.
> 
> It's easy to keep track of challenge values, when they are sent in a 
> registration reply. MN's identity is the key.
> 
> But, when challenge values are sent in unicast RAs in response to RS, how
> can FA 
> keep track of these? FA wouldn't know the identity of the MN. There's no NAI
> in 
> RS. And the source address of the RS doesn't have to be home address.
> 
> 
> If the solicited RA is sent multicast/broadcast, then since there can be too
> 
> many MNs sending RS, this would fill up the CHALLENGE_WINDOW very quickly
> and 
> create unnecessary rejections.
> 
> Unless I'm missing something, this seems like a problem.
> 
> alper
> 



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 19:21:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21983
	for ; Mon, 26 Mar 2001 19:21:37 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16385;
	Mon, 26 Mar 2001 14:00:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02473;
	Mon, 26 Mar 2001 14:00:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLwgIm002834
	for ; Mon, 26 Mar 2001 13:58:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2QLwgZd002833
	for mobile-ip-dist; Mon, 26 Mar 2001 13:58:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2QLwXIm002826
	for ; Mon, 26 Mar 2001 13:58:33 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02596
	for ; Mon, 26 Mar 2001 13:58:32 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18249
	for ; Mon, 26 Mar 2001 13:58:29 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA02408;
	Mon, 26 Mar 2001 13:58:19 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2QLwFr11360;
	Mon, 26 Mar 2001 13:58:15 -0800
X-mProtect:  Mon, 26 Mar 2001 13:58:15 -0800 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdCh1rGW; Mon, 26 Mar 2001 13:55:54 PST
Message-ID: <3ABFBB3C.AC5F6F37@iprg.nokia.com>
Date: Mon, 26 Mar 2001 13:57:16 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com> <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Paul,

Your suggestion might amount to pulling defeat from the jaws of
victory.  I am optimistic that we can get a baseline proposal to the
working group in the very near-term.  Maybe you would be
willing to take a look at that before giving up?

Regards,
Charlie P.



Paul Francis wrote:

> May I suggest a proposal on how to progress standardization of MIPv6?
>
> Take out all of the "route optimization" parts and run it basically like
> RFC2002 is run today, including the ability to assign a local home address
> to a mobile node in a visited domain.  This is basically what Mohan
> suggested in an earlier email (and perhaps others), but I would like to add
> my voice to that sentiment.
>
> This would allow us to move forward with standardization of MIPv6 while
> giving us time to sort out the security issues of route optimization without
> a huge panic.
>
> Not having route optimization (for the time being) is not necessarily that
> big a deal.  If you have something akin to the Home Domain Allocation
> Function (HDAF), then a mobile can get a new home address when it roams
> (powers up in a new location), and any mobility in that region will be
> pretty efficient by virtue of proximity to the (visited) home agent.  (This
> at least is my understanding of HDAF from reading RFC2794).
>
> Once assigned a (visited) home address, the mobile can use SIP to register
> its location with its SIP proxy.  For other applications (web browsing), it
> just works as a client as usual.
>
> I suspect that this will cover 90-some % of "optimization" requirements.
>
> PF



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 20:38:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24148
	for ; Mon, 26 Mar 2001 20:38:12 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16909;
	Mon, 26 Mar 2001 17:37:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19223;
	Mon, 26 Mar 2001 17:37:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R1aGIm003311
	for ; Mon, 26 Mar 2001 17:36:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R1aFjD003310
	for mobile-ip-dist; Mon, 26 Mar 2001 17:36:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R1a6Im003302
	for ; Mon, 26 Mar 2001 17:36:06 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17153
	for ; Mon, 26 Mar 2001 17:36:06 -0800 (PST)
Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA16004
	for ; Mon, 26 Mar 2001 17:36:05 -0800 (PST)
Received: (cpmta 7102 invoked from network); 26 Mar 2001 17:36:05 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.72) with SMTP; 26 Mar 2001 17:36:05 -0800
X-Sent: 27 Mar 2001 01:36:05 GMT
Message-ID: <001301c0b65e$3d5f2300$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com> <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com> <3ABFBB3C.AC5F6F37@iprg.nokia.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 17:35:42 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


>
> Your suggestion might amount to pulling defeat from the jaws of
> victory.  I am optimistic that we can get a baseline proposal to the
> working group in the very near-term.  Maybe you would be
> willing to take a look at that before giving up?
>

My suggestion might also amount to losing the battle in order to win the
war.

Of course I'm willing to look at a baseline proposal.

I'm not giving up, and I resent that characterization.  Quite the contrary,
I'm thinking about the best and fastest way forward.  I'm seriously
concerned that floating any proposal in an attempt to quickly get to
proposed standard with route optimization is going to hurt us in the long
run.

I suspect we can live without route optimization for a while longer.  I
would like to hear why not.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 21:19:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25306
	for ; Mon, 26 Mar 2001 21:19:34 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24910;
	Mon, 26 Mar 2001 18:18:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13656;
	Mon, 26 Mar 2001 18:18:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R2GsIm003403
	for ; Mon, 26 Mar 2001 18:16:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R2Grmq003401
	for mobile-ip-dist; Mon, 26 Mar 2001 18:16:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R2GQIm003393
	for ; Mon, 26 Mar 2001 18:16:40 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23370
	for ; Mon, 26 Mar 2001 18:16:25 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05237
	for ; Mon, 26 Mar 2001 18:16:25 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA26534;
	Mon, 26 Mar 2001 18:16:24 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2R2GNJ21588;
	Mon, 26 Mar 2001 18:16:23 -0800
X-mProtect:  Mon, 26 Mar 2001 18:16:23 -0800 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdzEngnz; Mon, 26 Mar 2001 18:16:09 PST
Message-ID: <3ABFF7D0.8970392F@iprg.nokia.com>
Date: Mon, 26 Mar 2001 18:15:44 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com> <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com> <3ABFBB3C.AC5F6F37@iprg.nokia.com> <001301c0b65e$3d5f2300$2000a8c0@dellchan>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Paul,

> > Your suggestion might amount to pulling defeat from the jaws of
> > victory.  I am optimistic that we can get a baseline proposal to the
> > working group in the very near-term.  Maybe you would be
> > willing to take a look at that before giving up?
> >
>
> My suggestion might also amount to losing the battle in order to win the
> war.
>
> Of course I'm willing to look at a baseline proposal.

Thanks!

> I'm not giving up, and I resent that characterization.  Quite the contrary,
> I'm thinking about the best and fastest way forward.  I'm seriously
> concerned that floating any proposal in an attempt to quickly get to
> proposed standard with route optimization is going to hurt us in the long
> run.

Well, I guess that this is a good example of how offense can be
taken where none was meant at all.  However, I realize that with
all the upheaval about Mobile IPv6, one could imagine a very long
delay.  My belief is that we can avoid that delay.

Did you see my earlier note to the [mobile-ip] mailing list?  In case
not, I'll repeat myself here:

> I think this is premature.  We have only just recently gotten a clear picture

> about what is needed from the standpoint of the IESG.  The Binding Update
> message is, after all, what the mobile node sends to the Home Agent.
>
> I did, in fact, suggest that we should move forward without specifying
> a method by which the mobile node and correspondent node would
> develop a security association.  That suggestion was denied.  To change
> the specification by eliminating the Binding Update would be very hard,
> and almost pointless since it's needed for the home agent.

Restated in alternate terms, the specification needs Binding Update
already for the home agent, so that has to stay.  Letting correspondent
nodes use it requires that they have a security association, which we
did NOT specify in the base draft.  However, see above.

So the current plan is to build a special purpose key establishment
protocol, which looks doable given the design parameters.

I do not believe that a wholesale rejustification of the basic
protocol is needed. Furthermore (again repeating myself):

You said:

> I suspect we can live without route optimization for a while longer.  I

> would like to hear why not.

In an earlier note, I said:

>  ....   getting the home agent out of the typical routing path, is an
>  important aspect of the scalability of the protocol.

We need to design this for billions of nodes.

Lastly, I promise that I do not intend to be offensive.  If you thought
this was offensive, just consider it a typo or whatever the logical
equivalent would be at the appropriate level of mistakeness.  And
also consider that we've gone this far after waiting through numerous
process delays to get almost done.  Going back to square one isn't
anywhere within the top 10 alternatives as far as I am concerned.

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 23:17:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28435
	for ; Mon, 26 Mar 2001 23:17:50 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07573;
	Mon, 26 Mar 2001 16:32:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05306;
	Mon, 26 Mar 2001 16:32:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R0TNIm003134
	for ; Mon, 26 Mar 2001 16:29:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R0TMfl003133
	for mobile-ip-dist; Mon, 26 Mar 2001 16:29:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R0TDIm003126
	for ; Mon, 26 Mar 2001 16:29:14 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20027
	for ; Mon, 26 Mar 2001 16:29:14 -0800 (PST)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05584
	for ; Mon, 26 Mar 2001 16:29:13 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA29383
	for ; Tue, 27 Mar 2001 00:29:09 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 27 Mar 2001 00:29:09 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 26 Mar 2001 16:29:08 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E890049A2AC6@orsmsx35.jf.intel.com>
From: "Iyer, Prakash" 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Clarifications on RFC2002-bis-04
Date: Mon, 26 Mar 2001 16:29:04 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

I'm looking for some clarifications on this draft.

* The UDP source port for a registration request is specified as variable.
Is there a
restriction against using port 434 as the source port as well.

* The draft does not discuss any DoS attacks. Clearly a mis-behaving MN can
cause
indefinite registration related processing on the FA and HA. It would be
nice if the
FA considerations section could specify mechanisms (if any) to detect this
and not blindly
relay registration requests to the HA 

-Prakash



From owner-mobile-ip@sunroof.eng.sun.com  Mon Mar 26 23:57:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29426
	for ; Mon, 26 Mar 2001 23:57:52 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25584;
	Mon, 26 Mar 2001 20:56:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00466;
	Mon, 26 Mar 2001 20:55:59 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R4sWIm003664
	for ; Mon, 26 Mar 2001 20:54:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R4sVxg003663
	for mobile-ip-dist; Mon, 26 Mar 2001 20:54:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R4sMIm003656
	for ; Mon, 26 Mar 2001 20:54:22 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23986
	for ; Mon, 26 Mar 2001 20:54:21 -0800 (PST)
Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA06837
	for ; Mon, 26 Mar 2001 20:54:21 -0800 (PST)
Received: (cpmta 2828 invoked from network); 26 Mar 2001 20:54:20 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.71) with SMTP; 26 Mar 2001 20:54:20 -0800
X-Sent: 27 Mar 2001 04:54:20 GMT
Message-ID: <001001c0b679$ef921440$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: "Charlie Perkins" 
Cc: 
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM> <15039.34511.324164.457274@thomasm-u1.cisco.com> <021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com> <3ABFBB3C.AC5F6F37@iprg.nokia.com> <001301c0b65e$3d5f2300$2000a8c0@dellchan> <3ABFF7D0.8970392F@iprg.nokia.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 20:53:58 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> Well, I guess that this is a good example of how offense can be
> taken where none was meant at all.  However, I realize that with

Or, a good example of how careless wording can lead to offense.

> all the upheaval about Mobile IPv6, one could imagine a very long
> delay.  My belief is that we can avoid that delay.

Understood.

>
> Did you see my earlier note to the [mobile-ip] mailing list?  In case
> not, I'll repeat myself here:

I did see it.

> >
> > I did, in fact, suggest that we should move forward without specifying
> > a method by which the mobile node and correspondent node would
> > develop a security association.  That suggestion was denied.  To change
> > the specification by eliminating the Binding Update would be very hard,
> > and almost pointless since it's needed for the home agent.

Nobody (as far as I know, certainly not me) ever suggested that we get rid
of the binding update, for the very reason you state.  Only that we consider
separating route optimization from the rest of MIPv6 so that the route
optimization part doesn't continue to delay moving forward with this
critical standard.

>
> So the current plan is to build a special purpose key establishment
> protocol, which looks doable given the design parameters.

Absolutely.  I notice that there does not appear to be concensus of what
those design parameters are.

>
> I do not believe that a wholesale rejustification of the basic
> protocol is needed. Furthermore (again repeating myself):

Wow you are putting a lot of words in my mouth that never came out in the
first place.  I don't think separating off route optimization amounts to a
whole rejustification of the basic protocol.

>
> In an earlier note, I said:
>
> >  ....   getting the home agent out of the typical routing path, is an
> >  important aspect of the scalability of the protocol.

I said I want to hear *why not*.  The above statement is simply a
re-affirmation that you believe route optimization is important.  I have
said it may not be important because in most cases upon power up a mobile
can get a home address from the visited domain and therefore is not very far
from its (adopted) HA.

This is my position, so if you want to explain why this is wrong, you can't
just repeat your base position...you have to justify it.

>
> We need to design this for billions of nodes.

It doesn't matter if you have one node that rarely needs route optimization
or a billion nodes that rarely need route optimization.  Either way route
optimization is rarely needed.

Finally, I'm not exactly saying that we don't need route optimization, just
that moving forward without is a better strategy than risking further delay
of the whole spec.  We absolutely need basic MIPv6 today.  We can optimize
it later when we know how.

Put another way, we have four possibilities:

1. MIPv6 very soon with no route optimization, route optimization later
2. MIPv6 very soon with route optimization
3. MIPv6 delayed with no route optimization
4. MIPv6 delayed with route optimization.

I'm saying that 1 is the safest and most prudent bet right now, even at a
risk of 3.  You are saying that going for 2 is better, even at a risk of 4.
I think 1 is safer and more prudent because I think the probability of 4 is
much higher than the probability of 3.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 01:21:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02646
	for ; Tue, 27 Mar 2001 01:21:51 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11901;
	Mon, 26 Mar 2001 22:19:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA00365;
	Mon, 26 Mar 2001 22:19:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6HxIm004017
	for ; Mon, 26 Mar 2001 22:17:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R6HwgF004016
	for mobile-ip-dist; Mon, 26 Mar 2001 22:17:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6HnIm004009
	for ; Mon, 26 Mar 2001 22:17:49 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA00225
	for ; Mon, 26 Mar 2001 22:17:47 -0800 (PST)
Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA25131
	for ; Mon, 26 Mar 2001 23:17:46 -0700 (MST)
Received: (cpmta 15653 invoked from network); 26 Mar 2001 22:17:45 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.64) with SMTP; 26 Mar 2001 22:17:45 -0800
X-Sent: 27 Mar 2001 06:17:45 GMT
Message-ID: <007301c0b685$938ef8a0$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References: <200103261805.KAA15758@heliopolis.Eng.Sun.COM><15039.34511.324164.457274@thomasm-u1.cisco.com><021f01c0b635$5a4b9a80$6501a8c0@smateo1.sfba.home.com> <15039.43967.633458.666356@thomasm-u1.cisco.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 22:17:18 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Paul Francis writes:
>  > Once assigned a (visited) home address, the mobile can use SIP to
register
>  > its location with its SIP proxy.  For other applications (web
browsing), it
>  > just works as a client as usual.
>
>    How do you deal with in-progress RTP streams? What
>    about their QoS requirements?
>

Whats the problem?

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 01:33:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04129
	for ; Tue, 27 Mar 2001 01:33:33 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18510;
	Mon, 26 Mar 2001 22:32:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03639;
	Mon, 26 Mar 2001 22:32:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6VOIm004067
	for ; Mon, 26 Mar 2001 22:31:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R6VNn3004066
	for mobile-ip-dist; Mon, 26 Mar 2001 22:31:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6VEIm004059
	for ; Mon, 26 Mar 2001 22:31:14 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09812
	for ; Mon, 26 Mar 2001 22:31:13 -0800 (PST)
Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA28104
	for ; Mon, 26 Mar 2001 22:31:13 -0800 (PST)
Received: (cpmta 19900 invoked from network); 26 Mar 2001 22:31:13 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.72) with SMTP; 26 Mar 2001 22:31:13 -0800
X-Sent: 27 Mar 2001 06:31:13 GMT
Message-ID: <007901c0b687$74281d00$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References: <200103262146.f2QLkJX00602@locked.eng.sun.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 22:30:44 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> >
> I don't think this will fly. I think one of the main features is route
> optimization, at least from all disucssions that i have seen.
>

In other words, because everybody before has assumed route optimization is a
main feature, it must be a main feature?

IPv6 has since its inception been under a lot of pressure to be better than
IPv4.  It wasn't enough just to supply more addresses, it had to supply more
features.  So early on things like route optimization were latched onto as
one of the added benefits.  Combine this with the going idea at the time
that we can piggy-back security on top of IPsec, and it makes sense that
route optimization looked like a great thing.  Now, though, it is holding up
basic MIPv6, and it don't look so great any more.


Now that I think about what I'm suggesting, I'm not proposing that we get
rid of route optimization.  I'm proposing a different, slightly less
efficient form of route optimization.

Classic MIPv6 route optimization is to go bypass the HA and go straight to
the CN.

What I'm suggesting instead is putting the HA close to the MN, so that going
through it is not very costly (by getting an HA in the visited domain).  My
form of route optimization will occasionally end up with a long path, if for
instance a mobile goes very far while maintaining a connection.  I'm saying
that this form of route optimization is worth it if it means we can delay
the hard problem of security.

Ok, so the choice is not between route optimization and no route
optimization, it is between "HA bypass route optimization" and "Nearby HA
route optimization".  Doesn't sound so bad now.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 01:45:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05080
	for ; Tue, 27 Mar 2001 01:45:19 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15816;
	Mon, 26 Mar 2001 22:34:24 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02010;
	Mon, 26 Mar 2001 22:34:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6X0Im004077
	for ; Mon, 26 Mar 2001 22:33:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R6WxlM004076
	for mobile-ip-dist; Mon, 26 Mar 2001 22:32:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6WlIm004069
	for ; Mon, 26 Mar 2001 22:32:48 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19805
	for ; Mon, 26 Mar 2001 22:32:46 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04528
	for ; Mon, 26 Mar 2001 23:32:45 -0700 (MST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2R6WiC02311
	for ; Tue, 27 Mar 2001 08:32:44 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 27 08:32:43 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 08:32:42 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCC7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'Samita Chakrabarti'" ,
        mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 ,
        ludovic.bellier@inria.fr, james.kempf@eng.sun.com
Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode
Date: Tue, 27 Mar 2001 08:32:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Samita, 

	Thanks for your thorough review, some comments below.

> Sorry for the late posting... But  most of the comments have been discussed with
> hmipv6 authors in private emails. 
> 
> The comments are based  mostly on hmipv6 version 2 draft.
> Also, I'd like to propose a third mode in hmipv6 especially
> for those systems which do not have ROHC implementation
> at their network.
> 
> Thus this proposed mode will save 40 bytes of tunnel overhead
> between MAP and mobile node in the basic mode. 
> 
	=> It can be used for both modes.

> I understand that
> this would be useful for IPRAN  as James Kempf had pointed out 
> earlier in the list.
> 
	=> Not really, all IP based cellular systems will use ROHC
	or something equivalent. To be more specific 3GPP will
	and I believe 3GPP2 is making (or has made a similar 
	decision). 



> Editorial comments:
> 
> section 3.0 : one or two word description of 'B' flag would be helpful
> 
> section 3.1 : Load-balancing sub-option : needs more clarification as to where the
>               sub-option is sent ( to MAP only or CN as well ?)
>               Load-balancing may be a misnomer, perhaps a more suitable name should
>               be used as this option basically is used by the MN for balancing load
>               over different interfaces. But the load-balancing is dependent on the
>               flow policies. So, how about "Policy" sub-option or other suitable names ?
> 
>               How about changing 'prot number' to 'proto number' ?
>               Needs description for dest-port, r and Destination address, I suppose
>               destination address should be LCOA
> 
>               'P' bit description should clarify which "ip-address" (LCOA?) is used
>                to identify flow.
> 
>                Since checking for flow-label or port-ipaddr pair also involve checking
>                each packet at MAP, 'per-packet' load balancing description is a bit
>                confusing in this context. Since 'per-packet' load-balancing refers to
>                'A' bit only, another beeter name or more clarification required here.
> 
	=> The load balancing will be placed in a separate
	draft that is generic for (H)MIPv6. Your comments will
	be included.
	This was requested by a few people in te WG to reduce 
	the scope of the draft.

> Section 4.0    An example of 'T' bit would help
> 
> Section 5.0    A little more detailed analysis of choices of MAP discovery will be
>                a good guide for implementors and users to pick which one to pick
>                in their implementation/operating environment.
>                
> 
> Section 5.4:   3rd paragraph mentions :
>                "If a MN has access to several ARs.......it's current MAP"
>                an example will be helpful in order to describe this scenario.
> Section 11:    Needs more clarification ( I was told that version 3 has improved texts)
> 
	=> Yes to all the above. For the last one check rev 3.

> Section 15:   Reference for AAAv6 should be recorded.
> 
	=> recorded ? I didn't get that, please explain.

> Technical :
> ----------
>  (Some of the following are discussed with hmipv6 authors)
> 
> Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
>                Next version of draft should also specify possible error codes--
>                at least the 'errors in text form'.
> 
> Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP discovery
>               and specify one or two options as 'MUST' to implement. Otherwise,
>               implementations either will become too complex or will not interoperate.
> 
> Section 6.1 : Please specify that alternate COA sub-option is optional when RCOA is
>               used as source address of the BU. (for location privacy)> 
> 
> Section 11 : This section should also mention that the hierarchical network between
>              MAP and MNs must be a trusted network and no src-address filtering is done
>              on the outging packets from the mobile nodes.
> 
> Section 7.1 and 7.2 :
>               Added operation in HA can be easily avoided if :
>               A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
>               uses for connection.
> 
>               But I think, having HA to add RH in the outer IP layer, has two
>               advantages:
> 
>               1) less signalling between MN and AR ( this is probably desirable by
>                  wirelss vendors)
>       
>               2) Supporting site-local addressed home-addr in the foreign domain.
> 
	=> Ok
>               
> Load Balancing in general:              
> BTW, a detailed load balancing scheme for fault-tolerance for MAP should be schetched
> out so that the backup MAP can takes over when the orginial MAP goes down. Perhaps the
> policy and MAP load babalncing scenarios should be discussed in a separate draft to
> keep this draft simple. But we can toss ideas and discuss more on that in the 
> discussion team.
> 
	=> Yes, this should be done in a separate draft. I'm in the process
	of polishing off a solution for this.

> Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical network where
> ROHC is not available.
> 
> Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels between MAP and MN
>          
> MAP Operation: 
>            In this mode, MAP recives BU and sends BAck after performing DAD operation
>            as described in basic mode. A new bit will be introduced in the MAP advertisement
>            to distinguish "Basic non-tunnel" mode service from other two modes.
> 
>       The new MAP option format ( as per discussion with Hesham Soliman):
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     |  Distance     |  Pref         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Plen      |R|M|T|N|            Reserved                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Valid Lifetime                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                  Global IP Address for MAP                    +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>           N  - Indicates that the MN MUST be able to replace the destination
>                address of incoming packet from LCOA to RCOA when the packets
>                are coming from either a correspondent node or it's home agent.
>                R bit MUST be set when N bit is set. N bit MUST not be set
>                when M is bit is set. Basicaly N bit is an indication of MAP
>                supporting basic-non-tunnel mode.
> 
>            The MAP keeps a binding cache containing association
>            of RCOA, LCOA and MN's home-addr. It intercepts the packets that are destined> 
>            to RCOA (either from HA or from CN. Note that in basic mode RCOA is different
>            from MAP's own address.) MAP then replaces the destination > IP-address RCOA by
>            LCOA after looking up the binding cache, and simply forwards the packet to
>            the topologically correct router in the hierarchy.
> 
> MN Operations:
>          
>            MN forms LCOA and RCOA exactly the same way as described in basic mode. It also
>            sends BU to MAP and home agent subsequently exactly the same way as described
>            in 6.1 (Basic mode MN operations). MN may also send BU to CN informing RCOA as
>            it's new COA ( same as in basic-mode operation).
> 
>            MN receives packets addressed to MN's LCOA address, MN replaces the LCOA address
>            by the corresponding RCOA address after determining that this packet is
>            coming from either it's home agent or correspondent node. MN then proceeds
>            with normal processing of packets as described in base mobile IPv6 draft.
> 
>            The differnce between basic mode MN and basic-non-tunnel mode MN is that
>            the latter, does not need to detunnel the packet from MAP at all. Instead it
>            swaps the destination address of the incoming  packet when the
>            source address is home agent address or  correspondent node address.
>            Thus a mobile node implementation may maintain a list of CNs and
>            Home agents for address verification.
> 
> HA Operation:
>            No change from basic mode operation.
> 
> ----------------------------------------------------------------------------------------
> 
	=> As I mentioned earlier, this would work at a cost of 
	more complexity in the MN. 
	Since, ROHC (or other HC techniques) are used 
	in all "BW-challenged" links, I'm inclined to think
	that this should be placed in a separate draft. 
	As you know several people have mentioned that 
	the draft is doing too much and we're working 
	on that. 
	I believe James' comments was related to context 
	transfer which is handled by seamoby. After 
	reading Mikael Degermark's (co-chair of ROHC) emails 
	I'm now convinced that this would work fine. 

	So to summarise, I think your proposal would 
	work and I (and the rest of the co-authors)
	would be more than happy to assist you in any 
	way if you would like to write another draft that 
	addresses this optimisation for HMIPv6. 

	Finally, I would strongly recommend that you 
	consult with the IPng folks as this solution
	requires some special tricks in the implementation
	and IPng is the best place to get feedback on 
	this.

	We're not saying it's not important,but simply 
	responding to the WG's comments about the 
	size/scope of the draft

	Regards,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 01:46:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05260
	for ; Tue, 27 Mar 2001 01:46:32 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24758;
	Mon, 26 Mar 2001 22:45:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10999;
	Mon, 26 Mar 2001 22:45:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6hiIm004121
	for ; Mon, 26 Mar 2001 22:43:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R6hiDG004120
	for mobile-ip-dist; Mon, 26 Mar 2001 22:43:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6hYIm004113
	for ; Mon, 26 Mar 2001 22:43:35 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21237
	for ; Mon, 26 Mar 2001 22:43:33 -0800 (PST)
Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA02669
	for ; Mon, 26 Mar 2001 22:43:33 -0800 (PST)
Received: (cpmta 25418 invoked from network); 26 Mar 2001 22:43:33 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.65) with SMTP; 26 Mar 2001 22:43:33 -0800
X-Sent: 27 Mar 2001 06:43:33 GMT
Message-ID: <008501c0b689$2d1b1be0$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References: 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 22:43:04 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> (btw, I am assuming that such an editorial change is even possible, and
not
> having read the document, my comments above may be pointless).
>

I'm not sure either.   Actually, there are two possible ways to jettison BUs
between MN and CN:

1.  Just get rid of MN<>CN BUs, but otherwise make no changes.
2.  Both get rid of MN<>CN BUs, and also add the ability to obtain local HAs
in a visited domain as in RFC 7494.  (Either that or some variant of the
Gateway FA or MAP or some such hierarchical/regional scheme that has already
been specified).

The latter is clearly more work, but should in any event not involve
techniques that haven't been discussed at length already.

Anybody care to volunteer to work with me to sketch out both choices 1 and 2
above so that we can better understand what is involved?

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 01:59:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06981
	for ; Tue, 27 Mar 2001 01:59:37 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00548;
	Mon, 26 Mar 2001 22:58:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03930;
	Mon, 26 Mar 2001 22:58:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6ubIm004151
	for ; Mon, 26 Mar 2001 22:56:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R6uapY004150
	for mobile-ip-dist; Mon, 26 Mar 2001 22:56:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R6uSIm004143
	for ; Mon, 26 Mar 2001 22:56:28 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03788
	for ; Mon, 26 Mar 2001 22:56:27 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA29829
	for ; Mon, 26 Mar 2001 22:56:25 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2R6uOC18732
	for ; Tue, 27 Mar 2001 08:56:24 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 27 08:56:23 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 08:52:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: "'paul@francis.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Tue, 27 Mar 2001 08:56:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Paul, 

Good to see you on this list :)
I haven't formed an opinion on either way, but 
it is worth noting that the scenario you mention
is possible/valid and can be supported with HMIPv6 as follows:

1. The MN discovers a MAP as specified in the draft
2. The MN gets an SA with the MAP using the AAA
    infrastructure
3. The MN registers with the MAP
4. The MN uses DynDNS or SIP to register its Home 
    address. 

Which is what you were saying (I think) anyway.

We have some framework draft for key generation
/distribution using the AAA infrastructure

http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt

However, you could argue the opposite also and say that 
the amount of time it would take to get this into a standard 
protocol (the AAA bit) can also be spent into developing a 
key distribution mechanism for the basic spec.
The other disadvantage would be that it won't work if there
is no AAA. 

This is not an ad for the drafts I'm doing but I thought it 
was worth noting the pros and cons

Cheers,
Hesham


> -----Original Message-----
> From:	Paul Francis [SMTP:paul@francis.com]
> Sent:	Tuesday, 27 March 2001 2:54
> To:	Charlie Perkins
> Cc:	mobile-ip@sunroof.eng.sun.com
> Subject:	Re: [mobile-ip] MIPv6 security issues:  how to move forward
> 
> >
> > Well, I guess that this is a good example of how offense can be
> > taken where none was meant at all.  However, I realize that with
> 
> Or, a good example of how careless wording can lead to offense.
> 
> > all the upheaval about Mobile IPv6, one could imagine a very long
> > delay.  My belief is that we can avoid that delay.
> 
> Understood.
> 
> >
> > Did you see my earlier note to the [mobile-ip] mailing list?  In case
> > not, I'll repeat myself here:
> 
> I did see it.
> 
> > >
> > > I did, in fact, suggest that we should move forward without specifying
> > > a method by which the mobile node and correspondent node would
> > > develop a security association.  That suggestion was denied.  To change
> > > the specification by eliminating the Binding Update would be very hard,
> > > and almost pointless since it's needed for the home agent.
> 
> Nobody (as far as I know, certainly not me) ever suggested that we get rid
> of the binding update, for the very reason you state.  Only that we consider
> separating route optimization from the rest of MIPv6 so that the route
> optimization part doesn't continue to delay moving forward with this
> critical standard.
> 
> >
> > So the current plan is to build a special purpose key establishment
> > protocol, which looks doable given the design parameters.
> 
> Absolutely.  I notice that there does not appear to be concensus of what
> those design parameters are.
> 
> >
> > I do not believe that a wholesale rejustification of the basic
> > protocol is needed. Furthermore (again repeating myself):
> 
> Wow you are putting a lot of words in my mouth that never came out in the
> first place.  I don't think separating off route optimization amounts to a
> whole rejustification of the basic protocol.
> 
> >
> > In an earlier note, I said:
> >
> > >  ....   getting the home agent out of the typical routing path, is an
> > >  important aspect of the scalability of the protocol.
> 
> I said I want to hear *why not*.  The above statement is simply a
> re-affirmation that you believe route optimization is important.  I have
> said it may not be important because in most cases upon power up a mobile
> can get a home address from the visited domain and therefore is not very far
> from its (adopted) HA.
> 
> This is my position, so if you want to explain why this is wrong, you can't
> just repeat your base position...you have to justify it.
> 
> >
> > We need to design this for billions of nodes.
> 
> It doesn't matter if you have one node that rarely needs route optimization
> or a billion nodes that rarely need route optimization.  Either way route> 
> optimization is rarely needed.
> 
> Finally, I'm not exactly saying that we don't need route optimization, just
> that moving forward without is a better strategy than risking further delay
> of the whole spec.  We absolutely need basic MIPv6 today.  We can optimize
> it later when we know how.
> 
> Put another way, we have four possibilities:
> 
> 1. MIPv6 very soon with no route optimization, route optimization later
> 2. MIPv6 very soon with route optimization
> 3. MIPv6 delayed with no route optimization
> 4. MIPv6 delayed with route optimization.
> 
> I'm saying that 1 is the safest and most prudent bet right now, even at a
> risk of 3.  You are saying that going for 2 is better, even at a risk of 4.
> I think 1 is safer and more prudent because I think the probability of 4 is
> much higher than the probability of 3.
> 
> PF
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 03:00:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14982
	for ; Tue, 27 Mar 2001 03:00:00 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07135;
	Mon, 26 Mar 2001 23:57:24 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08944;
	Mon, 26 Mar 2001 23:57:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R7thIm004274
	for ; Mon, 26 Mar 2001 23:55:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R7thF4004273
	for mobile-ip-dist; Mon, 26 Mar 2001 23:55:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R7tYIm004266
	for ; Mon, 26 Mar 2001 23:55:34 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27488
	for ; Mon, 26 Mar 2001 23:55:34 -0800 (PST)
Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA17326
	for ; Mon, 26 Mar 2001 23:55:34 -0800 (PST)
Received: (cpmta 10123 invoked from network); 26 Mar 2001 23:55:33 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.71) with SMTP; 26 Mar 2001 23:55:33 -0800
X-Sent: 27 Mar 2001 07:55:33 GMT
Message-ID: <009c01c0b693$407aa0c0$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References:  <3ABFC93F.C87E4EC6@iprg.nokia.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Mon, 26 Mar 2001 23:55:11 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Charlie Perkins" 
To: "Pat Calhoun" 
Cc: 
Sent: Monday, March 26, 2001 2:57 PM
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward


> Hello Pat,
>
>
> > Just to play the Devil's advocate, is mobility important by itself, or
only
> > with route optimization?
>
> "Mobility" is "more important" than "route optimization".  But allowing
> the correspondent node to send packets to a mobile node, and (just as
> important) getting the home agent out of the typical routing path, is an
> important aspect of the scalability of the protocol.

Not if the HA is already in or close to in the normal route the packet would
otherwise take (i.e., "Nearby HA Route Optimization").

>
> I think this is premature.  We have only just recently gotten a clear
picture
> about what is needed from the standpoint of the IESG.  The Binding Update
> message is, after all, what the mobile node sends to the Home Agent.

Though the IESG didn't say so in so many words, my distinct impression was
that the issue is with the security association between MN and CN, not
between MN and HA.  I don't think anyone is suggesting getting rid of the
latter.  I certainly wasn't.  Am I wrong on this?

>
> Again, a good solution is, I think, within reach.
>

I don't know.  The IESG is suggesting a design team.  Sounds like a time
comsuming process.  Also, Pekka's attack classification has like 15 attack
capabilities and 10 attack scenarios.  Presumably this represents a minimum
of the sort of analysis that has to be done on a new scheme.  I just don't
finishing the process of designing another scheme happening any time soon.

Charlie, if we assume that the existing method for establishing SAs and
sending BUs between MN and HA remain the same as now, are you less opposed
to the idea of just dropping the MN<>CN SA and BUs only?

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 03:11:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15079
	for ; Tue, 27 Mar 2001 03:11:41 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11031;
	Tue, 27 Mar 2001 00:10:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17614;
	Tue, 27 Mar 2001 00:09:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R88bIm004378
	for ; Tue, 27 Mar 2001 00:08:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R88aOn004377
	for mobile-ip-dist; Tue, 27 Mar 2001 00:08:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R88RIm004370
	for ; Tue, 27 Mar 2001 00:08:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10505
	for ; Tue, 27 Mar 2001 00:08:28 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02352
	for ; Tue, 27 Mar 2001 01:08:27 -0700 (MST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id KAA01836;
	Tue, 27 Mar 2001 10:08:20 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id KAA06217;
	Tue, 27 Mar 2001 10:07:19 +0200 (MEST)
Message-ID: <3AC04A37.973B221@inrialpes.fr>
Date: Tue, 27 Mar 2001 10:07:19 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'paul@francis.com'" 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------DADAECD747B19BA506DC7E9B"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------DADAECD747B19BA506DC7E9B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello,

An other "short-term" alternative would be to use HMIPv6 with pre-shared keys...
i.e. the MN has pre-shared keys with the MAPs it usually visits (i.e. its MAP at work,
at home, ....).

This would work as follows:
1-The MN discovers a MAP as specified in the HMIPv6 draft
2-if the MN has a pre-shared key with this MAP, it registers with it and registers its
RCoA
with its HA
3-if the MN does not have a pre-shared key it then uses Mobile IPv6 (without RO)

I think this is a pretty good tradeoff ....

regards,

Claude.

"Hesham Soliman (ERA)" wrote:

> Hello Paul,
>
> Good to see you on this list :)
> I haven't formed an opinion on either way, but
> it is worth noting that the scenario you mention
> is possible/valid and can be supported with HMIPv6 as follows:
>
> 1. The MN discovers a MAP as specified in the draft
> 2. The MN gets an SA with the MAP using the AAA
>     infrastructure
> 3. The MN registers with the MAP
> 4. The MN uses DynDNS or SIP to register its Home
>     address.
>
> Which is what you were saying (I think) anyway.
>
> We have some framework draft for key generation
> /distribution using the AAA infrastructure
>
> http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt
>
> However, you could argue the opposite also and say that
> the amount of time it would take to get this into a standard
> protocol (the AAA bit) can also be spent into developing a
> key distribution mechanism for the basic spec.
> The other disadvantage would be that it won't work if there
> is no AAA.
>
> This is not an ad for the drafts I'm doing but I thought it
> was worth noting the pros and cons
>
> Cheers,
> Hesham
>
> > -----Original Message-----
> > From: Paul Francis [SMTP:paul@francis.com]
> > Sent: Tuesday, 27 March 2001 2:54
> > To:   Charlie Perkins
> > Cc:   mobile-ip@sunroof.eng.sun.com
> > Subject:      Re: [mobile-ip] MIPv6 security issues:  how to move forward
> >
> > >
> > > Well, I guess that this is a good example of how offense can be
> > > taken where none was meant at all.  However, I realize that with
> >
> > Or, a good example of how careless wording can lead to offense.
> >
> > > all the upheaval about Mobile IPv6, one could imagine a very long
> > > delay.  My belief is that we can avoid that delay.
> >
> > Understood.
> >
> > >
> > > Did you see my earlier note to the [mobile-ip] mailing list?  In case
> > > not, I'll repeat myself here:
> >
> > I did see it.
> >
> > > >
> > > > I did, in fact, suggest that we should move forward without specifying
> > > > a method by which the mobile node and correspondent node would
> > > > develop a security association.  That suggestion was denied.  To change
> > > > the specification by eliminating the Binding Update would be very hard,
> > > > and almost pointless since it's needed for the home agent.
> >
> > Nobody (as far as I know, certainly not me) ever suggested that we get rid
> > of the binding update, for the very reason you state.  Only that we consider
> > separating route optimization from the rest of MIPv6 so that the route
> > optimization part doesn't continue to delay moving forward with this
> > critical standard.
> >
> > >
> > > So the current plan is to build a special purpose key establishment
> > > protocol, which looks doable given the design parameters.
> >
> > Absolutely.  I notice that there does not appear to be concensus of what
> > those design parameters are.
> >
> > >
> > > I do not believe that a wholesale rejustification of the basic
> > > protocol is needed. Furthermore (again repeating myself):
> >
> > Wow you are putting a lot of words in my mouth that never came out in the
> > first place.  I don't think separating off route optimization amounts to a
> > whole rejustification of the basic protocol.
> >
> > >
> > > In an earlier note, I said:
> > >
> > > >  ....   getting the home agent out of the typical routing path, is an
> > > >  important aspect of the scalability of the protocol.
> >
> > I said I want to hear *why not*.  The above statement is simply a
> > re-affirmation that you believe route optimization is important.  I have
> > said it may not be important because in most cases upon power up a mobile
> > can get a home address from the visited domain and therefore is not very far
> > from its (adopted) HA.
> >
> > This is my position, so if you want to explain why this is wrong, you can't
> > just repeat your base position...you have to justify it.
> >
> > >
> > > We need to design this for billions of nodes.
> >
> > It doesn't matter if you have one node that rarely needs route optimization
> > or a billion nodes that rarely need route optimization.  Either way route>
> > optimization is rarely needed.
> >
> > Finally, I'm not exactly saying that we don't need route optimization, just
> > that moving forward without is a better strategy than risking further delay
> > of the whole spec.  We absolutely need basic MIPv6 today.  We can optimize
> > it later when we know how.
> >
> > Put another way, we have four possibilities:
> >
> > 1. MIPv6 very soon with no route optimization, route optimization later
> > 2. MIPv6 very soon with route optimization
> > 3. MIPv6 delayed with no route optimization
> > 4. MIPv6 delayed with route optimization.
> >
> > I'm saying that 1 is the safest and most prudent bet right now, even at a
> > risk of 3.  You are saying that going for 2 is better, even at a risk of 4.
> > I think 1 is safer and more prudent because I think the probability of 4 is
> > much higher than the probability of 3.
> >
> > PF
> >

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------DADAECD747B19BA506DC7E9B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello,

An other "short-term" alternative would be to use HMIPv6 with pre-shared
keys...

i.e. the MN has pre-shared keys with the MAPs it usually visits
(i.e. its MAP at work, at home, ....).

This would work as follows:

1-The MN discovers a MAP as specified in the HMIPv6 draft

2-if the MN has a pre-shared key with this MAP, it registers with
it and registers its RCoA

with its HA

3-if the MN does not have a pre-shared key it then uses Mobile
IPv6 (without RO)

I think this is a pretty good tradeoff ....

regards,

Claude.

"Hesham Soliman (ERA)" wrote:

Hello Paul,

Good to see you on this list :)

I haven't formed an opinion on either way, but

it is worth noting that the scenario you mention

is possible/valid and can be supported with HMIPv6 as follows:

1. The MN discovers a MAP as specified in the draft

2. The MN gets an SA with the MAP using the AAA

    infrastructure

3. The MN registers with the MAP

4. The MN uses DynDNS or SIP to register its Home

    address.

Which is what you were saying (I think) anyway.

We have some framework draft for key generation

/distribution using the AAA infrastructure

http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt

However, you could argue the opposite also and say that

the amount of time it would take to get this into a standard

protocol (the AAA bit) can also be spent into developing a

key distribution mechanism for the basic spec.

The other disadvantage would be that it won't work if there

is no AAA.

This is not an ad for the drafts I'm doing but I thought it

was worth noting the pros and cons

Cheers,

Hesham

> -----Original Message-----

> From: Paul Francis [SMTP:paul@francis.com]

> Sent: Tuesday, 27 March 2001 2:54

> To:   Charlie Perkins

> Cc:   mobile-ip@sunroof.eng.sun.com

> Subject:      Re: [mobile-ip] MIPv6 security
issues:  how to move forward

>

> >

> > Well, I guess that this is a good example of how offense can be

> > taken where none was meant at all.  However, I realize that
with

>

> Or, a good example of how careless wording can lead to offense.

>

> > all the upheaval about Mobile IPv6, one could imagine a very long

> > delay.  My belief is that we can avoid that delay.

>

> Understood.

>

> >

> > Did you see my earlier note to the [mobile-ip] mailing list? 
In case

> > not, I'll repeat myself here:

>

> I did see it.

>

> > >

> > > I did, in fact, suggest that we should move forward without specifying

> > > a method by which the mobile node and correspondent node would

> > > develop a security association.  That suggestion was denied. 
To change

> > > the specification by eliminating the Binding Update would be
very hard,

> > > and almost pointless since it's needed for the home agent.

>

> Nobody (as far as I know, certainly not me) ever suggested that we
get rid

> of the binding update, for the very reason you state.  Only
that we consider

> separating route optimization from the rest of MIPv6 so that the
route

> optimization part doesn't continue to delay moving forward with this

> critical standard.

>

> >

> > So the current plan is to build a special purpose key establishment

> > protocol, which looks doable given the design parameters.

>

> Absolutely.  I notice that there does not appear to be concensus
of what

> those design parameters are.

>

> >

> > I do not believe that a wholesale rejustification of the basic

> > protocol is needed. Furthermore (again repeating myself):

>

> Wow you are putting a lot of words in my mouth that never came out
in the

> first place.  I don't think separating off route optimization
amounts to a

> whole rejustification of the basic protocol.

>

> >

> > In an earlier note, I said:

> >

> > >  ....   getting the home agent out of the typical
routing path, is an

> > >  important aspect of the scalability of the protocol.

>

> I said I want to hear *why not*.  The above statement is simply
a

> re-affirmation that you believe route optimization is important. 
I have

> said it may not be important because in most cases upon power up
a mobile

> can get a home address from the visited domain and therefore is not
very far

> from its (adopted) HA.

>

> This is my position, so if you want to explain why this is wrong,
you can't

> just repeat your base position...you have to justify it.

>

> >

> > We need to design this for billions of nodes.

>

> It doesn't matter if you have one node that rarely needs route optimization

> or a billion nodes that rarely need route optimization.  Either
way route>

> optimization is rarely needed.

>

> Finally, I'm not exactly saying that we don't need route optimization,
just

> that moving forward without is a better strategy than risking further
delay

> of the whole spec.  We absolutely need basic MIPv6 today. 
We can optimize

> it later when we know how.

>

> Put another way, we have four possibilities:

>

> 1. MIPv6 very soon with no route optimization, route optimization
later

> 2. MIPv6 very soon with route optimization

> 3. MIPv6 delayed with no route optimization

> 4. MIPv6 delayed with route optimization.

>

> I'm saying that 1 is the safest and most prudent bet right now, even
at a

> risk of 3.  You are saying that going for 2 is better, even
at a risk of 4.

> I think 1 is safer and more prudent because I think the probability
of 4 is

> much higher than the probability of 3.

>

> PF

>



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------DADAECD747B19BA506DC7E9B--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 03:38:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15303
	for ; Tue, 27 Mar 2001 03:38:45 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20826;
	Tue, 27 Mar 2001 00:36:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19845;
	Tue, 27 Mar 2001 00:36:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R8Z7Im004454
	for ; Tue, 27 Mar 2001 00:35:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R8Z6h8004453
	for mobile-ip-dist; Tue, 27 Mar 2001 00:35:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R8YvIm004446
	for ; Tue, 27 Mar 2001 00:34:57 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01258;
	Tue, 27 Mar 2001 00:34:53 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19931;
	Tue, 27 Mar 2001 00:34:52 -0800 (PST)
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id KAA02466;
	Tue, 27 Mar 2001 10:34:50 +0200 (MET DST)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.9.3+Sun/8.8.5) with ESMTP id KAA06226;
	Tue, 27 Mar 2001 10:33:49 +0200 (MEST)
Message-ID: <3AC0506D.177FD06B@inrialpes.fr>
Date: Tue, 27 Mar 2001 10:33:49 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Samita Chakrabarti 
CC: Hesham.Soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com,
        claude.castelluccia@inria.fr, Karim.El-Malki@era.ericsson.se,
        james.kempf@eng.sun.com
Subject: [mobile-ip] Re: Comments on hmipv6 draft and a proposal on a third mode
References: <200103261855.f2QItVxf148753@jurassic.eng.sun.com>
Content-Type: multipart/alternative;
 boundary="------------D8A97A3B1B68D164CF9F8C50"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------D8A97A3B1B68D164CF9F8C50
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello Samita and thanks a lot for your comments concerning HMIPv6.

We'll take your comments into consideration for the next version of the draft
(some of them are already integrated in the 03 version...
(http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt)

Concerning the third mode proposal, i have 3 comments:

-in the basic mode, the MAP is nothing more that a HA.  This was one of our requirements
when designing this mode. The basic mode is very simple to implement... adding the
fonctionality
you are proposing would require to modify the MAP and we won't be able to use a HA as MAP
anymore...

-in your proposal, the MAP modifies the destination address of the packets that are sent to a
Mobile host.
What will happen if the packet is authenticated with AH? The packets will be rejected by the
MN. This
is an issue when the CN is also mobile and piggybacks  its BUs with its packets (the whole
packets must then be
authenticated with AH) ...

- Most of wireless networks will use RoHC (as confirmed by Hesham email) so I don't see the
motivation
for this 3rd mode (considering the 2 previous issues).

Thanks again for your comments,

regards,

Claude.




Samita Chakrabarti wrote:

> Hello:
>
> Sorry for the late posting... But  most of the comments have been discussed with
> hmipv6 authors in private emails.
>
> The comments are based  mostly on hmipv6 version 2 draft.
> Also, I'd like to propose a third mode in hmipv6 especially
> for those systems which do not have ROHC implementation
> at their network.
> Thus this proposed mode will save 40 bytes of tunnel overhead
> between MAP and mobile node in the basic mode. I understand that
> this would be useful for IPRAN  as James Kempf had pointed out
> earlier in the list.
>
> Editorial comments:
>
> section 3.0 : one or two word description of 'B' flag would be helpful
>
> section 3.1 : Load-balancing sub-option : needs more clarification as to where the
>               sub-option is sent ( to MAP only or CN as well ?)
>               Load-balancing may be a misnomer, perhaps a more suitable name should
>               be used as this option basically is used by the MN for balancing load
>               over different interfaces. But the load-balancing is dependent on the
>               flow policies. So, how about "Policy" sub-option or other suitable names ?
>
>               How about changing 'prot number' to 'proto number' ?
>               Needs description for dest-port, r and Destination address, I suppose
>               destination address should be LCOA
>
>               'P' bit description should clarify which "ip-address" (LCOA?) is used
>                to identify flow.
>
>                Since checking for flow-label or port-ipaddr pair also involve checking
>                each packet at MAP, 'per-packet' load balancing description is a bit
>                confusing in this context. Since 'per-packet' load-balancing refers to
>                'A' bit only, another beeter name or more clarification required here.
>
> Section 4.0    An example of 'T' bit would help
>
> Section 5.0    A little more detailed analysis of choices of MAP discovery will be
>                a good guide for implementors and users to pick which one to pick
>                in their implementation/operating environment.
>
>
> Section 5.4:   3rd paragraph mentions :
>                "If a MN has access to several ARs.......it's current MAP"
>                an example will be helpful in order to describe this scenario.
> Section 11:    Needs more clarification ( I was told that version 3 has improved texts)
>
> Section 15:   Reference for AAAv6 should be recorded.
>
> Technical :
> ----------
>  (Some of the following are discussed with hmipv6 authors)
>
> Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
>                Next version of draft should also specify possible error codes--
>                at least the 'errors in text form'.
>
> Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP discovery
>               and specify one or two options as 'MUST' to implement. Otherwise,
>               implementations either will become too complex or will not interoperate.
>
> Section 6.1 : Please specify that alternate COA sub-option is optional when RCOA is
>               used as source address of the BU. (for location privacy)
>
> Section 11 : This section should also mention that the hierarchical network between
>              MAP and MNs must be a trusted network and no src-address filtering is done
>              on the outging packets from the mobile nodes.
>
> Section 7.1 and 7.2 :
>               Added operation in HA can be easily avoided if :
>               A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
>               uses for connection.
>
>               But I think, having HA to add RH in the outer IP layer, has two
>               advantages:
>
>               1) less signalling between MN and AR ( this is probably desirable by
>                  wirelss vendors)
>
>               2) Supporting site-local addressed home-addr in the foreign domain.
>
> Load Balancing in general:
> BTW, a detailed load balancing scheme for fault-tolerance for MAP should be schetched
> out so that the backup MAP can takes over when the orginial MAP goes down. Perhaps the
> policy and MAP load babalncing scenarios should be discussed in a separate draft to
> keep this draft simple. But we can toss ideas and discuss more on that in the
> discussion team.
>
> Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical network where
> ROHC is not available.
>
> Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels between MAP and MN
>
> MAP Operation:
>            In this mode, MAP recives BU and sends BAck after performing DAD operation
>            as described in basic mode. A new bit will be introduced in the MAP advertisement
>            to distinguish "Basic non-tunnel" mode service from other two modes.
>
>       The new MAP option format ( as per discussion with Hesham Soliman):
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     |  Distance     |  Pref         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Plen      |R|M|T|N|            Reserved                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Valid Lifetime                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                  Global IP Address for MAP                    +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>           N  - Indicates that the MN MUST be able to replace the destination
>                address of incoming packet from LCOA to RCOA when the packets
>                are coming from either a correspondent node or it's home agent.
>                R bit MUST be set when N bit is set. N bit MUST not be set
>                when M is bit is set. Basicaly N bit is an indication of MAP
>                supporting basic-non-tunnel mode.
>
>            The MAP keeps a binding cache containing association
>            of RCOA, LCOA and MN's home-addr. It intercepts the packets that are destined
>            to RCOA (either from HA or from CN. Note that in basic mode RCOA is different
>            from MAP's own address.) MAP then replaces the destination IP-address RCOA by
>            LCOA after looking up the binding cache, and simply forwards the packet to
>            the topologically correct router in the hierarchy.
>
> MN Operations:
>
>            MN forms LCOA and RCOA exactly the same way as described in basic mode. It also
>            sends BU to MAP and home agent subsequently exactly the same way as described
>            in 6.1 (Basic mode MN operations). MN may also send BU to CN informing RCOA as
>            it's new COA ( same as in basic-mode operation).
>
>            MN receives packets addressed to MN's LCOA address, MN replaces the LCOA address
>            by the corresponding RCOA address after determining that this packet is
>            coming from either it's home agent or correspondent node. MN then proceeds
>            with normal processing of packets as described in base mobile IPv6 draft.
>
>            The differnce between basic mode MN and basic-non-tunnel mode MN is that
>            the latter, does not need to detunnel the packet from MAP at all. Instead it
>            swaps the destination address of the incoming  packet when the
>            source address is home agent address or  correspondent node address.
>            Thus a mobile node implementation may maintain a list of CNs and
>            Home agents for address verification.
>
> HA Operation:
>            No change from basic mode operation.
>
> ----------------------------------------------------------------------------------------
>
> Thanks,
> -Samita

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------D8A97A3B1B68D164CF9F8C50
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello Samita and thanks a lot for your comments concerning HMIPv6.

We'll take your comments into consideration for the next version of
the draft

(some of them are already integrated in the 03 version... (http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt)

Concerning the third mode proposal, i have 3 comments:

-in the basic mode, the MAP is nothing more that a HA.  This
was one of our requirements

when designing this mode. The basic mode is very simple to implement...
adding the fonctionality

you are proposing would require to modify the MAP and we won't be able
to use a HA as MAP anymore...

-in your proposal, the MAP modifies the destination address of the packets
that are sent to a Mobile host.

What will happen if the packet is authenticated with AH? The packets
will be rejected by the MN. This

is an issue when the CN is also mobile and piggybacks  its
BUs with its packets (the whole packets must then be

authenticated with AH) ...

- Most of wireless networks will use RoHC (as confirmed by Hesham email)
so I don't see the motivation

for this 3rd mode (considering the 2 previous issues).

Thanks again for your comments,

regards,

Claude.

 

 

 

Samita Chakrabarti wrote:

Hello:

Sorry for the late posting... But  most of the comments have been
discussed with

hmipv6 authors in private emails.

The comments are based  mostly on hmipv6 version 2 draft.

Also, I'd like to propose a third mode in hmipv6 especially

for those systems which do not have ROHC implementation

at their network.

Thus this proposed mode will save 40 bytes of tunnel overhead

between MAP and mobile node in the basic mode. I understand that

this would be useful for IPRAN  as James Kempf had pointed out

earlier in the list.

Editorial comments:

section 3.0 : one or two word description of 'B' flag would be helpful

section 3.1 : Load-balancing sub-option : needs more clarification as
to where the

             
sub-option is sent ( to MAP only or CN as well ?)

             
Load-balancing may be a misnomer, perhaps a more suitable name should

             
be used as this option basically is used by the MN for balancing load

             
over different interfaces. But the load-balancing is dependent on the

             
flow policies. So, how about "Policy" sub-option or other suitable names
?

             
How about changing 'prot number' to 'proto number' ?

             
Needs description for dest-port, r and Destination address, I suppose

             
destination address should be LCOA

             
'P' bit description should clarify which "ip-address" (LCOA?) is used

              
to identify flow.

              
Since checking for flow-label or port-ipaddr pair also involve checking

              
each packet at MAP, 'per-packet' load balancing description is a bit

              
confusing in this context. Since 'per-packet' load-balancing refers to

              
'A' bit only, another beeter name or more clarification required here.

Section 4.0    An example of 'T' bit would help

Section 5.0    A little more detailed analysis of choices
of MAP discovery will be

              
a good guide for implementors and users to pick which one to pick

              
in their implementation/operating environment.

 

Section 5.4:   3rd paragraph mentions :

              
"If a MN has access to several ARs.......it's current MAP"

              
an example will be helpful in order to describe this scenario.

Section 11:    Needs more clarification ( I was told
that version 3 has improved texts)

Section 15:   Reference for AAAv6 should be recorded.

Technical :

----------

 (Some of the following are discussed with hmipv6 authors)

Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future
use ?

              
Next version of draft should also specify possible error codes--

              
at least the 'errors in text form'.

Section 5  :  For simplicity, hmipv6 draft should limit the
choices of MAP discovery

             
and specify one or two options as 'MUST' to implement. Otherwise,

             
implementations either will become too complex or will not interoperate.

Section 6.1 : Please specify that alternate COA sub-option is optional
when RCOA is

             
used as source address of the BU. (for location privacy)

Section 11 : This section should also mention that the hierarchical
network between

            
MAP and MNs must be a trusted network and no src-address filtering is done

            
on the outging packets from the mobile nodes.

Section 7.1 and 7.2 :

             
Added operation in HA can be easily avoided if :

             
A MN MUST (instead of SHOULD) send a BU for each different Home-addr it

             
uses for connection.

             
But I think, having HA to add RH in the outer IP layer, has two

             
advantages:

             
1) less signalling between MN and AR ( this is probably desirable by

                
wirelss vendors)

             
2) Supporting site-local addressed home-addr in the foreign domain.

Load Balancing in general:

BTW, a detailed load balancing scheme for fault-tolerance for MAP should
be schetched

out so that the backup MAP can takes over when the orginial MAP goes
down. Perhaps the

policy and MAP load babalncing scenarios should be discussed in a separate
draft to

keep this draft simple. But we can toss ideas and discuss more on that
in the

discussion team.

Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical
network where

ROHC is not available.

Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels
between MAP and MN

MAP Operation:

           In this
mode, MAP recives BU and sends BAck after performing DAD operation

           as described
in basic mode. A new bit will be introduced in the MAP advertisement

           to distinguish
"Basic non-tunnel" mode service from other two modes.

      The new MAP option format ( as per discussion
with Hesham Soliman):

      0                  
1                  
2                  
3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |     Type     
|    Length     |  Distance    
|  Pref         |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |     Plen     
|R|M|T|N|           
Reserved                  
|

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                        
Valid Lifetime                       
|

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                                                              
|

      +                                                              
+

      |                                                              
|

      +                 
Global IP Address for MAP                   
+

      |                                                              
|

      +                                                              
+

      |                                                              
|

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          N  - Indicates
that the MN MUST be able to replace the destination

              
address of incoming packet from LCOA to RCOA when the packets

              
are coming from either a correspondent node or it's home agent.

              
R bit MUST be set when N bit is set. N bit MUST not be set

              
when M is bit is set. Basicaly N bit is an indication of MAP

              
supporting basic-non-tunnel mode.

           The MAP
keeps a binding cache containing association

           of RCOA,
LCOA and MN's home-addr. It intercepts the packets that are destined

           to RCOA
(either from HA or from CN. Note that in basic mode RCOA is different

           from MAP's
own address.) MAP then replaces the destination IP-address RCOA by

           LCOA after
looking up the binding cache, and simply forwards the packet to

           the topologically
correct router in the hierarchy.

MN Operations:

           MN forms
LCOA and RCOA exactly the same way as described in basic mode. It also

           sends
BU to MAP and home agent subsequently exactly the same way as described

           in 6.1
(Basic mode MN operations). MN may also send BU to CN informing RCOA as

           it's new
COA ( same as in basic-mode operation).

           MN receives
packets addressed to MN's LCOA address, MN replaces the LCOA address

           by the
corresponding RCOA address after determining that this packet is

           coming
from either it's home agent or correspondent node. MN then proceeds

           with normal
processing of packets as described in base mobile IPv6 draft.

           The differnce
between basic mode MN and basic-non-tunnel mode MN is that

           the latter,
does not need to detunnel the packet from MAP at all. Instead it

           swaps
the destination address of the incoming  packet when the

           source
address is home agent address or  correspondent node address.

           Thus a
mobile node implementation may maintain a list of CNs and

           Home agents
for address verification.

HA Operation:

           No change
from basic mode operation.

----------------------------------------------------------------------------------------

Thanks,

-Samita



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------D8A97A3B1B68D164CF9F8C50--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 04:21:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15639
	for ; Tue, 27 Mar 2001 04:21:35 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16857;
	Tue, 27 Mar 2001 01:20:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23944;
	Tue, 27 Mar 2001 01:20:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9JCIm004560
	for ; Tue, 27 Mar 2001 01:19:12 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R9JBAX004559
	for mobile-ip-dist; Tue, 27 Mar 2001 01:19:11 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9J1Im004552
	for ; Tue, 27 Mar 2001 01:19:01 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20683;
	Tue, 27 Mar 2001 01:19:01 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02327;
	Tue, 27 Mar 2001 01:19:00 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2R9Iwd50841;
	Tue, 27 Mar 2001 10:18:58 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA08815;
	Tue, 27 Mar 2001 11:18:57 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2R9IuA76050;
	Tue, 27 Mar 2001 11:18:56 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103270918.f2R9IuA76050@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: Mohan Parthasarathy 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Mon, 26 Mar 2001 21:19:17 +0300.
             <3ABF8825.8E51BE6E@nomadiclab.com> 
Date: Tue, 27 Mar 2001 11:18:56 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   By the way, if somebody has good numbers about the typical memory
   print of an AH or ESP SA, it would be very interesting to see them.
   
=> because of its sparse usage I believe the problem is more in the
creation/lookup/cleanup price in CPU cycles than in the memory print,
ie. we should get something similar to a lot of short TCP connections
with the 2MSL time wait replaced by medium lifetime (short lifetimes
will cost to much in IKE, long lifetime are not very secure and can give
very large tables... IPsec SA lifetimes are not easy to deal with for
this kind of applications).

Regards

Francis.Dupont@enst-bretagne.fr

PS: in fact the ISAKMP SA lifetime should be large in order to pay
only a phase 2 when the IPsec SA pair must be rebuilt but this works
only when the MN/initiator can use its home address in phase 1, ie.
this doesn't work at least with the home agent (a dedicated mechanism
will be able to benefit from the two addresses contrary to IKE).


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 04:43:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15972
	for ; Tue, 27 Mar 2001 04:43:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA11048;
	Tue, 27 Mar 2001 01:42:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06896;
	Tue, 27 Mar 2001 01:41:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9dxIm004596
	for ; Tue, 27 Mar 2001 01:39:59 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R9dw98004595
	for mobile-ip-dist; Tue, 27 Mar 2001 01:39:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9dnIm004588
	for ; Tue, 27 Mar 2001 01:39:50 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06688
	for ; Tue, 27 Mar 2001 01:39:49 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09559
	for ; Tue, 27 Mar 2001 01:39:48 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2R9dkd24476;
	Tue, 27 Mar 2001 10:39:46 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA09404;
	Tue, 27 Mar 2001 11:39:40 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2R9ddA76136;
	Tue, 27 Mar 2001 11:39:39 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103270939.f2R9ddA76136@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: Pekka Nikander 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Mon, 26 Mar 2001 10:47:12 -0800.
             <200103261847.f2QIlCl00511@locked.eng.sun.com> 
Date: Tue, 27 Mar 2001 11:39:39 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   We need to define what lighter protocol is ? Less secure (this needs
   to be broken down further e.g. Is man in the middle attack ok ?
   Is DoS attack ok ?),

=> there are minimal requirements but I believe we should do our best.

   fewer roundtrips, less computational overhead
   etc. This is the draft i was mentioning earlier at the IETF :
   
   draft-snoeren-tcp-migrate-00.txt
   
=> in my hands...

   which essentially does a diffie-hellman exchange and establishes
   a shared secret. When the connection needs to be migrated, it
   provides a token (HMAC of sequence numbers etc.). A similar one
   can be done here. I think there is no authentication in this.
   We can get it by routing packets through Home Agent if we feel
   that it is sufficient.
   
=> we can do something better: send a part of needed things directly
to the care-of address and the remainder to the home address (through
the home agent) so the MN will need to get the traffic from both paths
(and the MITM will need to intercept the traffic on both paths).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 04:43:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16001
	for ; Tue, 27 Mar 2001 04:43:56 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA11288;
	Tue, 27 Mar 2001 01:42:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19904;
	Tue, 27 Mar 2001 01:42:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9fYIm004606
	for ; Tue, 27 Mar 2001 01:41:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2R9fXqE004605
	for mobile-ip-dist; Tue, 27 Mar 2001 01:41:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2R9fNIm004598
	for ; Tue, 27 Mar 2001 01:41:23 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06859
	for ; Tue, 27 Mar 2001 01:41:22 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA10233
	for ; Tue, 27 Mar 2001 01:41:22 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA17334
	for ; Tue, 27 Mar 2001 01:41:21 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2R9fJr12203
	for ; Tue, 27 Mar 2001 01:41:19 -0800
X-mProtect:  Tue, 27 Mar 2001 01:41:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdjUBG7I; Tue, 27 Mar 2001 01:41:12 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id BAA37791 for ; Tue, 27 Mar 2001 01:41:14 -0800 (PST)
Message-ID: <3AC0603A.46907B5F@iprg.nokia.com>
Date: Tue, 27 Mar 2001 01:41:14 -0800
From: "Jari T. Malinen" 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
References: <034BEFD03799D411A59F00508BDF7546013DBCB8@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

Sorry for late response due to mail problems..

> > I believe we are not overriding routing protocols any more than you
> > are, once we compare with your extended mode.
> >
>         => ??? I don't get that. Multi-level hierarchy forces packets
>         into a fixed route between levels. I don't know what you mean ??
>         Extended mode != multi-level hierarchy.

It seems to resemble a multi-level hierarchy, at least for packets
going to previous MAP address or when using nested mobile routers.

In extended mode MN is dislocated as compared to both the fixed and
mobile MAP. The mobile node needs to let the lower MAP to know how
to route packets to MN. Consider packets coming from CN to old RCoA
(CoA registered with CN before MN can register new CoA after lower
MAP moved). The packets get re-routed from HA of the mobile MAP to
wherever the mobile MAP moved, taking them to the higher MAP since
this should hold the RCoA for the lower MAP. It will consume the
routing header of a route-optimized packet. Now the packet's destination
address will be home address of the MN in the mobile network.
Could you clarify routing to this address, re-capsulation through
lower MAP or perhaps by host-based routing?

A second case to consider is when MN can recursively be a mobile
router. There is a need for a host-routing protocol or recapsulating
tunneling to navigate packets through nested mobile networks.
Using MAP as the connection point of mobile networks looks essential
to the method of getting packets to these nested networks thus fixing 
packets to pass MAPs.

> > > > Better optimization of last hop bandwidth usage, network-controlled
> > > > load balancing (your scheme has hop count and priority in a MAP
> > > > option, these trust MN does something it may not be designed to
> > > > do and require more than one MAP options to make a choice even
> > > > possible).
> > > >
> > >         => Are you referring to the MAP option ?
> > >         I hope this is not the BW argument. This argument is
> > >         not valid IMO. RAs are designed to have several
> > >         options regardless of the use of MIP. I hope we can agree on that.
> >
> > We can still try to reduce the size of the RA, i.e. number of extensions
> > needed for a load-balancing network.
> >
>         => Jari, have you read the draft ? What load balancing
>         extensions are you referring to ? The load balancig described
>         in the draft is something else. Have a look at rev 2 or 3.

You introduce load balancing in the most recent draft in a different role,
let me re-phrase my word load-balancing as signaling load balancing.

Considering RA size in IPv6 and cost of last mile bandwidth it is
in our requirements advisable trying to avoid extending it further.
If we can do with one extension and still distribute signaling load,
it extends scalability the bigger the visited domain.

>         regards,
>         Hesham

Best Regards,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 05:05:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16184
	for ; Tue, 27 Mar 2001 05:05:07 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12165;
	Tue, 27 Mar 2001 02:02:29 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24509;
	Tue, 27 Mar 2001 02:02:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA15Im004667
	for ; Tue, 27 Mar 2001 02:01:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RA14L4004666
	for mobile-ip-dist; Tue, 27 Mar 2001 02:01:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA0sIm004658
	for ; Tue, 27 Mar 2001 02:00:55 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21459
	for ; Tue, 27 Mar 2001 02:00:54 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02584
	for ; Tue, 27 Mar 2001 03:00:53 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RA0qd29351
	for ; Tue, 27 Mar 2001 11:00:52 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA10019
	for ; Tue, 27 Mar 2001 12:00:51 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RA0pA76237
	for ; Tue, 27 Mar 2001 12:00:51 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271000.f2RA0pA76237@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-reply-to: Your message of Mon, 26 Mar 2001 11:24:18 -0800.
             <15039.38754.398599.433366@thomasm-u1.cisco.com> 
Date: Tue, 27 Mar 2001 12:00:51 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

      I'm not a huge IKE fan, but I do know that the
      cable MSO's are using Kerberos to key SA's for
      MGCP/SIP, and that there's a real working group
      to really standardize Kerberized IPsec in IETF.

=> I'd prefer to have more general trusted third party but
this has at least open the door.

      Using (or not) AAA for a similar general
      purpose keying mechanism really should not be
      done piece meal, and *especially* from MIP WG. 
      If people think that AAA is a good way to key
      SA's, we ought to have a BOF and a real WG to
      set the charter and requirements. As it is
      right, now using AAA to key SA's is an
      amorphous requirementless free for all. Since
      it's a security protocol, that should frighten
      everybody.
   
=> I don't understand your overcautiousness... The security
problems of mobile IPv6 are authentication / authorization
and AAA is supposed to provide them (in a different context).
There are some cases where AAA is clearly a good solution when
it is already available, for instance when a mobile node boots
in a visited network using AAA for its access control (the
local/visited AAA server will contact the home/remote AAA server
giving a timelineness to key SA's using the AAAH as a trusted
third party). Of course mobile IPv6 should not rely on AAA.

Regards

Francis.Dupont@enst-bretagne.fr

PS: there were already some discussions about AAA and mobility in
the intersection of AAA and mobile ip WGs, and some I-Ds.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 05:07:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16238
	for ; Tue, 27 Mar 2001 05:07:47 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14130;
	Tue, 27 Mar 2001 02:05:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21876;
	Tue, 27 Mar 2001 02:05:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA4DIm004701
	for ; Tue, 27 Mar 2001 02:04:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RA4DWK004700
	for mobile-ip-dist; Tue, 27 Mar 2001 02:04:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RA3xIm004686
	for ; Tue, 27 Mar 2001 02:03:59 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08806
	for ; Tue, 27 Mar 2001 02:03:59 -0800 (PST)
Received: from mercury (mercury.ukc.ac.uk [129.12.21.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20590
	for ; Tue, 27 Mar 2001 02:03:57 -0800 (PST)
Received: from pelican.ukc.ac.uk ([129.12.200.26])
	by mercury with esmtp (Exim 3.16 #1)
	id 14hqKM-0003dW-00; Tue, 27 Mar 2001 11:03:51 +0100
Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk)
	by pelican.ukc.ac.uk with esmtp (Exim 1.92 #1)
	id 14hqKT-0001z3-00; Tue, 27 Mar 2001 11:03:57 +0100
Message-ID: <3AC0658C.AD417668@ukc.ac.uk>
Date: Tue, 27 Mar 2001 11:03:56 +0100
From: Kumarendra Sivarajah 
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile IP TestBed
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello,
Does anyone knows if there are any companies that sells ready made
equipments that support mobile IP. This is because I am interested to
implement a mobile IP testbed and looking at purchasing equipment that
are useful for my research.
Thank you
INdran

--

#################################################
Kumarendra Sivarajah (INdran)
Electronics Engineering Laboratory
University of Kent at Canterbury
Canterbury, Kent CT2 7NT
United Kingdom
Telephone(Office): +44 (0)1227 823257
Telephone(Mobile): +44 (0)7765 007016
Fax: +44 (0)7902 181526
#################################################




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 05:30:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16432
	for ; Tue, 27 Mar 2001 05:30:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25316;
	Tue, 27 Mar 2001 02:28:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26318;
	Tue, 27 Mar 2001 02:28:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RAQgIm004754
	for ; Tue, 27 Mar 2001 02:26:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RAQgxY004753
	for mobile-ip-dist; Tue, 27 Mar 2001 02:26:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RAQXIm004746
	for ; Tue, 27 Mar 2001 02:26:33 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10418
	for ; Tue, 27 Mar 2001 02:26:32 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28625
	for ; Tue, 27 Mar 2001 02:26:31 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RAQUd19339;
	Tue, 27 Mar 2001 11:26:30 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA10741;
	Tue, 27 Mar 2001 12:26:29 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RAQSA76422;
	Tue, 27 Mar 2001 12:26:28 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271026.f2RAQSA76422@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: Paul Francis 
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Mon, 26 Mar 2001 13:57:16 -0800.
             <3ABFBB3C.AC5F6F37@iprg.nokia.com> 
Date: Tue, 27 Mar 2001 12:26:28 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Your suggestion might amount to pulling defeat from the jaws of
   victory.  I am optimistic that we can get a baseline proposal to the
   working group in the very near-term.  Maybe you would be
   willing to take a look at that before giving up?
   
=> I agree but we should add unoptimized/paranoid modes in the current
mobile IPv6:
 - make sending of BUs to new CNs explicitely optional (ie. the last
   SHOULD of page 88 is a bit too strong)
 - add a bidir HA-MN tunnel mode (ie. "reverse tunnel" mode for
   superparanoid visited networks)
But these should be marked as degraded modes of operation, not as basic
modes which can be optionally optimized.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: local home agents still need a good security (ie. strong authentication),
this is a place where an improved AAA can help (ie. not only get the
authorization to use a local address, but get the authorization to use
it as a home address in the near future).
PPS: about section 10.8, a statement about policy in the page 88-89 list
should be enough.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 05:36:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16506
	for ; Tue, 27 Mar 2001 05:36:23 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28118;
	Tue, 27 Mar 2001 02:35:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11030;
	Tue, 27 Mar 2001 02:35:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RAXqIm004788
	for ; Tue, 27 Mar 2001 02:33:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RAXqHE004787
	for mobile-ip-dist; Tue, 27 Mar 2001 02:33:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RAXgIm004780
	for ; Tue, 27 Mar 2001 02:33:42 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00266
	for ; Tue, 27 Mar 2001 02:33:42 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03431
	for ; Tue, 27 Mar 2001 02:33:41 -0800 (PST)
Received: from zrchh190 by smtprch2.nortel.com; Tue, 27 Mar 2001 04:25:24 -0600
Received: from marvin.corpeast.baynetworks.com by zrchh190;
          Tue, 27 Mar 2001 04:30:59 -0600
Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) 
          by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP 
          id FAA16678 for ;
          Tue, 27 Mar 2001 05:30:08 -0500 (EST)
Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t;
          Tue, 27 Mar 2001 05:29:04 -0500
Received: from mail.discretix.com ( [199.203.197.2]) by 
          with SMTP (MailShield v1.5); Tue, 27 Mar 2001 05:30:29 -0500
Received: from limoremobl (fwdiscretix [199.203.92.254]) 
          by mail.discretix.com (8.9.1b+Sun/8.9.3) with SMTP id MAA01850;
          Tue, 27 Mar 2001 12:24:57 +0200 (IST)
From: Limor Elbaz 
To: ietf-tls , ipsec ,
        MOBILE-IP@marvin.corpeast.baynetworks.com, ssl 
Subject: [mobile-ip] TestBed for SSL / TLS / WTLS
Date: Tue, 27 Mar 2001 12:21:22 +0200
Message-ID: <001301c0b6a7$acac71b0$010710ac@discretix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-SMTP-HELO: mail.discretix.com
X-SMTP-MAIL-FROM: Limor.Elbaz@discretix.com
X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
X-SMTP-PEER-INFO: [199.203.197.2]
X-Orig: 
X-Orig: 
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello,
Does anyone know of a company selling out-of-the-box equipment for testing
SSL / TLS / WTLS?
Regarding WTLS, as far as I've seen, the WAP testing environment does not
cover the WTLS layer.

Thanks,

Limor.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 06:37:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16851
	for ; Tue, 27 Mar 2001 06:37:37 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28345;
	Tue, 27 Mar 2001 03:35:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28324;
	Tue, 27 Mar 2001 03:35:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RBXjIm004849
	for ; Tue, 27 Mar 2001 03:33:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RBXji8004848
	for mobile-ip-dist; Tue, 27 Mar 2001 03:33:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RBXaIm004841
	for ; Tue, 27 Mar 2001 03:33:36 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28186
	for ; Tue, 27 Mar 2001 03:33:35 -0800 (PST)
Received: from mailbreak.com ([216.207.225.170])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13684
	for ; Tue, 27 Mar 2001 04:33:35 -0700 (MST)
Received: from eshim by mailbreak.com
	with SMTP (MDaemon.v3.5.2.R)
	for ; Tue, 27 Mar 2001 06:32:30 -0500
Message-ID: <012401c0b6b2$2d33d760$6501a8c0@nyc.solidstreaming.net>
From: "Eunsoo Shim" 
To: 
References: <3AADC1B6.1772296C@iprg.nokia.com>
Subject: Re: [mobile-ip] Comments on Regional Registration
Date: Tue, 27 Mar 2001 06:36:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Return-Path: eunsoo@ctr.columbia.edu
X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I am wondering about connectivity recovery time when we use anycast
addresses.
When a group of GFAs belong to an anycast (address) group, the other routers
will pick a nearest GFA.
Let say there is a router A and its nearest GFA crashes.
Then how long will it take the router A find out crash of the nearest GFA
and find the new nearest GFA (the old second nearest GFA in the anycast
group)?
Thanks.


Eunsoo

----- Original Message -----
From: "Charlie Perkins" 
To: "Glenn Morrow" 
Cc: 
Sent: Tuesday, March 13, 2001 1:44 AM
Subject: [mobile-ip] Comments on Regional Registration


> Hello folks,
>
> Sorry if this is a duplicate.  I do not know if the original
> made it out of our site.
>
> > Thanks for the reply. I am trying to get people to open up their minds
with
> > IPv6. It is still fairly malleable for change and has many tools which
can
> > be used to achieve this functionality.
>
> Do you mean to suggest changing IPv6?  If you mean changing something
> else (using its favorable malleability), can you say what?
>
> >                                           The RR draft seems to be let's
> > fork-lift the IPv4 solution and slap in some anycast magic. I think a
better
> > solution is out there for this functionality using IPv6's features that
> > leverages any natural aggregation that may exist in any given IP
network.
>
> A slap is not respectful treatment for anybody, not even an
> anycast address.  I think that the anycast address has
> exactly the right semantics.  We also are trying to get people
> to open their minds with IPv6.
>
> Anycast is exactly right, because what the mobile node "wants"
> is for the crossover router to take the appropriate action,
> without the mobile node knowing which router it is.
>
> Anycast even helps to preserve the connectionless nature which
> we would like to preserve for regionalized mobility handling.
>
> > In my opinion arbitary point is not a requirement and even if it were
there
> > are better solutions  which do not require any changes to the protocols,
> > especially if you use tunneling.
>
> I thought that a lot of people wanted to use an arbitrary point of
> contact (between access network and Internet) as an "anchor point".
> Or maybe you are referring to something else.
>
> > RR is nothing more than an IP proxy using MIP signaling to provision it.
>
> In a subsequent note, you retracted this characterization, but I'd
> still like to know how you wished to draw the analogy between
> something in regionalized registration, and an IP proxy (what
> is an IP proxy?).
>
> Regards,
> Charlie P.
>




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 06:47:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16928
	for ; Tue, 27 Mar 2001 06:47:01 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03914;
	Tue, 27 Mar 2001 03:45:26 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05224;
	Tue, 27 Mar 2001 03:45:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RBhvIm004883
	for ; Tue, 27 Mar 2001 03:43:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RBhv4d004882
	for mobile-ip-dist; Tue, 27 Mar 2001 03:43:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RBhmIm004875
	for ; Tue, 27 Mar 2001 03:43:48 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03164
	for ; Tue, 27 Mar 2001 03:43:48 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03063
	for ; Tue, 27 Mar 2001 03:43:46 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f2RBhiC05032
	for ; Tue, 27 Mar 2001 13:43:44 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f2RBhgC17865
	for ; Tue, 27 Mar 2001 14:43:42 +0300 (EET DST)
Message-ID: <3AC07CEE.BC5DF2C0@lmf.ericsson.se>
Date: Tue, 27 Mar 2001 14:43:42 +0300
From: Jari Arkko 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Scalability [Was Re: [mobile-ip] Drafty draft about key ...
References: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com> <3ABF8825.8E51BE6E@nomadiclab.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

There were some questions on this list relating to
exactly what the scalability issues wrt security are,
and how costly it is to maintain large numbers of
SAs etc. Maybe I can offer some thoughts on the
subject from the point of view of an IPsec
implementor (even on small systems):

* I'm pretty sure the IESG is talking about the
  overhead in setting up the SAs, not e.g. the
  overhead of IPsec AH itself. Why? See below...

* The header overhead per secured BU packet shouldn't
  be a concern. There aren't enough BU packets to
  make this significant.

* The cryptographic processing (e.g. MAC verification)
  shouldn't be a concern either. Again, you won't be
  doing all your traffic with these. And even if you
  were - what do you demand: that you can have security
  but not have to execute any cryptographic operations
  at all? MAC verification must be one of the cheapest
  cryptographic operations.

* Memory consumption. Well, essentially an SA needs
  an SPI number (4 bytes), protocol (1 byte), secret
  (e.g. 16 bytes), various algorithm etc indicators
  (say 4 bytes), and maybe a couple of other things
  such as sequence numbers. So, in conclusion you
  could spend in the best case maybe some dozens
  of bytes, typical implementations perhaps use
  something in the order of a few hundred bytes
  at the worst. (Adding encryption algorithm that
  needs a large table to speed things up could
  set you up for an additional few kilobytes.)

  Of course there also has to be some sort of
  policy information that determines which
  packet should be protected how, but I haven't
  counted this as that sort of thing depends to
  vary a lot between systems, and is in any
  case the same for all possible security schemes.

  In conclusion, the memory consumption varies
  as you use different length keys and different
  algorithms, but isn't really that significant.
  Think you need million SAs and claim that IPsec
  AH doesn't scale in terms of memory needed? Well,
  I'll use again my argument about the use of some
  crypto at least. Otherwise you won't have security.
  And if you have some cryptographic operations, do
  you think you're going to survive without any
  secrets or connection identifiers whatsover, or
  sequence numbers? Don't think so. No security
  costs less than security, but all security schemes
  will require _some_ amount of storage.

* What about the overhead in setting up the SAs then?
  Where are the concerns? (Don't you just love the
  divine wisdom we are getting from the iesg, it
  is very hard to decipher their input.)

  Here I think we see several issues. One, there
  is again a number of cryptographic operations
  which are very heavy this time: Diffie-Hellman,
  RSA, ... Second, protocols to negotiate this
  are complex. Third, how do we set up the trust
  for the protocols to work, do we need a global
  PKI?

*
I firmly believe the trust part is the hard
  one here. Almost everybody agrees that building
  global PKIs is neither possible nor desirable.
  I think this is what the IESG is worried about.

* Cryptographic operations for the set-up.
  This is a hard one, too, particularly for
  small systems. Before you decide that you
  can't afford protocol X because it uses
  algorithm Y which is heavy, please decide
  what are the security requirements! If you
  *can* compromise on Man-in-the-Middle protection,
  for instance, then maybe something can be done.
  Otherwise...

* Protocol complexity. Yeah. A lot of the
  complexity comes from the PKI stuff, by the
  way. Avoid that and you get rid of it...
  Not avoid it and it won't help much if you
  simplify your keying protocol or the packet
  protection protocol... Also, when you consider
  things like KINK in a global context you'll
  propably have to do Kerberos *and* public
  key schemes with PK-Init.

* I believe somebody mentioned also that IPsec
  can't deal with the policies to protect
  particular extension headers. I believe this
  is an issue that could be dealth with, if
  we wanted to.

Hope this helps,

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 07:30:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17309
	for ; Tue, 27 Mar 2001 07:30:51 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24899;
	Tue, 27 Mar 2001 04:28:45 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01679;
	Tue, 27 Mar 2001 04:28:40 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RCRHIm004947
	for ; Tue, 27 Mar 2001 04:27:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RCRHcG004946
	for mobile-ip-dist; Tue, 27 Mar 2001 04:27:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RCR7Im004939
	for ; Tue, 27 Mar 2001 04:27:08 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01590
	for ; Tue, 27 Mar 2001 04:27:07 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24118
	for ; Tue, 27 Mar 2001 04:27:06 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2RCR4d18323
	for ; Tue, 27 Mar 2001 14:27:04 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Mar 27 14:26:57 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 14:26:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCCC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.
	txt
Date: Tue, 27 Mar 2001 14:26:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	Hi Jari, 

> > > I believe we are not overriding routing protocols any more than you
> > > are, once we compare with your extended mode.
> > >
> >         => ??? I don't get that. Multi-level hierarchy forces packets
> >         into a fixed route between levels. I don't know what you mean ??
> >         Extended mode != multi-level hierarchy.
> 
> It seems to resemble a multi-level hierarchy, at least for packets
> going to previous MAP address or when using nested mobile routers.
> 
	=> No it's certainly not a multi-level hierarchy, the smooth 
	handoff (forwarding from the previous MAP) is a temporary 
	situation during a handoff. 

	As for the MR case, I agree that it would look like a multi-level
	hierarchy, but in this case routing within the network 
	is not overridden since every packet reaching the MN will 
	go through the AR anyway. (*)

> In extended mode MN is dislocated as compared to both the fixed and
> mobile MAP. 
> The mobile node needs to let the lower MAP to know how
> to route packets to MN. Consider packets coming from CN to old RCoA
> (CoA registered with CN before MN can register new CoA after lower
> MAP moved). The packets get re-routed from HA of the mobile MAP to
> 
	=> No they get routed from the HA of the MN which maybe 
	the same as the MR.

> wherever the mobile MAP moved, taking them to the higher MAP since
> this should hold the RCoA for the lower MAP. It will consume the
> routing header of a route-optimized packet. Now the packet's destination
> address will be home address of the MN in the mobile network.
> Could you clarify routing to this address, re-capsulation through
> lower MAP or perhaps by host-based routing?
> 
	=> Encapsulate to the lower MAP. Again note that the packets 
	have to go through the MR anyway. 

> A second case to consider is when MN can recursively be a mobile
> router. There is a need for a host-routing protocol or recapsulating
> tunneling to navigate packets through nested mobile networks.
> 
	=> This is really out there, why does the MN need to be another
	MR, except for the case of making this proposal look like a 
	tree of routers ??? 
	The scenario you've mentioned is not in the draft and I don't 
	understand the relevance to this discssion.

> Using MAP as the connection point of mobile networks looks essential
> to the method of getting packets to these nested networks thus fixing 
> packets to pass MAPs.
> 
	=> See (*).

> > > > > Better optimization of last hop bandwidth usage, network-controlled
> > > > > load balancing (your scheme has hop count and priority in a MAP
> > > > > option, these trust MN does something it may not be designed to
> > > > > do and require more than one MAP options to make a choice even
> > > > > possible).
> > > > >
> > > >         => Are you referring to the MAP option ?
> > > >         I hope this is not the BW argument. This argument is
> > > >         not valid IMO. RAs are designed to have several
> > > >         options regardless of the use of MIP. I hope we can agree on that.
> > >
> > > We can still try to reduce the size of the RA, i.e. number of extensions
> > > needed for a load-balancing network.
> > >
> >         => Jari, have you read the draft ? What load balancing
> >         extensions are you referring to ? The load balancig described
> >         in the draft is something else. Have a look at rev 2 or 3.
> 
> 
> Considering RA size in IPv6 and cost of last mile bandwidth it is
> in our requirements advisable trying to avoid extending it further.
> If we can do with one extension and still distribute signaling load,
> it extends scalability the bigger the visited domain.
> 
	=> Jari, we're going around in circles here. I've already
	answered this _several_ times. The rtr adv does NOT
	need to be frequently advertised. Only when something 
	changes, timers time out ....etc. See the Fast 
	Handoffs draft to see how Fast Handoffs can still work
	in this scenario. 
	We're talking about 2 options at the most.

	I hope this is clear now. 

	Regards,
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 08:45:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17989
	for ; Tue, 27 Mar 2001 08:45:37 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06090;
	Tue, 27 Mar 2001 05:44:11 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14192;
	Tue, 27 Mar 2001 05:44:02 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RDgYIm005055
	for ; Tue, 27 Mar 2001 05:42:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RDgYda005054
	for mobile-ip-dist; Tue, 27 Mar 2001 05:42:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RDgNIm005039
	for ; Tue, 27 Mar 2001 05:42:24 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25229
	for ; Tue, 27 Mar 2001 05:42:24 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24371
	for ; Tue, 27 Mar 2001 05:42:22 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RDgKd42134
	for ; Tue, 27 Mar 2001 14:42:21 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA15954
	for ; Tue, 27 Mar 2001 15:42:20 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RDgJA76985
	for ; Tue, 27 Mar 2001 15:42:19 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271342.f2RDgJA76985@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Mon, 26 Mar 2001 22:43:04 -0800.
             <008501c0b689$2d1b1be0$6501a8c0@smateo1.sfba.home.com> 
Date: Tue, 27 Mar 2001 15:42:19 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   2.  Both get rid of MN<>CN BUs, and also add the ability to obtain local HAs
   in a visited domain as in RFC 7494.  (Either that or some variant of the
   Gateway FA or MAP or some such hierarchical/regional scheme that has already
   been specified).
   
=> if you want to put the HA close to one of the two peers
the CN is better in general because the MN is known to be mobile.
(This is essentialy my proposal for site-local stuff - first IPngWG
session, I don't know if you attended this one but minutes are available,
I'll ask to add a statement about this :-).
I've seen there is a message from a HMIPv6 person so I'll read it in order
to discover if we have a good solution using a hierarchical scheme.

Regards

Francis.Dupont@enst-bretagne.fr

PS: even with some social engineering I don't know a good way to avoid
delays so we should leave the "panic mode", please.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 09:02:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18217
	for ; Tue, 27 Mar 2001 09:02:21 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03242;
	Tue, 27 Mar 2001 06:01:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09084;
	Tue, 27 Mar 2001 06:01:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RDxgIm005109
	for ; Tue, 27 Mar 2001 05:59:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RDxgZl005108
	for mobile-ip-dist; Tue, 27 Mar 2001 05:59:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RDxXIm005101
	for ; Tue, 27 Mar 2001 05:59:33 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15863
	for ; Tue, 27 Mar 2001 05:59:34 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19819
	for ; Tue, 27 Mar 2001 06:59:32 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RDxVd42787;
	Tue, 27 Mar 2001 14:59:31 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA16505;
	Tue, 27 Mar 2001 15:59:30 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RDxTA77073;
	Tue, 27 Mar 2001 15:59:29 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271359.f2RDxTA77073@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: "'paul@francis.com'" 
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Tue, 27 Mar 2001 08:56:15 +0200.
             <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se> 
Date: Tue, 27 Mar 2001 15:59:29 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   The other disadvantage would be that it won't work if there
   is no AAA. 
   
=> I agree but my conclusion is a bit different: the new scheme for
Mobile IPv6 security should be able to work with the help of AAA,
for instance:
 - message (Bx) transport must be flexible
 - trusted third party should be able to provide authentication

Regards

Francis.Dupont@enst-bretagne.fr

PS: some proposals did already show that some part of the secure
Mobile IPv6 procedures can be greatly simplified by AAA!


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 09:19:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18470
	for ; Tue, 27 Mar 2001 09:19:03 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09854;
	Tue, 27 Mar 2001 06:18:01 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14929;
	Tue, 27 Mar 2001 06:17:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REExIm005163
	for ; Tue, 27 Mar 2001 06:15:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2REExKm005162
	for mobile-ip-dist; Tue, 27 Mar 2001 06:14:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REEoIm005155
	for ; Tue, 27 Mar 2001 06:14:50 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17660
	for ; Tue, 27 Mar 2001 06:14:51 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11503
	for ; Tue, 27 Mar 2001 06:14:50 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2REEmd16329;
	Tue, 27 Mar 2001 15:14:48 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA16960;
	Tue, 27 Mar 2001 16:14:48 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2REElA77135;
	Tue, 27 Mar 2001 16:14:47 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271414.f2REElA77135@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: "'paul@francis.com'" 
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Tue, 27 Mar 2001 10:07:19 +0200.
             <3AC04A37.973B221@inrialpes.fr> 
Date: Tue, 27 Mar 2001 16:14:47 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   An other "short-term" alternative would be to use HMIPv6 with
   pre-shared keys...  i.e. the MN has pre-shared keys with the MAPs it
   usually visits (i.e. its MAP at work, at home, ....).
   
=> I disagree: if we have pre-shared keys then we can use certificates.
But the fact we have authentication/authorization is still right.

   This would work as follows:
   1-The MN discovers a MAP as specified in the HMIPv6 draft
   2-if the MN has a pre-shared key with this MAP, it registers with
     it and registers its RCoA with its HA
   3-if the MN does not have a pre-shared key it then uses Mobile IPv6
     (without RO)
   
   I think this is a pretty good tradeoff ....
   
=> it is a good one if CNs are not far from HA and MAPs.
I believe this idea doesn't apply in every cases but this is better
than the local HA in all cases where the local HA is interesting.
So we can add a requirement to the new security scheme: still work
with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 09:53:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18885
	for ; Tue, 27 Mar 2001 09:53:39 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24298;
	Tue, 27 Mar 2001 06:52:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03632;
	Tue, 27 Mar 2001 06:52:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REp0Im005253
	for ; Tue, 27 Mar 2001 06:51:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2REp0CP005252
	for mobile-ip-dist; Tue, 27 Mar 2001 06:51:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2REopIm005245
	for ; Tue, 27 Mar 2001 06:50:51 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21823
	for ; Tue, 27 Mar 2001 06:50:52 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10410
	for ; Tue, 27 Mar 2001 06:50:51 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2REood54490
	for ; Tue, 27 Mar 2001 15:50:50 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA18052
	for ; Tue, 27 Mar 2001 16:50:49 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2REonA77475
	for ; Tue, 27 Mar 2001 16:50:49 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271450.f2REonA77475@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ... 
In-reply-to: Your message of Tue, 27 Mar 2001 14:43:42 +0300.
             <3AC07CEE.BC5DF2C0@lmf.ericsson.se> 
Date: Tue, 27 Mar 2001 16:50:49 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

     Almost everybody agrees that building
     global PKIs is neither possible nor desirable.

=> no, I disagree. This is not yet proved impossible and
this is desirable or I don't understand why we are trying
so hard to fix then deploy DNSsec!
So don't say everybody (or add "in the IESG" :-).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:11:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19392
	for ; Tue, 27 Mar 2001 10:11:26 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02386;
	Tue, 27 Mar 2001 07:10:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24911;
	Tue, 27 Mar 2001 07:10:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RF93Im005316
	for ; Tue, 27 Mar 2001 07:09:03 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RF928Z005315
	for mobile-ip-dist; Tue, 27 Mar 2001 07:09:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RF8rIm005308
	for ; Tue, 27 Mar 2001 07:08:54 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16663
	for ; Tue, 27 Mar 2001 07:08:54 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00114
	for ; Tue, 27 Mar 2001 08:08:53 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03663
	for ; Tue, 27 Mar 2001 07:09:15 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE08341;
	Tue, 27 Mar 2001 07:08:51 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02861; Tue, 27 Mar 2001 07:08:51 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.44291.238997.780414@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 07:08:51 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <007901c0b687$74281d00$6501a8c0@smateo1.sfba.home.com>
References: <200103262146.f2QLkJX00602@locked.eng.sun.com>
	<007901c0b687$74281d00$6501a8c0@smateo1.sfba.home.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Paul Francis writes:
 > What I'm suggesting instead is putting the HA close to the MN, so that going
 > through it is not very costly (by getting an HA in the visited domain).  My
 > form of route optimization will occasionally end up with a long path, if for
 > instance a mobile goes very far while maintaining a connection.  I'm saying
 > that this form of route optimization is worth it if it means we can delay
 > the hard problem of security.

   I think you've falled into a pretty easy trap.
   The main (though perhaps not only) motiviation
   of a home agent is reachability as a server. So
   how do you plan to migrate the A6 records as you
   are moving in the visited network?

   I believe that you end up with two previously 
   unsolved problems instead of one. Perhaps three,
   because this is really just renumbering in 
   disguise.

		     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:14:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19482
	for ; Tue, 27 Mar 2001 10:14:22 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03942;
	Tue, 27 Mar 2001 07:13:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25365;
	Tue, 27 Mar 2001 07:12:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFBkIm005348
	for ; Tue, 27 Mar 2001 07:11:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFBjjw005347
	for mobile-ip-dist; Tue, 27 Mar 2001 07:11:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFBaIm005340
	for ; Tue, 27 Mar 2001 07:11:36 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25188
	for ; Tue, 27 Mar 2001 07:11:37 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09946
	for ; Tue, 27 Mar 2001 07:11:36 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05105;
	Tue, 27 Mar 2001 07:11:57 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE08371;
	Tue, 27 Mar 2001 07:11:35 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02864; Tue, 27 Mar 2001 07:11:35 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.44454.892571.129954@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 07:11:34 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'paul@francis.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
References: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham Soliman  (ERA) writes:
 > 4. The MN uses DynDNS or SIP to register its Home 
 >     address. 

   So do you envision 0 length TTL's? 

	 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:17:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19596
	for ; Tue, 27 Mar 2001 10:17:44 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05748;
	Tue, 27 Mar 2001 07:16:42 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17951;
	Tue, 27 Mar 2001 07:16:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFF0Im005380
	for ; Tue, 27 Mar 2001 07:15:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFEx0v005379
	for mobile-ip-dist; Tue, 27 Mar 2001 07:14:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFEmIm005372
	for ; Tue, 27 Mar 2001 07:14:49 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10904
	for ; Tue, 27 Mar 2001 07:14:49 -0800 (PST)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA11420
	for ; Tue, 27 Mar 2001 07:14:48 -0800 (PST)
Date: Tue, 27 Mar 2001 07:14:46 -0800 (PST)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <15040.44291.238997.780414@thomasm-u1.cisco.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> Paul Francis writes:
>  > What I'm suggesting instead is putting the HA close to the MN, so that
> going
>  > through it is not very costly (by getting an HA in the visited domain). 
> My
>  > form of route optimization will occasionally end up with a long path, if
> for
>  > instance a mobile goes very far while maintaining a connection.  I'm
> saying
>  > that this form of route optimization is worth it if it means we can delay
>  > the hard problem of security.
> 
>    I think you've falled into a pretty easy trap.
>    The main (though perhaps not only) motiviation
>    of a home agent is reachability as a server. So
>    how do you plan to migrate the A6 records as you
>    are moving in the visited network?
> 
>    I believe that you end up with two previously 
>    unsolved problems instead of one. Perhaps three,
>    because this is really just renumbering in 
>    disguise.

Allocation of a Home Agent in a visited network does require some additional
infrastructure, such as AAA, and yes this does require a dynamic home address
(and dynamic DNS updates from AAA in the home domain). I am sorry to say that
not only is still solved, interoperability was achieved (for v4) at the last
Connectathon. So, figuring out the MIPv6->AAA interactions would solve this
problem.

Of course, this mandates AAA for (scalable) MIPv6, which is probably not a
good thing.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:18:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19627
	for ; Tue, 27 Mar 2001 10:18:34 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15739;
	Tue, 27 Mar 2001 07:17:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26172;
	Tue, 27 Mar 2001 07:17:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFG8Im005393
	for ; Tue, 27 Mar 2001 07:16:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFG7uu005392
	for mobile-ip-dist; Tue, 27 Mar 2001 07:16:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFFsIm005385
	for ; Tue, 27 Mar 2001 07:15:55 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17795
	for ; Tue, 27 Mar 2001 07:15:45 -0800 (PST)
Received: from newman.gte.com ([132.197.8.26])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05145
	for ; Tue, 27 Mar 2001 08:15:44 -0700 (MST)
Received: from rcmppc2 (rcmppc2.gte.com [132.197.73.30])
	by newman.gte.com (8.9.1/8.9.1) with ESMTP id KAA25949
	for ; Tue, 27 Mar 2001 10:15:43 -0500 (EST)
Message-Id: <4.2.0.58.20010327101151.00aaf100@127.0.0.1>
X-Sender: sjj0/pophost.gte.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Mar 2001 10:16:26 -0500
To: mobile-ip@sunroof.eng.sun.com
From: Stuart Jacobs 
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key
  ... 
In-Reply-To: <200103271450.f2REonA77475@givry.rennes.enst-bretagne.fr>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

I have to add my 2 cents and agree with Francis.  Unless we move to a 
globally authenticatible networking environment we will always be plagued 
with security problems and the only way to scale up to this via PKIs.  We 
do NOT have to have one great PKI rather we should be thinking of a 
multitude of PKIs that are each established for specific purposes.  One can 
instantiate a PKI just for MIP that would provide asymmetric credentials 
bound to NAIs for authenticating NMs, CNs and mobility agents.

At 3/27/01 04:50 PM, you wrote:
>      Almost everybody agrees that building
>      global PKIs is neither possible nor desirable.
>
>=> no, I disagree. This is not yet proved impossible and
>this is desirable or I don't understand why we are trying
>so hard to fix then deploy DNSsec!
>So don't say everybody (or add "in the IESG" :-).
>
>Thanks
>
>Francis.Dupont@enst-bretagne.fr

==========================
Stuart Jacobs CISSP
Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
stu.jacobs@verizon.com     sjj0@gte.com
==========================


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:22:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19753
	for ; Tue, 27 Mar 2001 10:22:18 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18396;
	Tue, 27 Mar 2001 07:20:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26943;
	Tue, 27 Mar 2001 07:20:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFJOIm005447
	for ; Tue, 27 Mar 2001 07:19:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFJNxB005446
	for mobile-ip-dist; Tue, 27 Mar 2001 07:19:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFJDIm005436
	for ; Tue, 27 Mar 2001 07:19:14 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12249
	for ; Tue, 27 Mar 2001 07:18:58 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16796
	for ; Tue, 27 Mar 2001 07:18:42 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2RFIdC15176
	for ; Tue, 27 Mar 2001 17:18:40 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 27 17:18:37 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:14:26 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD5@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Tue, 27 Mar 2001 17:18:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mike, 


> Paul Francis writes:
>  > What I'm suggesting instead is putting the HA close to the MN, so that going
>  > through it is not very costly (by getting an HA in the visited domain).  My
>  > form of route optimization will occasionally end up with a long path, if for
>  > instance a mobile goes very far while maintaining a connection.  I'm saying
>  > that this form of route optimization is worth it if it means we can delay
>  > the hard problem of security.
> 
>    I think you've falled into a pretty easy trap.
>    The main (though perhaps not only) motiviation
>    of a home agent is reachability as a server. So
>    how do you plan to migrate the A6 records as you
>    are moving in the visited network?
> 
	=> I don't get that. See below.

>    I believe that you end up with two previously 
>    unsolved problems instead of one. Perhaps three,
>    because this is really just renumbering in 
>    disguise.
> 
	=> I don't think so, there are other mechanisms
	(like SIP or DynDNS) that can be used to update
	the user's location. Not having a HA does not mean
	you can't be a server. 


	Hesham







From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:24:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19824
	for ; Tue, 27 Mar 2001 10:24:05 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20523;
	Tue, 27 Mar 2001 07:22:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27197;
	Tue, 27 Mar 2001 07:22:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFLpIm005481
	for ; Tue, 27 Mar 2001 07:21:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFLpvp005480
	for mobile-ip-dist; Tue, 27 Mar 2001 07:21:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFLfIm005471
	for ; Tue, 27 Mar 2001 07:21:42 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13263
	for ; Tue, 27 Mar 2001 07:21:42 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19534
	for ; Tue, 27 Mar 2001 07:21:41 -0800 (PST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2RFLdC17312
	for ; Tue, 27 Mar 2001 17:21:39 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 27 17:21:37 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:21:39 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD6@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Tue, 27 Mar 2001 17:21:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> Hesham Soliman  (ERA) writes:
>  > 4. The MN uses DynDNS or SIP to register its Home 
>  >     address. 
> 
>    So do you envision 0 length TTL's? 
> 
	=> Well if you use DynDNS I guess you 
	have to. I assume you're referring to the 
	DynDNS example. SIP is also a possibility
	for the applications that will use it. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:30:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19998
	for ; Tue, 27 Mar 2001 10:30:38 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11684;
	Tue, 27 Mar 2001 07:29:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14377;
	Tue, 27 Mar 2001 07:25:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFNqIm005510
	for ; Tue, 27 Mar 2001 07:23:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFNpwQ005509
	for mobile-ip-dist; Tue, 27 Mar 2001 07:23:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFNfIm005497
	for ; Tue, 27 Mar 2001 07:23:41 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27301
	for ; Tue, 27 Mar 2001 07:23:42 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29217
	for ; Tue, 27 Mar 2001 07:23:41 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA08262
	for ; Tue, 27 Mar 2001 07:23:41 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE08531;
	Tue, 27 Mar 2001 07:23:40 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02868; Tue, 27 Mar 2001 07:23:40 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.45180.381408.299660@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 07:23:40 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: 
References: <15040.44291.238997.780414@thomasm-u1.cisco.com>
	
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > > Paul Francis writes:
 > >    I think you've falled into a pretty easy trap.
 > >    The main (though perhaps not only) motiviation
 > >    of a home agent is reachability as a server. So
 > >    how do you plan to migrate the A6 records as you
 > >    are moving in the visited network?
 > > 
 > >    I believe that you end up with two previously 
 > >    unsolved problems instead of one. Perhaps three,
 > >    because this is really just renumbering in 
 > >    disguise.
 > 
 > Allocation of a Home Agent in a visited network does require some additional
 > infrastructure, such as AAA, and yes this does require a dynamic home address
 > (and dynamic DNS updates from AAA in the home domain). I am sorry to say that
 > not only is still solved, interoperability was achieved (for v4) at the last
 > Connectathon. So, figuring out the MIPv6->AAA interactions would solve this
 > problem.

   So did you use 0 length TTL's?
 
 > Of course, this mandates AAA for (scalable) MIPv6, which is probably not a
 > good thing.

   Amongst other things. Anything that posits DNS
   as being a real time transaction system is dead
   in the water. 

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:45:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20498
	for ; Tue, 27 Mar 2001 10:45:31 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08643;
	Tue, 27 Mar 2001 07:44:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00447;
	Tue, 27 Mar 2001 07:44:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFh7Im005595
	for ; Tue, 27 Mar 2001 07:43:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFh7EY005594
	for mobile-ip-dist; Tue, 27 Mar 2001 07:43:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFgwIm005587
	for ; Tue, 27 Mar 2001 07:42:58 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00285
	for ; Tue, 27 Mar 2001 07:42:59 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03992
	for ; Tue, 27 Mar 2001 07:42:58 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA20155
	for ; Tue, 27 Mar 2001 07:43:01 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE08763;
	Tue, 27 Mar 2001 07:42:56 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02871; Tue, 27 Mar 2001 07:42:56 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.46336.563904.967688@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 07:42:56 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBCD6@esealnt448.al.sw.ericsson.se>
References: <034BEFD03799D411A59F00508BDF7546013DBCD6@esealnt448.al.sw.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham Soliman  (ERA) writes:
 > > Hesham Soliman  (ERA) writes:
 > >  > 4. The MN uses DynDNS or SIP to register its Home 
 > >  >     address. 
 > > 
 > >    So do you envision 0 length TTL's? 
 > > 
 > 	=> Well if you use DynDNS I guess you 
 > 	have to. I assume you're referring to the 
 > 	DynDNS example. SIP is also a possibility
 > 	for the applications that will use it. 

   Whether it's SIP or DNS or Oracle 27.0, the implication
   is a highly available, highly distributed online transaction
   processing database with suffers many of the same cross
   realm difficulties that FMIP, etc, are trying to solve
   (which is, for the most part, local convergence).

   Do you have an example of an existing system which
   actually exhibits all of the necessary requirements?
   I don't know of any. About the closest I can think
   of is the IP routing system, but that would bring
   us back full circle.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 10:59:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20845
	for ; Tue, 27 Mar 2001 10:59:06 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25535;
	Tue, 27 Mar 2001 07:58:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19647;
	Tue, 27 Mar 2001 07:57:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFuDIm005634
	for ; Tue, 27 Mar 2001 07:56:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RFuDQI005633
	for mobile-ip-dist; Tue, 27 Mar 2001 07:56:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RFu4Im005626
	for ; Tue, 27 Mar 2001 07:56:04 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01846
	for ; Tue, 27 Mar 2001 07:56:04 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12244
	for ; Tue, 27 Mar 2001 07:56:03 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2RFu2d08704
	for ; Tue, 27 Mar 2001 17:56:02 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Mar 27 17:56:02 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:51:50 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCD8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Tue, 27 Mar 2001 17:56:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

>  > > Hesham Soliman  (ERA) writes:
>  > >  > 4. The MN uses DynDNS or SIP to register its Home 
>  > >  >     address. 
>  > > 
>  > >    So do you envision 0 length TTL's? 
>  > > 
>  > 	=> Well if you use DynDNS I guess you 
>  > 	have to. I assume you're referring to the 
>  > 	DynDNS example. SIP is also a possibility
>  > 	for the applications that will use it. 
> 
>    Whether it's SIP or DNS or Oracle 27.0, the implication
>    is a highly available, highly distributed online transaction
>    processing database with suffers many of the same cross
>    realm difficulties that FMIP, etc, are trying to solve
>    (which is, for the most part, local convergence).
> 
>    Do you have an example of an existing system which
>    actually exhibits all of the necessary requirements?
> 
	=> No I don't, and I don't know how far it can scale
	before the whole infrastructure starts shaking ! I was just 
	presenting alternatives. I haven't seen any simulations
	that I can use to know whether this would scale 
	at all.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:10:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21141
	for ; Tue, 27 Mar 2001 11:10:15 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28781;
	Tue, 27 Mar 2001 08:08:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04254;
	Tue, 27 Mar 2001 08:08:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RG7dIm005688
	for ; Tue, 27 Mar 2001 08:07:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RG7d6i005687
	for mobile-ip-dist; Tue, 27 Mar 2001 08:07:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RG7UIm005680
	for ; Tue, 27 Mar 2001 08:07:30 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21159
	for ; Tue, 27 Mar 2001 08:07:31 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22369
	for ; Tue, 27 Mar 2001 08:07:30 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA09892
	for ; Tue, 27 Mar 2001 08:07:52 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE09204;
	Tue, 27 Mar 2001 08:07:30 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02874; Tue, 27 Mar 2001 08:07:30 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.47810.150384.99403@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 08:07:30 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-Reply-To: <200103271000.f2RA0pA76237@givry.rennes.enst-bretagne.fr>
References: <15039.38754.398599.433366@thomasm-u1.cisco.com>
	<200103271000.f2RA0pA76237@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis Dupont writes:
 >       I'm not a huge IKE fan, but I do know that the
 >       cable MSO's are using Kerberos to key SA's for
 >       MGCP/SIP, and that there's a real working group
 >       to really standardize Kerberized IPsec in IETF.
 > 
 > => I'd prefer to have more general trusted third party but
 > this has at least open the door.
 > 
 >       Using (or not) AAA for a similar general
 >       purpose keying mechanism really should not be
 >       done piece meal, and *especially* from MIP WG. 
 >       If people think that AAA is a good way to key
 >       SA's, we ought to have a BOF and a real WG to
 >       set the charter and requirements. As it is
 >       right, now using AAA to key SA's is an
 >       amorphous requirementless free for all. Since
 >       it's a security protocol, that should frighten
 >       everybody.
 >    
 > => I don't understand your overcautiousness... 

   I'm overcautious because getting security right
   is extremely difficult and fraught with all kinds
   of subtleties that are very easy to miss if you
   aren't extremely critical. For the denizens of
   MIP to have the hubris -- especially at this
   juncture -- to believe that they can make over
   AAA into a key distribution scheme without
   falling into any number of traps is typical,
   but manifestly wrong.

 > The security
 > problems of mobile IPv6 are authentication / authorization
 > and AAA is supposed to provide them (in a different context).

   As I've said many times before, AAA was never
   intended as a key distribution scheme. Its
   roots are a PPP client with a symmetric key 
   through a NAS to a AAA without mutual
   authentication. This isn't to say that AAA 
   cannot be transmogrified into a key
   distribution scheme -- anything can. The
   question is whether:

   a) Whether that's an appropriate use,
      and if so, how do we get it right

   b) Whether we end up with something that
      could have been solved with existing
      protocols with the proper peer review,
      etc, etc

 > There are some cases where AAA is clearly a good solution when
 > it is already available, for instance when a mobile node boots
 > in a visited network using AAA for its access control (the
 > local/visited AAA server will contact the home/remote AAA server
 > giving a timelineness to key SA's using the AAAH as a trusted
 > third party). Of course mobile IPv6 should not rely on AAA.

   AAA may be a good conduit to an existing
   authentication system. In particular, I think
   that marrying AAA with Kerberos would probably
   be a good thing (or more generally, allowing 
   for whatever EAP allows). Otherwise the AAA WG
   is just going to end up reinventing Kerberos 
   for the authentication piece all over again.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:37:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22224
	for ; Tue, 27 Mar 2001 11:37:02 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20755;
	Tue, 27 Mar 2001 08:35:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08798;
	Tue, 27 Mar 2001 08:35:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGXvIm005763
	for ; Tue, 27 Mar 2001 08:33:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGXuAN005762
	for mobile-ip-dist; Tue, 27 Mar 2001 08:33:56 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGXiIm005755
	for ; Tue, 27 Mar 2001 08:33:44 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08418;
	Tue, 27 Mar 2001 08:33:41 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA06384;
	Tue, 27 Mar 2001 08:33:41 -0800 (PST)
Message-Id: <200103271633.IAA06384@heliopolis.Eng.Sun.COM>
Date: Tue, 27 Mar 2001 08:33:41 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode
To: Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        Hesham.Soliman@era.ericsson.se
Cc: claude.castelluccia@inria.fr, Karim.El-Malki@era.ericsson.se,
        ludovic.bellier@inria.fr, james.kempf@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: c7mPjNg5Yjp/vq0kQbPAuw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham,

>
>> I understand that
>> this would be useful for IPRAN  as James Kempf had pointed out 
>> earlier in the list.
>> 
>	=> Not really, all IP based cellular systems will use ROHC
>	or something equivalent. To be more specific 3GPP will
>	and I believe 3GPP2 is making (or has made a similar 
>	decision). 
>

Neither 3GPP nor 3GPP2 currently has all IP RANs. 3GPP2 is discussing
whether to start work on a new all IP RAN architecture. 3GPP, having
just completed the UTRAN architecture, has so far declined to
investigate all IP RAN, being content with introducing IP as an
alternate transport layer protocol.

That said, I agree that header compression will likely play a role
even in an all IP RAN. That does not negate the advantage of removing
tunnelling overhead. In particular, if the tunnel changes during
handoff, it could cause the compressor to revert back to the start
state, resulting in some number (the number is currently disputed)
of packets required to restart the compressor. I've seen numbers from
60-600 ms quoted as required on a radio link with a 20 ms frame transmit
time, I am trying to reduce the uncertainty by corresponding with the ROHC 
working group chairs. Any amount of additional delay caused by having
to restart the compression state machine at the beginning would thoroughly
negate the low latency handoff work.

Note that, unlike IPv4, the headers *will* change even if there is no
tunnel overhead in IPv6 because the CoA will change when the mobile
moves to the new access point, and the CoA gets sent out over the 
air. In IPv4, the FA strips the tunnel overhead, so the compressor
state remains the same and could potentially be shipped across the
wire in a context transfer protocol (Seamoby). In IPv6, it is as yet
uncertain if the compressor state could be maintained during handoff.
And it may turn out that changing the CoA would allow the compressor
state to be transferred, but changing the tunnel would not.

The ROHC group seems to have been exclusively focused on IPv4. From
my conversations with the working group chairs at IETF in Minneapolis,
they seemed unaware that the header would change during handover
in IPv6.

My conclusion from this is that it is dangerous to make blanket assumptions that
header compression will solve problems with fat IPv6 headers lacking
solid data about whether the compression algorithms can use context
transfer to reestablish state and also reinitialize the state machines
with the new CoA. I hope this will become somewhat clearer as we get
more data from the ROHC working group.

If you are interested in helping to find this out, I suggest you generate
a couple of HMIPv6 headers including the tunnelling overhead both
before and after handover and send them to the ROHC chairs. They requested
I do this for straight IPv6 headers. They will then be able to tell
you whether or not the compressor can be restared without moving back
to the start state. Then you can base your HMIPv6 design on solid data,
rather than assumptions.

			jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:39:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22284
	for ; Tue, 27 Mar 2001 11:39:45 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15286;
	Tue, 27 Mar 2001 08:38:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07843;
	Tue, 27 Mar 2001 08:38:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGb0Im005814
	for ; Tue, 27 Mar 2001 08:37:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGb0wx005813
	for mobile-ip-dist; Tue, 27 Mar 2001 08:37:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGakIm005805
	for ; Tue, 27 Mar 2001 08:36:46 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09015
	for ; Tue, 27 Mar 2001 08:36:46 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09802
	for ; Tue, 27 Mar 2001 08:36:40 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RGaad44398
	for ; Tue, 27 Mar 2001 17:36:36 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA21200
	for ; Tue, 27 Mar 2001 18:36:35 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RGaZA78168
	for ; Tue, 27 Mar 2001 18:36:35 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271636.f2RGaZA78168@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-reply-to: Your message of Tue, 27 Mar 2001 08:07:30 -0800.
             <15040.47810.150384.99403@thomasm-u1.cisco.com> 
Date: Tue, 27 Mar 2001 18:36:35 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

    > => I don't understand your overcautiousness... 
   
      I'm overcautious because getting security right
      is extremely difficult and fraught with all kinds
      of subtleties that are very easy to miss if you
      aren't extremely critical. For the denizens of
      MIP to have the hubris -- especially at this

=> They had the hubris so they tried to use IPsec which is
supposed to be right (for security at least). You know the result!

      juncture -- to believe that they can make over
      AAA into a key distribution scheme without
      falling into any number of traps is typical,
      but manifestly wrong.
   
=> I don't like the term key distribution because AAA is more
a trusted third party but I agree about the traps.
Of course IPsec people can (should!) help: IMHO they can
have a more positive attitude than last week.

    > The security
    > problems of mobile IPv6 are authentication / authorization
    > and AAA is supposed to provide them (in a different context).
   
      As I've said many times before, AAA was never
      intended as a key distribution scheme.

=> see my previous remark.

      AAA may be a good conduit to an existing
      authentication system. In particular, I think
      that marrying AAA with Kerberos would probably
      be a good thing (or more generally, allowing 
      for whatever EAP allows).

=> I prefer the comment. I don't like Kerberos as the ultimate
answer for security (ie. I have at least as many concerns about
Kerberos as you have for AAA :-).

      Otherwise the AAA WG
      is just going to end up reinventing Kerberos 
      for the authentication piece all over again.
   
=> There is a big difference: AAA has an architecture, not only
because this is good a priori, but in order to not reinventing
Kerberos with its known weakness (don't scale, no hierarchy,
no distribution, ...).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:40:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22334
	for ; Tue, 27 Mar 2001 11:40:51 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20287;
	Tue, 27 Mar 2001 08:34:56 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08730;
	Tue, 27 Mar 2001 08:34:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGXFIm005753
	for ; Tue, 27 Mar 2001 08:33:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGXEFE005752
	for mobile-ip-dist; Tue, 27 Mar 2001 08:33:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGX5Im005745
	for ; Tue, 27 Mar 2001 08:33:05 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26034
	for ; Tue, 27 Mar 2001 08:33:05 -0800 (PST)
Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA25576
	for ; Tue, 27 Mar 2001 09:33:04 -0700 (MST)
Received: (cpmta 16294 invoked from network); 27 Mar 2001 08:33:03 -0800
Received: from c523561-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140)
  by smtp.francis.com (209.228.32.66) with SMTP; 27 Mar 2001 08:33:03 -0800
X-Sent: 27 Mar 2001 16:33:03 GMT
Message-ID: <017701c0b6db$8b73f7a0$6501a8c0@smateo1.sfba.home.com>
From: "Paul Francis" 
To: 
References: <200103271414.f2REElA77135@givry.rennes.enst-bretagne.fr>
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
Date: Tue, 27 Mar 2001 08:32:41 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> => it is a good one if CNs are not far from HA and MAPs.
> I believe this idea doesn't apply in every cases but this is better
> than the local HA in all cases where the local HA is interesting.
> So we can add a requirement to the new security scheme: still work
> with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)
>

Are you saying to use HMIPv6/MAPs, but not local HAs (but rather the true
HA)?  Then won't packet still be traveling through the true HA, and
therefore be potentially long?  I don't see what HMIPv6 would buy you here.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:48:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22537
	for ; Tue, 27 Mar 2001 11:48:20 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19161;
	Tue, 27 Mar 2001 08:47:14 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10984;
	Tue, 27 Mar 2001 08:47:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGjtIm005868
	for ; Tue, 27 Mar 2001 08:45:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGjtRZ005867
	for mobile-ip-dist; Tue, 27 Mar 2001 08:45:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGjiIm005860
	for ; Tue, 27 Mar 2001 08:45:44 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10675
	for ; Tue, 27 Mar 2001 08:45:45 -0800 (PST)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA12569
	for ; Tue, 27 Mar 2001 08:45:42 -0800 (PST)
Date: Tue, 27 Mar 2001 08:45:38 -0800 (PST)
From: Patrice Calhoun 
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <15040.47810.150384.99403@thomasm-u1.cisco.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> Francis Dupont writes:
>  >       I'm not a huge IKE fan, but I do know that the
>  >       cable MSO's are using Kerberos to key SA's for
>  >       MGCP/SIP, and that there's a real working group
>  >       to really standardize Kerberized IPsec in IETF.
>  > 
>  > => I'd prefer to have more general trusted third party but
>  > this has at least open the door.
>  > 
>  >       Using (or not) AAA for a similar general
>  >       purpose keying mechanism really should not be
>  >       done piece meal, and *especially* from MIP WG. 
>  >       If people think that AAA is a good way to key
>  >       SA's, we ought to have a BOF and a real WG to
>  >       set the charter and requirements. As it is
>  >       right, now using AAA to key SA's is an
>  >       amorphous requirementless free for all. Since
>  >       it's a security protocol, that should frighten
>  >       everybody.
>  >    
>  > => I don't understand your overcautiousness... 
> 
>    I'm overcautious because getting security right
>    is extremely difficult and fraught with all kinds
>    of subtleties that are very easy to miss if you
>    aren't extremely critical. For the denizens of
>    MIP to have the hubris -- especially at this
>    juncture -- to believe that they can make over
>    AAA into a key distribution scheme without
>    falling into any number of traps is typical,
>    but manifestly wrong.
> 
>  > The security
>  > problems of mobile IPv6 are authentication / authorization
>  > and AAA is supposed to provide them (in a different context).
> 
>    As I've said many times before, AAA was never
>    intended as a key distribution scheme. Its
>    roots are a PPP client with a symmetric key 
>    through a NAS to a AAA without mutual
>    authentication. This isn't to say that AAA 
>    cannot be transmogrified into a key
>    distribution scheme -- anything can. The
>    question is whether:
> 
>    a) Whether that's an appropriate use,
>       and if so, how do we get it right
> 
>    b) Whether we end up with something that
>       could have been solved with existing
>       protocols with the proper peer review,
>       etc, etc
> 
>  > There are some cases where AAA is clearly a good solution when
>  > it is already available, for instance when a mobile node boots
>  > in a visited network using AAA for its access control (the
>  > local/visited AAA server will contact the home/remote AAA server
>  > giving a timelineness to key SA's using the AAAH as a trusted
>  > third party). Of course mobile IPv6 should not rely on AAA.
> 
>    AAA may be a good conduit to an existing
>    authentication system. In particular, I think
>    that marrying AAA with Kerberos would probably
>    be a good thing (or more generally, allowing 
>    for whatever EAP allows). Otherwise the AAA WG
>    is just going to end up reinventing Kerberos 
>    for the authentication piece all over again.

But the reality is that it *will* happen. Remember here the critical
difference between both Kerberos and AAA, where the mobile does not initially
have access to the network (and therefore cannot contact a kerberos server),
and an intermediate box acts as the mobile's proxy. The mobile, in this case,
speaks Mobile IP with the proxy, and receives its keys via Mobile IP.

So it really isn't fair to state that there is wheel re-invention going on.

Perhaps a better use of your energy is to work with the AAA folks to make sure
that their KDC stuff is solid, instead of hand-waving about security
difficulties. That way, we all benefit at the end with a solid and secure
protocol.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 11:55:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22802
	for ; Tue, 27 Mar 2001 11:55:56 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23119;
	Tue, 27 Mar 2001 08:54:47 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12750;
	Tue, 27 Mar 2001 08:54:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGrVIm005904
	for ; Tue, 27 Mar 2001 08:53:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGrVEL005903
	for mobile-ip-dist; Tue, 27 Mar 2001 08:53:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGrMIm005896
	for ; Tue, 27 Mar 2001 08:53:22 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10688
	for ; Tue, 27 Mar 2001 08:53:22 -0800 (PST)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06809
	for ; Tue, 27 Mar 2001 08:53:22 -0800 (PST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA24065;
	Tue, 27 Mar 2001 10:53:20 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f2RGqpi21992;
	Tue, 27 Mar 2001 10:52:51 -0600 (CST)
Message-ID: <3AC0C6A3.107A6828@usa.alcatel.com>
Date: Tue, 27 Mar 2001 10:58:11 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'paul@francis.com'" 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References: <034BEFD03799D411A59F00508BDF7546013DBCC8@esealnt448.al.sw.ericsson.se>
Content-Type: multipart/mixed;
 boundary="------------D8A2299717B02D9850A568C5"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.
--------------D8A2299717B02D9850A568C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Hesham,



> the scenario you mention
> is possible/valid and can be supported with HMIPv6 as follows:
>
> 1. The MN discovers a MAP as specified in the draft
> 2. The MN gets an SA with the MAP using the AAA
>     infrastructure
> 3. The MN registers with the MAP
> 4. The MN uses DynDNS or SIP to register its Home
>     address.
>

You mean to say that the route optimization should be dropped from
the base standard?

Maybe newcomers to Mobile IP list (of course we welcome newcomers)
may not know, performance studies of mipv4 clearly indicated that the highest cost
incurred in Mobile IP routing stems from the dogleg routing
(ref. links at the mobile IP page of National University of Singapore, if they are
still there).
Anticipating this, mobile IPv6 was designed with route optimization.
  Now removing the route optimization will take us back to the dark ages, I am afraid.
  Another point: in IPv6 one of the RFCs was supposed to mandate binding cache
for all corresponding hosts upon which Mobile IPv6 route optimization was
built. Can someone tell us which RFC? I could not
locate it.

--behcet

--------------D8A2299717B02D9850A568C5
Content-Type: text/x-vcard; charset=us-ascii;
 name="behcet.sarikaya.vcf"
Content-Description: Card for Behcet Sarikaya
Content-Disposition: attachment;
 filename="behcet.sarikaya.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Sarikaya;Behcet
tel;fax:972-9965714
tel;work:972-9965075
x-mozilla-html:FALSE
org:Alcatel Corporate Research Center;Network Architecture
version:2.1
email;internet:Behcet.Sarikaya@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell Rd, CTO2=0D=0A;Richardson;Texas;75081-1936;USA
x-mozilla-cpt:;-1616
fn:Behcet Sarikaya
end:vcard

--------------D8A2299717B02D9850A568C5--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:01:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22992
	for ; Tue, 27 Mar 2001 12:01:53 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26135;
	Tue, 27 Mar 2001 09:00:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13923;
	Tue, 27 Mar 2001 09:00:45 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGxNIm005941
	for ; Tue, 27 Mar 2001 08:59:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RGxN0E005940
	for mobile-ip-dist; Tue, 27 Mar 2001 08:59:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RGxDIm005933
	for ; Tue, 27 Mar 2001 08:59:14 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01008
	for ; Tue, 27 Mar 2001 08:59:13 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25359
	for ; Tue, 27 Mar 2001 08:59:12 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA21646
	for ; Tue, 27 Mar 2001 08:57:53 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE10247;
	Tue, 27 Mar 2001 08:59:08 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02886; Tue, 27 Mar 2001 08:59:08 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.50908.368313.174432@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 08:59:08 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-Reply-To: 
References: <15040.47810.150384.99403@thomasm-u1.cisco.com>
	
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > >    AAA may be a good conduit to an existing
 > >    authentication system. In particular, I think
 > >    that marrying AAA with Kerberos would probably
 > >    be a good thing (or more generally, allowing 
 > >    for whatever EAP allows). Otherwise the AAA WG
 > >    is just going to end up reinventing Kerberos 
 > >    for the authentication piece all over again.
 > 
 > But the reality is that it *will* happen. Remember here the critical
 > difference between both Kerberos and AAA, where the mobile does not initially
 > have access to the network (and therefore cannot contact a kerberos
server),

   Incorrect. That's exactly what IAKERB is
   for. In fact, one of your chairs wrote a 
   draft on exactly this subject for using
   GSSAPI mechanisms for EAP through an IAKERB
   proxy.

   See: draft-aboba-pppext-eapgss-03.txt

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:12:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23227
	for ; Tue, 27 Mar 2001 12:12:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21432;
	Tue, 27 Mar 2001 09:10:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03395;
	Tue, 27 Mar 2001 09:09:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RH82Im005981
	for ; Tue, 27 Mar 2001 09:08:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RH8107005980
	for mobile-ip-dist; Tue, 27 Mar 2001 09:08:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RH7rIm005973
	for ; Tue, 27 Mar 2001 09:07:53 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03091
	for ; Tue, 27 Mar 2001 09:07:53 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19302
	for ; Tue, 27 Mar 2001 10:07:52 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RH7od22970
	for ; Tue, 27 Mar 2001 18:07:50 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22039
	for ; Tue, 27 Mar 2001 19:07:50 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RH7nA78291
	for ; Tue, 27 Mar 2001 19:07:49 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271707.f2RH7nA78291@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Tue, 27 Mar 2001 08:32:41 -0800.
             <017701c0b6db$8b73f7a0$6501a8c0@smateo1.sfba.home.com> 
Date: Tue, 27 Mar 2001 19:07:49 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > => it is a good one if CNs are not far from HA and MAPs.
   > I believe this idea doesn't apply in every cases but this is better
   > than the local HA in all cases where the local HA is interesting.
   > So we can add a requirement to the new security scheme: still work
   > with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)
   
   Are you saying to use HMIPv6/MAPs, but not local HAs (but rather
   the true HA)?

=> yes. HMIPv6/MAPs are a bit more complex but you can use the hierarchy
for different levels of proximity. The degenerate case (one level) is
very close to your proposal.

   Then won't packet still be traveling through the true HA,

=> why will they? I believe we need a summary of HMIPv6 by an expert
(what I am not).

   and therefore be potentially long?  I don't see what HMIPv6 would
   buy you here.
   
=> argh! I've reread the last I-D about HMIPv6:
 - in basic mode you have just to bind the proper/better RCoA and
   the traffic will be optimized routed through the corresponding MAP
 - the extended mode does essentially the same thing (just replace
   the RCoA by an alternate-COA).
Claude or Hersham should be able to explain more and more clearly...

With Eric's site-local stuff it should be easy to keep the traffic
from the site inside the site.

Regards

Francis.Dupont@enst-bretagne.fr

PS: IMHO the local HA function is one of the functions of HMIPv6
even if this is not an essential one.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:15:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23304
	for ; Tue, 27 Mar 2001 12:15:07 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24052;
	Tue, 27 Mar 2001 09:13:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14731;
	Tue, 27 Mar 2001 09:13:16 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHBfIm006013
	for ; Tue, 27 Mar 2001 09:11:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHBej7006012
	for mobile-ip-dist; Tue, 27 Mar 2001 09:11:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHBVIm006002
	for ; Tue, 27 Mar 2001 09:11:31 -0800 (PST)
Received: from locked (locked.Eng.Sun.COM [129.146.85.189])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2RHBVxf335674;
	Tue, 27 Mar 2001 09:11:31 -0800 (PST)
Message-Id: <200103271711.f2RHBVxf335674@jurassic.eng.sun.com>
Date: Tue, 27 Mar 2001 09:10:16 -0800 (PST)
From: Mohan Parthasarathy 
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ...
To: Jari.Arkko@lmf.ericsson.se
Cc: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Z4CB77dtOeOJV5GqK2wvdA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

 
> There were some questions on this list relating to
> exactly what the scalability issues wrt security are,
> and how costly it is to maintain large numbers of
> SAs etc. Maybe I can offer some thoughts on the
> subject from the point of view of an IPsec
> implementor (even on small systems):
> 
> * I'm pretty sure the IESG is talking about the
>   overhead in setting up the SAs, not e.g. the
>   overhead of IPsec AH itself. Why? See below...
> 
> * The header overhead per secured BU packet shouldn't
>   be a concern. There aren't enough BU packets to
>   make this significant.
> 
> * The cryptographic processing (e.g. MAC verification)
>   shouldn't be a concern either. Again, you won't be
>   doing all your traffic with these. And even if you
>   were - what do you demand: that you can have security
>   but not have to execute any cryptographic operations
>   at all? MAC verification must be one of the cheapest
>   cryptographic operations.
> 
If you piggyback Binding updates on an existing TCP connection
which accepts only clear packets, then the peer would drop
packets because the policy says "accept" clear packets". 
I don't know how many implementations latch the policy for
the duration of a TCP connection. We can solve this by
mandating that BUs should not be piggybacked.

> * Memory consumption. Well, essentially an SA needs
>   an SPI number (4 bytes), protocol (1 byte), secret
>   (e.g. 16 bytes), various algorithm etc indicators
>   (say 4 bytes), and maybe a couple of other things
>   such as sequence numbers. So, in conclusion you
>   could spend in the best case maybe some dozens
>   of bytes, typical implementations perhaps use
>   something in the order of a few hundred bytes
>   at the worst. (Adding encryption algorithm that
>   needs a large table to speed things up could
>   set you up for an additional few kilobytes.)
> 
>   Of course there also has to be some sort of
>   policy information that determines which
>   packet should be protected how, but I haven't
>   counted this as that sort of thing depends to
>   vary a lot between systems, and is in any
>   case the same for all possible security schemes.
> 
>   In conclusion, the memory consumption varies
>   as you use different length keys and different
>   algorithms, but isn't really that significant.
>   Think you need million SAs and claim that IPsec
>   AH doesn't scale in terms of memory needed? Well,
>   I'll use again my argument about the use of some
>   crypto at least. Otherwise you won't have security.
>   And if you have some cryptographic operations, do
>   you think you're going to survive without any
>   secrets or connection identifiers whatsover, or
>   sequence numbers? Don't think so. No security
>   costs less than security, but all security schemes
>   will require _some_ amount of storage.
> 
All the selectors defined in section 4.4.2 of RFC 2401 should
be there in the SA. These are needed for inbound selector
verification.

> * What about the overhead in setting up the SAs then?
>   Where are the concerns? (Don't you just love the
>   divine wisdom we are getting from the iesg, it
>   is very hard to decipher their input.)
> 
>   Here I think we see several issues. One, there
>   is again a number of cryptographic operations
>   which are very heavy this time: Diffie-Hellman,
>   RSA, ... Second, protocols to negotiate this
>   are complex. Third, how do we set up the trust
>   for the protocols to work, do we need a global
>   PKI?
> 
I don't think overhead is a real issue. Once an SA is setup,
it can be used for a lot of BUs.

-mohan

> *
> I firmly believe the trust part is the hard
>   one here. Almost everybody agrees that building
>   global PKIs is neither possible nor desirable.
>   I think this is what the IESG is worried about.
> 
> * Cryptographic operations for the set-up.
>   This is a hard one, too, particularly for
>   small systems. Before you decide that you
>   can't afford protocol X because it uses
>   algorithm Y which is heavy, please decide
>   what are the security requirements! If you
>   *can* compromise on Man-in-the-Middle protection,
>   for instance, then maybe something can be done.
>   Otherwise...
> 
> * Protocol complexity. Yeah. A lot of the
>   complexity comes from the PKI stuff, by the
>   way. Avoid that and you get rid of it...
>   Not avoid it and it won't help much if you
>   simplify your keying protocol or the packet
>   protection protocol... Also, when you consider
>   things like KINK in a global context you'll
>   propably have to do Kerberos *and* public
>   key schemes with PK-Init.
> 
> * I believe somebody mentioned also that IPsec
>   can't deal with the policies to protect
>   particular extension headers. I believe this
>   is an issue that could be dealth with, if
>   we wanted to.
> 
> Hope this helps,
> 
> Jari



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:23:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23509
	for ; Tue, 27 Mar 2001 12:23:29 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01713;
	Tue, 27 Mar 2001 09:22:10 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05909;
	Tue, 27 Mar 2001 09:21:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHKKIm006048
	for ; Tue, 27 Mar 2001 09:20:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHKJt5006047
	for mobile-ip-dist; Tue, 27 Mar 2001 09:20:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHKAIm006040
	for ; Tue, 27 Mar 2001 09:20:10 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16386
	for ; Tue, 27 Mar 2001 09:20:10 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09136
	for ; Tue, 27 Mar 2001 09:20:05 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02433
	for ; Tue, 27 Mar 2001 09:18:13 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE10751;
	Tue, 27 Mar 2001 09:19:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02890; Tue, 27 Mar 2001 09:19:28 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.52127.930379.143697@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 09:19:27 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-Reply-To: <200103271636.f2RGaZA78168@givry.rennes.enst-bretagne.fr>
References: <15040.47810.150384.99403@thomasm-u1.cisco.com>
	<200103271636.f2RGaZA78168@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis Dupont writes:
 > => They had the hubris so they tried to use IPsec which is
 > supposed to be right (for security at least). You know the result!

   Heh :-)

 >       AAA may be a good conduit to an existing
 >       authentication system. In particular, I think
 >       that marrying AAA with Kerberos would probably
 >       be a good thing (or more generally, allowing 
 >       for whatever EAP allows).
 > 
 > => I prefer the comment. I don't like Kerberos as the ultimate
 > answer for security (ie. I have at least as many concerns about
 > Kerberos as you have for AAA :-).

   Let me be explicit here: my concern is with
   using AAA for something it wasn't designed 
   for in a working group that is not frequented
   by people with security smarts and doesn't even
   have in its charter to solve these classes of
   problems. This has led to problems even where
   a solution for a very MIP related issue --
   BU's to CN's -- without grand ambitions of
   protocol reinvention got blindsided. FWIW, 
   the BU problem was apparent to me after my
   first reading of MIPv6 a year and a half ago...
   I had just assumed that it was obvious to
   everybody else and that the global PKI
   implications were something that the working
   group was willing to live with!

   I was serious when I told James that the
   proponents of using AAA as an alternate means
   of key distribution ought to have a BOF,
   leading potentially to a working group. It's
   possible that there's something new and
   problematic that AAA could solve better 
   even though I have my doubts. However, we'll
   never know until we open this up to an audience
   who has been through all of these arguments
   dozens of times and know the security landscape
   far better than anybody here (and I include
   myself).

 > => There is a big difference: AAA has an architecture, not only
 > because this is good a priori, but in order to not reinventing
 > Kerberos with its known weakness (don't scale, no hierarchy,
 > no distribution, ...).

   Actually, the addition of PKINIT and PKCROSS
   go a very long way to addressing the scaling
   issues. Since you will always going to run into
   the "global PKI" problem, that isn't really a
   Kerberos problem per se, it's a PKI problem.

		    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:27:33 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23657
	for ; Tue, 27 Mar 2001 12:27:33 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08294;
	Tue, 27 Mar 2001 09:26:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18967;
	Tue, 27 Mar 2001 09:26:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHP6Im006085
	for ; Tue, 27 Mar 2001 09:25:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHP6u9006084
	for mobile-ip-dist; Tue, 27 Mar 2001 09:25:06 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHOvIm006077
	for ; Tue, 27 Mar 2001 09:24:57 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06509
	for ; Tue, 27 Mar 2001 09:24:57 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12864
	for ; Tue, 27 Mar 2001 09:24:56 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00178
	for ; Tue, 27 Mar 2001 09:25:17 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE10886;
	Tue, 27 Mar 2001 09:24:53 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02897; Tue, 27 Mar 2001 09:24:53 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.52453.387167.290866@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 09:24:53 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Scalability [Was Re: [mobile-ip] Drafty draft about key ...
In-Reply-To: <3AC07CEE.BC5DF2C0@lmf.ericsson.se>
References: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com>
	<3ABF8825.8E51BE6E@nomadiclab.com>
	<3AC07CEE.BC5DF2C0@lmf.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

One quick clarification:

Jari Arkko writes:
 > * Memory consumption. Well, essentially an SA needs
 >   an SPI number (4 bytes), protocol (1 byte), secret
 >   (e.g. 16 bytes), various algorithm etc indicators
 >   (say 4 bytes), and maybe a couple of other things
 >   such as sequence numbers. So, in conclusion you
 >   could spend in the best case maybe some dozens
 >   of bytes, typical implementations perhaps use
 >   something in the order of a few hundred bytes
 >   at the worst. (Adding encryption algorithm that
 >   needs a large table to speed things up could
 >   set you up for an additional few kilobytes.)

     Yes. I believe that both twofish and rijndeal
     are about two orders of magnitude slower (maybe
     more, my memory is fuzzy) when you don't use the
     tables. For all practical purposes, you are 
     going to need the tables in all but very special
     cases (read: not IPsec).

		  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:30:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23793
	for ; Tue, 27 Mar 2001 12:30:51 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10206;
	Tue, 27 Mar 2001 09:29:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19719;
	Tue, 27 Mar 2001 09:29:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHSXIm006120
	for ; Tue, 27 Mar 2001 09:28:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHSXgb006119
	for mobile-ip-dist; Tue, 27 Mar 2001 09:28:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHSOIm006112
	for ; Tue, 27 Mar 2001 09:28:24 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19395
	for ; Tue, 27 Mar 2001 09:28:25 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15005
	for ; Tue, 27 Mar 2001 09:28:23 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RHSLd34026
	for ; Tue, 27 Mar 2001 18:28:22 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22578
	for ; Tue, 27 Mar 2001 19:28:21 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RHSLA78506
	for ; Tue, 27 Mar 2001 19:28:21 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271728.f2RHSLA78506@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
In-reply-to: Your message of Tue, 27 Mar 2001 10:58:11 MDT.
             <3AC0C6A3.107A6828@usa.alcatel.com> 
Date: Tue, 27 Mar 2001 19:28:20 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

     Another point: in IPv6 one of the RFCs was supposed to mandate
   binding cache for all corresponding hosts upon which Mobile IPv6 route
   optimization was built. Can someone tell us which RFC? I could not
   locate it.
   
=> no, the proposal is/was to make the support of the home address
destination option mandatory (this provides a direct MN->CN routing
without the ingress filtering issue). It is not in a RFC but in
Mobile IPv6 I-Ds (last is #13) with the definition of this option
and of the binding cache.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:35:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23859
	for ; Tue, 27 Mar 2001 12:35:11 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12028;
	Tue, 27 Mar 2001 09:33:59 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19262;
	Tue, 27 Mar 2001 09:33:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHWUIm006155
	for ; Tue, 27 Mar 2001 09:32:30 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHWUuY006154
	for mobile-ip-dist; Tue, 27 Mar 2001 09:32:30 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHWLIm006147
	for ; Tue, 27 Mar 2001 09:32:21 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20327
	for ; Tue, 27 Mar 2001 09:32:21 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10221
	for ; Tue, 27 Mar 2001 09:32:20 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15446;
	Tue, 27 Mar 2001 09:32:20 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2RHWJi06020;
	Tue, 27 Mar 2001 09:32:19 -0800
X-mProtect:  Tue, 27 Mar 2001 09:32:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdRMUl4y; Tue, 27 Mar 2001 09:32:07 PST
Message-ID: <3AC0CE97.A40A2CEA@iprg.nokia.com>
Date: Tue, 27 Mar 2001 09:32:07 -0800
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
References:  <3ABFC93F.C87E4EC6@iprg.nokia.com> <009c01c0b693$407aa0c0$6501a8c0@smateo1.sfba.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Paul,

>> I think this is premature.  We have only just recently gotten a clear picture
>> about what is needed from the standpoint of the IESG.  The Binding Update
>> message is, after all, what the mobile node sends to the Home Agent.
> 
> Though the IESG didn't say so in so many words, my distinct impression was
> that the issue is with the security association between MN and CN, not
> between MN and HA.  I don't think anyone is suggesting getting rid of the
> latter.  I certainly wasn't.  Am I wrong on this?

I am glad to hear you weren't suggesting getting rid of using
the Binding Update.  That was my reaction to your previous message,
and prompted my worried characterization of your suggestion as
an extensive rewrite.  So let's imagine keeping the Binding Update,
revised as necessary for use with a different authentication
mechanism (not AH).  That much is pretty straightforward, and
I've already done a lot of it.

> I don't know.  The IESG is suggesting a design team.  Sounds like a time
> comsuming process.  Also, Pekka's attack classification has like 15 attack
> capabilities and 10 attack scenarios.  Presumably this represents a minimum
> of the sort of analysis that has to be done on a new scheme.  I just don't
> finishing the process of designing another scheme happening any time soon.

My impression is that the design team was going to be pretty sharply
focussed on solving the problem at hand.  We have enough tools at
hand to be pretty effective, I think.  I hope that we don't have
to equate "design teams" with "committees", because the latter seem
to have an inglorious history.

> Charlie, if we assume that the existing method for establishing SAs and
> sending BUs between MN and HA remain the same as now, are you less opposed
> to the idea of just dropping the MN<>CN SA and BUs only?

To answer your question, yes that would be less problematic.  Nevertheless,
I am still very much persuaded that enabling direct communications between
IPv6 nodes (as much as possible) is quite important.

To put this discussion in context, let me make a quick summary of the
current situation:

- Last fall, a decision was taken to expedite the then-stalled
  Mobile IPv6 specification.  Engineers were polled, issues were
  raised, solutions were found, and interoperability was tested.

- All of these inputs were taken together as part of revising the
  specification.  This is the time-honored IETF process in action.

- The IESG raised concerns about key establishment with correspondent
  nodes.  It was thought that the current specification might be
  abused in such a way to engender a security vulnerability, because
  engineers _might_ (in the absence of any key establishment protocol)
  build network systems that did not securely check authentication.

- Last week, further discussion (centering on the idea of "First, do
  no harm") helped to clarify the technical requirements for what
  might be considered an acceptable key establishment protocol.
  Ideas have been floated (including PBK and my drafty draft) that
  could meet the requirement.  As I understand it, the requirement
  can be stated as not introducing any vulnerability not already
  present between two non-moving network nodes in the Internet today.

- A design team is to look at the problem(s), propose a solution, and
  make sure it fits the requirement(s).  I'm pretty sure we can do
  it if the scope of the problem is narrowly defined.

So what I see is that we've changed the base specification from stalled
into almost done, and now we are in the process of meeting some challenging
guidelines from the IESG that weren't clearly enough articulated
until recently.  In fact, the basic specification needs to be slightly
retooled to avoid AH no matter what, and to revise the renumbering
section.  The new stuff about key establishment would properly fit
in a new draft, I think.  I know life doesn't have to be fair, but
anyway we should be cognizant of how close we are to the solution
most people seem to want in the end.

We should continue the considerable forward momentum we have now for at
least a few more weeks before stepping back and re-evaluating.  And, I
think that even after that point any such re-evaluation should be carried
out with the benefit of a great deal of consideration to what has gone
before.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 12:40:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23984
	for ; Tue, 27 Mar 2001 12:40:56 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16867;
	Tue, 27 Mar 2001 09:39:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21888;
	Tue, 27 Mar 2001 09:39:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHcTIm006192
	for ; Tue, 27 Mar 2001 09:38:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHcSNH006191
	for mobile-ip-dist; Tue, 27 Mar 2001 09:38:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHcKIm006184
	for ; Tue, 27 Mar 2001 09:38:20 -0800 (PST)
Received: from locked (locked.Eng.Sun.COM [129.146.85.189])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2RHcHxf342820;
	Tue, 27 Mar 2001 09:38:17 -0800 (PST)
Message-Id: <200103271738.f2RHcHxf342820@jurassic.eng.sun.com>
Date: Tue, 27 Mar 2001 09:37:02 -0800 (PST)
From: Mohan Parthasarathy 
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
To: paul@francis.com, mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: D6UMaiXUcgKKgw84JuJQpA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 

> >
> >
> > > Just to play the Devil's advocate, is mobility important by itself, or
> only
> > > with route optimization?
> >
> > "Mobility" is "more important" than "route optimization".  But allowing
> > the correspondent node to send packets to a mobile node, and (just as
> > important) getting the home agent out of the typical routing path, is an
> > important aspect of the scalability of the protocol.
> 
> Not if the HA is already in or close to in the normal route the packet would
> otherwise take (i.e., "Nearby HA Route Optimization").
> 
I am not sure i understand this completely. Does this mean the home
address of the MN changes at it potentially moves across various
domains ? Or whenever the "distance" increases you would find
a near by HA ?

> >
> > I think this is premature.  We have only just recently gotten a clear
> picture
> > about what is needed from the standpoint of the IESG.  The Binding Update
> > message is, after all, what the mobile node sends to the Home Agent.
> 
> Though the IESG didn't say so in so many words, my distinct impression was
> that the issue is with the security association between MN and CN, not
> between MN and HA.  I don't think anyone is suggesting getting rid of the
> latter.  I certainly wasn't.  Am I wrong on this?
> 
> >
> > Again, a good solution is, I think, within reach.
> >
> 
> I don't know.  The IESG is suggesting a design team.  Sounds like a time
> comsuming process.  Also, Pekka's attack classification has like 15 attack
> capabilities and 10 attack scenarios.  Presumably this represents a minimum
> of the sort of analysis that has to be done on a new scheme.  I just don't
> finishing the process of designing another scheme happening any time soon.
> 
That's why we should use whatever we have today and not pretend to solve
all the problems. Then we don't have to reinvent everything and the 
security analysis becomes simpler assuming somebody has already done
a good amount of analysis on the existing solutions. I think finally
it boils down to the question "How secure the binding updates should
be " ?

-mohan

> Charlie, if we assume that the existing method for establishing SAs and
> sending BUs between MN and HA remain the same as now, are you less opposed
> to the idea of just dropping the MN<>CN SA and BUs only?



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 13:00:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24515
	for ; Tue, 27 Mar 2001 13:00:34 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26373;
	Tue, 27 Mar 2001 09:59:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26200;
	Tue, 27 Mar 2001 09:59:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHvcIm006230
	for ; Tue, 27 Mar 2001 09:57:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RHvbk9006229
	for mobile-ip-dist; Tue, 27 Mar 2001 09:57:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RHvTIm006222
	for ; Tue, 27 Mar 2001 09:57:29 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25948
	for ; Tue, 27 Mar 2001 09:57:29 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21241
	for ; Tue, 27 Mar 2001 09:57:28 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2RHvQd44543
	for ; Tue, 27 Mar 2001 18:57:27 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA23248
	for ; Tue, 27 Mar 2001 19:57:26 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2RHvPA78708
	for ; Tue, 27 Mar 2001 19:57:25 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103271757.f2RHvPA78708@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update) 
In-reply-to: Your message of Tue, 27 Mar 2001 09:19:27 -0800.
             <15040.52127.930379.143697@thomasm-u1.cisco.com> 
Date: Tue, 27 Mar 2001 19:57:25 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

      Let me be explicit here: my concern is with
      using AAA for something it wasn't designed 
      for in a working group that is not frequented
      by people with security smarts

=> is it a working group problem or a "people with security
smarts" problem? I believed the first A of AAA stood for
authentication and the second for authorization...

      and doesn't even have in its charter to solve
      these classes of problems.

=> I believe there is some misunderstanding: I say AAA provides
authentication and authorization, you say it doesn't provide
key distribution...

      This has led to problems even where
      a solution for a very MIP related issue --
      BU's to CN's -- without grand ambitions of
      protocol reinvention got blindsided.

=> BUs to CNs is not in the scope of AAA: AAA is for local network access
control and MN to HA security (look at RFC 2977).

      FWIW, 
      the BU problem was apparent to me after my
      first reading of MIPv6 a year and a half ago...
      I had just assumed that it was obvious to
      everybody else and that the global PKI
      implications were something that the working
      group was willing to live with!
   
=> this problem was known but the new fact is that the global PKI is
something not desirable...

      Since you will always going to run into
      the "global PKI" problem, that isn't really a
      Kerberos problem per se, it's a PKI problem.
   
=> I agree: no protocol will provide authentication between
two random Internet nodes without solving first this problem.
So now (as we heard this problem cannot/should not be solved)
Mobile IPv6 people look at AAA for authentication in some domains
(typically local/visited and home/remote domains) as *an option*
and weak security (which meets minimal requirements, but not too weak)
for random correspondents.
 The problem is to remove some stupid MITMs (but not all because it is
not possible without a global PKI, this seems not to be too difficult) and
DoS vulnerabilities (*harder*). A security threat document is supposed
to help us too (look at draft-glass-mobileip-security-issues-00.txt
but many sections are TBDs).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 13:07:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24739
	for ; Tue, 27 Mar 2001 13:07:51 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13889;
	Tue, 27 Mar 2001 10:06:43 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27339;
	Tue, 27 Mar 2001 10:06:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI4dIm006329
	for ; Tue, 27 Mar 2001 10:04:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RI4ceS006328
	for mobile-ip-dist; Tue, 27 Mar 2001 10:04:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RI4JIm006317
	for ; Tue, 27 Mar 2001 10:04:19 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2RI4Hxf348105;
	Tue, 27 Mar 2001 10:04:18 -0800 (PST)
Message-Id: <200103271804.f2RI4Hxf348105@jurassic.eng.sun.com>
Date: Tue, 27 Mar 2001 10:05:18 -0800 (PST)
From: Samita Chakrabarti 
Subject: Re: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode
To: mobile-ip@sunroof.eng.sun.com, Hesham.Soliman@era.ericsson.se
Cc: Karim.El-Malki@era.ericsson.se, ludovic.bellier@inria.fr,
        claude.castelluccia@inria.fr, james.kempf@eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: aceGaM5qeYpzW5VNU7SlWg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Hesham,

> > Also, I'd like to propose a third mode in hmipv6 especially
> > for those systems which do not have ROHC implementation
> > at their network.
> > 
> > Thus this proposed mode will save 40 bytes of tunnel overhead
> > between MAP and mobile node in the basic mode. 
> > 
> 	=> It can be used for both modes.
> 

Yes, in can be, but it's more easily applicable in basic mode. 
> > 
> 	=> The load balancing will be placed in a separate
> 	draft that is generic for (H)MIPv6. Your comments will
> 	be included.
> 	This was requested by a few people in te WG to reduce 
> 	the scope of the draft.
> 

Sounds fine.


> 
> > Section 15:   Reference for AAAv6 should be recorded.
> > 
> 	=> recorded ? I didn't get that, please explain.
> 
Oops! I just meant a reference pointer for the AAAv6 draft or document.


> > Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical 
network where
> > ROHC is not available.
> > 
> > Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels 
between MAP and MN
> >          
> > MAP Operation: 
> >            In this mode, MAP recives BU and sends BAck after performing DAD 
operation
> >            as described in basic mode. A new bit will be introduced in the 
MAP advertisement
> >            to distinguish "Basic non-tunnel" mode service from other two 
modes.
> > 
> >       The new MAP option format ( as per discussion with Hesham Soliman):
> > 
> > 
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |     Type      |    Length     |  Distance     |  Pref         |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |     Plen      |R|M|T|N|            Reserved                   |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         Valid Lifetime                        |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                                                               |
> >       +                                                               +
> >       |                                                               |
> >       +                  Global IP Address for MAP                    +
> >       |                                                               |
> >       +                                                               +
> >       |                                                               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >           N  - Indicates that the MN MUST be able to replace the destination
> >                address of incoming packet from LCOA to RCOA when the packets
> >                are coming from either a correspondent node or it's home 
agent.
> >                R bit MUST be set when N bit is set. N bit MUST not be set
> >                when M is bit is set. Basicaly N bit is an indication of MAP
> >                supporting basic-non-tunnel mode.
> > 
> >            The MAP keeps a binding cache containing association
> >            of RCOA, LCOA and MN's home-addr. It intercepts the packets that 
are destined> 
> >            to RCOA (either from HA or from CN. Note that in basic mode RCOA 
is different
> >            from MAP's own address.) MAP then replaces the destination > 
IP-address RCOA by
> >            LCOA after looking up the binding cache, and simply forwards the 
packet to
> >            the topologically correct router in the hierarchy.
> > 
> > MN Operations:
> >          
> >            MN forms LCOA and RCOA exactly the same way as described in basic 
mode. It also
> >            sends BU to MAP and home agent subsequently exactly the same way 
as described
> >            in 6.1 (Basic mode MN operations). MN may also send BU to CN 
informing RCOA as
> >            it's new COA ( same as in basic-mode operation).
> > 
> >            MN receives packets addressed to MN's LCOA address, MN replaces 
the LCOA address
> >            by the corresponding RCOA address after determining that this 
packet is
> >            coming from either it's home agent or correspondent node. MN then 
proceeds
> >            with normal processing of packets as described in base mobile 
IPv6 draft.
> > 
> >            The differnce between basic mode MN and basic-non-tunnel mode MN 
is that
> >            the latter, does not need to detunnel the packet from MAP at all. 
Instead it
> >            swaps the destination address of the incoming  packet when the
> >            source address is home agent address or  correspondent node 
address.
> >            Thus a mobile node implementation may maintain a list of CNs and
> >            Home agents for address verification.
> > 
> > HA Operation:
> >            No change from basic mode operation.
> > 
> > 
--------------------------------------------------------------------------------
--------
> > 
> 	=> As I mentioned earlier, this would work at a cost of 
> 	more complexity in the MN. 
> 	Since, ROHC (or other HC techniques) are used 
> 	in all "BW-challenged" links, I'm inclined to think
> 	that this should be placed in a separate draft. 
> 	As you know several people have mentioned that 
> 	the draft is doing too much and we're working 
> 	on that. 
> 	I believe James' comments was related to context 
> 	transfer which is handled by seamoby. After 
> 	reading Mikael Degermark's (co-chair of ROHC) emails 
> 	I'm now convinced that this would work fine. 
> 
> 	So to summarise, I think your proposal would 
> 	work and I (and the rest of the co-authors)
> 	would be more than happy to assist you in any 
> 	way if you would like to write another draft that 
> 	addresses this optimisation for HMIPv6. 
> 
> 	Finally, I would strongly recommend that you 
> 	consult with the IPng folks as this solution
> 	requires some special tricks in the implementation
> 	and IPng is the best place to get feedback on 
> 	this.
> 
I thought, at IETF we agreed on this solution :)
I am not sure if this  option should go into a separate draft.
But, we can discuss more. Regarding IPng folks, I think many IPng
folks are also in this working group.

> 	We're not saying it's not important,but simply 
> 	responding to the WG's comments about the 
> 	size/scope of the draft

If you include the third option as an optional mode, that will give
flexibility to the implementors to choose to implement this option.
When 3GPP and 3GPP2 systems implement ROHC, I understand that then
this option will be redundant. But, I'd argue that, for now this
option saves 40 bytes of overhead and is useful for systems which
does not implement header compression (ROHC).  I am not saying that
this option is "MUST", but optional, in addition to the basic mode.
Also, this is in scope of hmipv6 draft.

Thanks,
-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 13:38:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25528
	for ; Tue, 27 Mar 2001 13:38:52 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10774;
	Tue, 27 Mar 2001 10:27:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01882;
	Tue, 27 Mar 2001 10:27:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIPPIm006476
	for ; Tue, 27 Mar 2001 10:25:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RIPORX006475
	for mobile-ip-dist; Tue, 27 Mar 2001 10:25:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIPGIm006468
	for ; Tue, 27 Mar 2001 10:25:16 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2RIPAxf352083;
	Tue, 27 Mar 2001 10:25:11 -0800 (PST)
Message-Id: <200103271825.f2RIPAxf352083@jurassic.eng.sun.com>
Date: Tue, 27 Mar 2001 10:26:11 -0800 (PST)
From: Samita Chakrabarti 
Subject: [mobile-ip] Re: Comments on hmipv6 draft and a proposal on a third mode
To: claude.castelluccia@inrialpes.fr
Cc: mobile-ip@sunroof.eng.sun.com, samita@jurassic.Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: joqQ46GZFFZd2aBXtJRXKw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Claude,

> Concerning the third mode proposal, i have 3 comments:
> 
> -in the basic mode, the MAP is nothing more that a HA.  This was one of our 
requirements
> when designing this mode. The basic mode is very simple to implement... adding 
the
> fonctionality
> you are proposing would require to modify the MAP and we won't be able to use 
a HA as MAP
> anymore...
> 

That's not completely true. Because a MAP implementation needs to send MAP
advertisements and process MAP registration. A simple mobileIPv6 HA is not
capable of doing MAP's work. 

> -in your proposal, the MAP modifies the destination address of the packets 
that are sent to a
> Mobile host.
> What will happen if the packet is authenticated with AH? The packets will be 
rejected by the
> MN. This
> is an issue when the CN is also mobile and piggybacks  its BUs with its 
packets (the whole
> packets must then be
> authenticated with AH) ...
> 

This will not be a problem becuase MN now is 
intelligent enough to use RCOA to caculate ICV part of AH header.

When the packet is received by MN  from CN using route optimization:

 LCOA     <===== IP dst (replaced by MAP from the binding cache info)
 CN
 ----
 Home-addr    <--- Routing header
 
 
 When MN sees that there is routing header from CN,
 it  does the following steps:
  1. Uses RCOA instead of LCOA for AH validity computation.
     Note, in order to compute the ICV of AH correctly, MN must
     have the key from security association with CN and it needs
     the right set of parameters, namely src, dst addresses.
     
     If this is a spoof packet, then even though it has same src/dst
     address it's AH value will not be the same as the real packet.
     In another words, this has no worse security threat than the 
     regular IPsecv6.
     
   2. After the AH computation, it processes router header and then
      replaces LCOA with Home-addr and passes up exactly the same 
      way as mobileipv6 main draft says.

> - Most of wireless networks will use RoHC (as confirmed by Hesham email) so I 
don't see the
> motivation
> for this 3rd mode (considering the 2 previous issues).
> 

I thought, it will be useful for implementations which do not have ROHC
implementation today. 

Thanks very much,
-Samita


> 
> 
> 
> Samita Chakrabarti wrote:
> 
> > Hello:
> >
> > Sorry for the late posting... But  most of the comments have been discussed 
with
> > hmipv6 authors in private emails.
> >
> > The comments are based  mostly on hmipv6 version 2 draft.
> > Also, I'd like to propose a third mode in hmipv6 especially
> > for those systems which do not have ROHC implementation
> > at their network.
> > Thus this proposed mode will save 40 bytes of tunnel overhead
> > between MAP and mobile node in the basic mode. I understand that
> > this would be useful for IPRAN  as James Kempf had pointed out
> > earlier in the list.
> >
> > Editorial comments:
> >
> > section 3.0 : one or two word description of 'B' flag would be helpful
> >
> > section 3.1 : Load-balancing sub-option : needs more clarification as to 
where the
> >               sub-option is sent ( to MAP only or CN as well ?)
> >               Load-balancing may be a misnomer, perhaps a more suitable name 
should
> >               be used as this option basically is used by the MN for 
balancing load
> >               over different interfaces. But the load-balancing is dependent 
on the
> >               flow policies. So, how about "Policy" sub-option or other 
suitable names ?
> >
> >               How about changing 'prot number' to 'proto number' ?
> >               Needs description for dest-port, r and Destination address, I 
suppose
> >               destination address should be LCOA
> >
> >               'P' bit description should clarify which "ip-address" (LCOA?) 
is used
> >                to identify flow.
> >
> >                Since checking for flow-label or port-ipaddr pair also 
involve checking
> >                each packet at MAP, 'per-packet' load balancing description 
is a bit
> >                confusing in this context. Since 'per-packet' load-balancing 
refers to
> >                'A' bit only, another beeter name or more clarification 
required here.
> >
> > Section 4.0    An example of 'T' bit would help
> >
> > Section 5.0    A little more detailed analysis of choices of MAP discovery 
will be
> >                a good guide for implementors and users to pick which one to 
pick
> >                in their implementation/operating environment.
> >
> >
> > Section 5.4:   3rd paragraph mentions :
> >                "If a MN has access to several ARs.......it's current MAP"
> >                an example will be helpful in order to describe this 
scenario.
> > Section 11:    Needs more clarification ( I was told that version 3 has 
improved texts)
> >
> > Section 15:   Reference for AAAv6 should be recorded.
> >
> > Technical :
> > ----------
> >  (Some of the following are discussed with hmipv6 authors)
> >
> > Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
> >                Next version of draft should also specify possible error 
codes--
> >                at least the 'errors in text form'.
> >
> > Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP 
discovery
> >               and specify one or two options as 'MUST' to implement. 
Otherwise,
> >               implementations either will become too complex or will not 
interoperate.
> >
> > Section 6.1 : Please specify that alternate COA sub-option is optional when 
RCOA is
> >               used as source address of the BU. (for location privacy)
> >
> > Section 11 : This section should also mention that the hierarchical network 
between
> >              MAP and MNs must be a trusted network and no src-address 
filtering is done
> >              on the outging packets from the mobile nodes.
> >
> > Section 7.1 and 7.2 :
> >               Added operation in HA can be easily avoided if :
> >               A MN MUST (instead of SHOULD) send a BU for each different 
Home-addr it
> >               uses for connection.
> >
> >               But I think, having HA to add RH in the outer IP layer, has 
two
> >               advantages:
> >
> >               1) less signalling between MN and AR ( this is probably 
desirable by
> >                  wirelss vendors)
> >
> >               2) Supporting site-local addressed home-addr in the foreign 
domain.
> >
> > Load Balancing in general:
> > BTW, a detailed load balancing scheme for fault-tolerance for MAP should be 
schetched
> > out so that the backup MAP can takes over when the orginial MAP goes down. 
Perhaps the
> > policy and MAP load babalncing scenarios should be discussed in a separate 
draft to
> > keep this draft simple. But we can toss ideas and discuss more on that in 
the
> > discussion team.
> >
> > Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical 
network where
> > ROHC is not available.
> >
> > Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels 
between MAP and MN
> >
> > MAP Operation:
> >            In this mode, MAP recives BU and sends BAck after performing DAD 
operation
> >            as described in basic mode. A new bit will be introduced in the 
MAP advertisement
> >            to distinguish "Basic non-tunnel" mode service from other two 
modes.
> >
> >       The new MAP option format ( as per discussion with Hesham Soliman):
> >
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |     Type      |    Length     |  Distance     |  Pref         |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |     Plen      |R|M|T|N|            Reserved                   |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         Valid Lifetime                        |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                                                               |
> >       +                                                               +
> >       |                                                               |
> >       +                  Global IP Address for MAP                    +
> >       |                                                               |
> >       +                                                               +
> >       |                                                               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >           N  - Indicates that the MN MUST be able to replace the destination
> >                address of incoming packet from LCOA to RCOA when the packets
> >                are coming from either a correspondent node or it's home 
agent.
> >                R bit MUST be set when N bit is set. N bit MUST not be set
> >                when M is bit is set. Basicaly N bit is an indication of MAP
> >                supporting basic-non-tunnel mode.
> >
> >            The MAP keeps a binding cache containing association
> >            of RCOA, LCOA and MN's home-addr. It intercepts the packets that 
are destined
> >            to RCOA (either from HA or from CN. Note that in basic mode RCOA 
is different
> >            from MAP's own address.) MAP then replaces the destination 
IP-address RCOA by
> >            LCOA after looking up the binding cache, and simply forwards the 
packet to
> >            the topologically correct router in the hierarchy.
> >
> > MN Operations:
> >
> >            MN forms LCOA and RCOA exactly the same way as described in basic 
mode. It also
> >            sends BU to MAP and home agent subsequently exactly the same way 
as described
> >            in 6.1 (Basic mode MN operations). MN may also send BU to CN 
informing RCOA as
> >            it's new COA ( same as in basic-mode operation).
> >
> >            MN receives packets addressed to MN's LCOA address, MN replaces 
the LCOA address
> >            by the corresponding RCOA address after determining that this 
packet is
> >            coming from either it's home agent or correspondent node. MN then 
proceeds
> >            with normal processing of packets as described in base mobile 
IPv6 draft.
> >
> >            The differnce between basic mode MN and basic-non-tunnel mode MN 
is that
> >            the latter, does not need to detunnel the packet from MAP at all. 
Instead it
> >            swaps the destination address of the incoming  packet when the
> >            source address is home agent address or  correspondent node 
address.
> >            Thus a mobile node implementation may maintain a list of CNs and
> >            Home agents for address verification.
> >
> > HA Operation:
> >            No change from basic mode operation.
> >
> > 
--------------------------------------------------------------------------------
--------
> >
> > Thanks,
> > -Samita
> 
> --
> 
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 13:56:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26141
	for ; Tue, 27 Mar 2001 13:56:39 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26734;
	Tue, 27 Mar 2001 10:55:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08559;
	Tue, 27 Mar 2001 10:55:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIrNIm006589
	for ; Tue, 27 Mar 2001 10:53:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RIrNAC006588
	for mobile-ip-dist; Tue, 27 Mar 2001 10:53:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIrEIm006581
	for ; Tue, 27 Mar 2001 10:53:14 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09775
	for ; Tue, 27 Mar 2001 10:53:14 -0800 (PST)
Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA10255
	for ; Tue, 27 Mar 2001 10:53:13 -0800 (PST)
Received: (cpmta 5813 invoked from network); 27 Mar 2001 10:53:12 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.65) with SMTP; 27 Mar 2001 10:53:12 -0800
X-Sent: 27 Mar 2001 18:53:12 GMT
Message-ID: <006801c0b6ef$1f3cef60$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <15040.44291.238997.780414@thomasm-u1.cisco.com> <15040.45180.381408.299660@thomasm-u1.cisco.com>
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Tue, 27 Mar 2001 10:52:45 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
>  > Of course, this mandates AAA for (scalable) MIPv6, which is probably
not a
>  > good thing.
>
>    Amongst other things. Anything that posits DNS
>    as being a real time transaction system is dead
>    in the water.
>

I'm not suggesting that DNS be updated for this.  I'm not suggesting
anything different from what we can do today with IPv4 (for the time being).

I'm not suggesting we need a new AAA infrastructure.

I'm not suggesting DynDNS.

I'm not suggesting we stop pursueing true route optimization.

All I'm saying is that we move forward with a simple form of MIPv6 that
provides us with no more capability than we have today with MIPv4.  When you
roam and authenticate with the local AAA infrastrucuture (PPP and RADIUS and
CHAP or whatever protocols and infrastructure is already out there today),
you get assigned an address that ties you to a local HA.  When you are
mobile, traffic still goes through the local HA.  Your A6 records are not
updated, so if you want to act as a server, then it must be through your
true original HA (not local HA).  (Hmmmm, does MIPv6 today allow for the
possibility of multiple HAs?  If not, then rather than add functionality for
that, better to say that for the time being that the MN cannot act as a
server.)  If you are running SIP, and you do a SIP REGISTER with the address
of your local HA, then parties calling you can go through your local HA.

Lets not go down the rat-hole of trying to perfect a partial and temporary
solution.  If the temporary solution isn't dead simple, then there is no
point in pursuing it.

PF





From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 13:57:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26170
	for ; Tue, 27 Mar 2001 13:57:02 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27138;
	Tue, 27 Mar 2001 10:55:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08691;
	Tue, 27 Mar 2001 10:55:46 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIs1Im006601
	for ; Tue, 27 Mar 2001 10:54:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RIs1aV006600
	for mobile-ip-dist; Tue, 27 Mar 2001 10:54:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RIrlIm006591
	for ; Tue, 27 Mar 2001 10:53:48 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09886
	for ; Tue, 27 Mar 2001 10:53:42 -0800 (PST)
Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA19885
	for ; Tue, 27 Mar 2001 10:53:42 -0800 (PST)
Received: (cpmta 3976 invoked from network); 27 Mar 2001 10:53:41 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.72) with SMTP; 27 Mar 2001 10:53:41 -0800
X-Sent: 27 Mar 2001 18:53:41 GMT
Message-ID: <006c01c0b6ef$30a78da0$2000a8c0@dellchan>
From: "Paul Francis" 
To: , "Thomas Narten" 
References: <200103192226.f2JMQUH23623@locked.eng.sun.com>
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
Date: Tue, 27 Mar 2001 10:53:19 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> 
> > The WG is encouraged to look at the ID
> > http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> > It was developed specifically as an alternate approach to addressing
> > the problems discussed in this note.
> >
> But this does not address the above problem which is important.
> draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP

Why doesn't pbk solve the problem? 

PF





From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 14:04:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26385
	for ; Tue, 27 Mar 2001 14:04:43 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04186;
	Tue, 27 Mar 2001 11:03:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10960;
	Tue, 27 Mar 2001 11:03:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJ25Im006649
	for ; Tue, 27 Mar 2001 11:02:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RJ25kU006648
	for mobile-ip-dist; Tue, 27 Mar 2001 11:02:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJ1uIm006641
	for ; Tue, 27 Mar 2001 11:01:57 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10510
	for ; Tue, 27 Mar 2001 11:01:56 -0800 (PST)
Received: from newman.gte.com ([132.197.8.26])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24463
	for ; Tue, 27 Mar 2001 11:01:56 -0800 (PST)
Received: from rcmppc2 (rcmppc2.gte.com [132.197.73.30])
	by newman.gte.com (8.9.1/8.9.1) with ESMTP id OAA29239
	for ; Tue, 27 Mar 2001 14:01:55 -0500 (EST)
Message-Id: <4.2.0.58.20010327140052.00aa9330@127.0.0.1>
X-Sender: sjj0/pophost.gte.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Mar 2001 14:02:38 -0500
To: mobile-ip@sunroof.eng.sun.com
From: Stuart Jacobs 
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
In-Reply-To: <006c01c0b6ef$30a78da0$2000a8c0@dellchan>
References: <200103192226.f2JMQUH23623@locked.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

IMHO the pbk is a specific example of a special pki oriented just for 
something like MIP.  I would go farther and say the if these pbkeys were 
kept in certificates then they could also be used to initially authenticate 
entities.

Stu

At 3/27/01 10:53 AM, you wrote:
> >
> > > The WG is encouraged to look at the ID
> > > http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
> > > It was developed specifically as an alternate approach to addressing
> > > the problems discussed in this note.
> > >
> > But this does not address the above problem which is important.
> > draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
>
>Why doesn't pbk solve the problem?
>
>PF
>
>

==========================
Stuart Jacobs CISSP
Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
stu.jacobs@verizon.com     sjj0@gte.com
==========================


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 15:10:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28164
	for ; Tue, 27 Mar 2001 15:10:25 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00677;
	Tue, 27 Mar 2001 12:09:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29835;
	Tue, 27 Mar 2001 12:09:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RK6OIm006864
	for ; Tue, 27 Mar 2001 12:06:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RK6O9h006863
	for mobile-ip-dist; Tue, 27 Mar 2001 12:06:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RK6CIm006848
	for ; Tue, 27 Mar 2001 12:06:12 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28390
	for ; Tue, 27 Mar 2001 12:06:12 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29201
	for ; Tue, 27 Mar 2001 12:06:10 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09242
	for ; Tue, 27 Mar 2001 12:06:10 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE16041;
	Tue, 27 Mar 2001 12:06:08 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02925; Tue, 27 Mar 2001 12:06:08 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.62128.681562.462124@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 12:06:08 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 security issues:  how to move forward
In-Reply-To: <006801c0b6ef$1f3cef60$2000a8c0@dellchan>
References: <15040.44291.238997.780414@thomasm-u1.cisco.com>
	
	<15040.45180.381408.299660@thomasm-u1.cisco.com>
	<006801c0b6ef$1f3cef60$2000a8c0@dellchan>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Paul Francis writes:
 > >  > Of course, this mandates AAA for (scalable) MIPv6, which is probably
 > not a
 > >  > good thing.
 > >
 > >    Amongst other things. Anything that posits DNS
 > >    as being a real time transaction system is dead
 > >    in the water.
 > >
 > 
 > I'm not suggesting that DNS be updated for this.  I'm not suggesting
 > anything different from what we can do today with IPv4 (for the time being).

   Well, one of the things I can do with IP4 today
   is send a SYN to a web server based upon a DNS
   A record lookup. If you localize the HA in the
   visited network, how does that SYN get there
   without going through my home subnet? 

   I hope that you're not suggesting that the mobile
   server problem is not as important, because that
   makes SIP UA's pretty hard to implement.

 > Lets not go down the rat-hole of trying to perfect a partial and temporary
 > solution.  If the temporary solution isn't dead simple, then there is no
 > point in pursuing it.

   That's fine by me. I'm afraid that we're not
   going to find a simple temporary solution though.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 15:44:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29105
	for ; Tue, 27 Mar 2001 15:44:05 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29840;
	Tue, 27 Mar 2001 12:43:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27197;
	Tue, 27 Mar 2001 12:43:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RKdKIm006981
	for ; Tue, 27 Mar 2001 12:39:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RKdKqm006980
	for mobile-ip-dist; Tue, 27 Mar 2001 12:39:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RKd2Im006973
	for ; Tue, 27 Mar 2001 12:39:06 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03113
	for ; Tue, 27 Mar 2001 12:38:05 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12994
	for ; Tue, 27 Mar 2001 12:38:04 -0800 (PST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 27 Mar 2001 14:21:39 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 27 Mar 2001 14:21:25 -0600
Message-ID: <9A9367D1556AD21182C40000F80930AB025E56CD@crchy28b.us.nortel.com>
From: "Mohamed Khalil" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] length field
Date: Tue, 27 Mar 2001 14:21:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B6FB.7D00B9E0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B6FB.7D00B9E0
Content-Type: text/plain;
	charset="iso-8859-1"

All,

to remove the confusion of interpreting the meaning of the length field in
MIER and GNAI, we will change the definition slightly  as follows:

MIER:

Length 
 
   8-bit unsigned integer. Length of the extension, in octets,
   excluding the extension Type and the extension Length fields.
   This field MUST be set to 1 plus the total length of the data field.

GNAI:

Length

   8-bit unsigned integer. Length of the extension, in octets,
   excluding the extension Type and the extension Length fields.
   This field MUST be set to 1 plus the total length of the NAI field.



MK



   




------_=_NextPart_001_01C0B6FB.7D00B9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






length field




All,




to remove the confusion of interpreting the meaning =
of the length field in MIER and GNAI, we will change the definition =
slightly  as follows:



MIER:




Length 

 

   8-bit unsigned integer. Length of the =
extension, in octets,

   excluding the extension Type and the =
extension Length fields.

   This field MUST be set to 1 plus the =
total length of the data field.




GNAI:




Length




   8-bit unsigned integer. Length of the =
extension, in octets,

   excluding the extension Type and the =
extension Length fields.

   This field MUST be set to 1 plus the =
total length of the NAI field.








MK








   









------_=_NextPart_001_01C0B6FB.7D00B9E0--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 16:09:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29754
	for ; Tue, 27 Mar 2001 16:09:21 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25534;
	Tue, 27 Mar 2001 13:08:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12065;
	Tue, 27 Mar 2001 13:08:40 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RL6iIm007127
	for ; Tue, 27 Mar 2001 13:06:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RL6iBK007126
	for mobile-ip-dist; Tue, 27 Mar 2001 13:06:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RL6WIm007119
	for ; Tue, 27 Mar 2001 13:06:35 -0800 (PST)
Received: from lillen (d-mpk17-85-194.Eng.Sun.COM [129.146.85.194])
	by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id XAA03449;
	Tue, 27 Mar 2001 23:06:29 +0200 (MET DST)
Date: Tue, 27 Mar 2001 13:06:26 -0800 (PST)
From: Erik Nordmark 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
To: mobile-ip@sunroof.eng.sun.com
Cc: Pekka Nikander 
In-Reply-To: "Your message with ID" <200103270939.f2R9ddA76136@givry.rennes.enst-bretagne.fr>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> => we can do something better: send a part of needed things directly
> to the care-of address and the remainder to the home address (through
> the home agent) so the MN will need to get the traffic from both paths
> (and the MITM will need to intercept the traffic on both paths).

While such complexity helps for some threats it doesn't deal with
MITM positioned close to the CN.
But we can't do much about that threat since the CN doesn't have any 
prestablished association with the HA or MN.

The most important threat to handle (that we can handle) is MITM
attacks on the MNs link.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 16:51:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01044
	for ; Tue, 27 Mar 2001 16:51:36 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14775;
	Tue, 27 Mar 2001 13:51:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20905;
	Tue, 27 Mar 2001 13:50:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLnAIm007299
	for ; Tue, 27 Mar 2001 13:49:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RLnADY007298
	for mobile-ip-dist; Tue, 27 Mar 2001 13:49:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLmxIm007284
	for ; Tue, 27 Mar 2001 13:48:59 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18388
	for ; Tue, 27 Mar 2001 13:48:58 -0800 (PST)
Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA15178
	for ; Tue, 27 Mar 2001 13:48:58 -0800 (PST)
Received: (cpmta 10617 invoked from network); 27 Mar 2001 13:48:57 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.72) with SMTP; 27 Mar 2001 13:48:57 -0800
X-Sent: 27 Mar 2001 21:48:57 GMT
Message-ID: <01bb01c0b707$a78f14c0$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <200103271707.f2RH7nA78291@givry.rennes.enst-bretagne.fr>
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward 
Date: Tue, 27 Mar 2001 13:48:26 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Ok, thanks for the explanation.  I'll read the draft again too.  Last I read
it, it was at the same time as reading a bunch of other drafts, and its all
muddled in my head.

PF


>
> => argh! I've reread the last I-D about HMIPv6:
>  - in basic mode you have just to bind the proper/better RCoA and
>    the traffic will be optimized routed through the corresponding MAP
>  - the extended mode does essentially the same thing (just replace
>    the RCoA by an alternate-COA).
> Claude or Hersham should be able to explain more and more clearly...
>





From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 16:58:26 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01257
	for ; Tue, 27 Mar 2001 16:58:25 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28094;
	Tue, 27 Mar 2001 13:58:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14963;
	Tue, 27 Mar 2001 13:57:50 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLu4Im007332
	for ; Tue, 27 Mar 2001 13:56:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RLu4KD007331
	for mobile-ip-dist; Tue, 27 Mar 2001 13:56:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RLtrIm007324
	for ; Tue, 27 Mar 2001 13:55:53 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14442
	for ; Tue, 27 Mar 2001 13:55:52 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26349
	for ; Tue, 27 Mar 2001 13:55:51 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2RLtod12542
	for ; Tue, 27 Mar 2001 23:55:50 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Mar 27 23:55:49 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 23:51:37 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDC@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'James Kempf'" ,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 ,
        ludovic.bellier@inria.fr
Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode
Date: Tue, 27 Mar 2001 23:55:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

James, 


> >
> >> I understand that
> >> this would be useful for IPRAN  as James Kempf had pointed out 
> >> earlier in the list.
> >> 
> >	=> Not really, all IP based cellular systems will use ROHC
> >	or something equivalent. To be more specific 3GPP will
> >	and I believe 3GPP2 is making (or has made a similar 
> >	decision). 
> >
> 
> Neither 3GPP nor 3GPP2 currently has all IP RANs. 3GPP2 is discussing
> whether to start work on a new all IP RAN architecture. 3GPP, having
> just completed the UTRAN architecture, has so far declined to
> investigate all IP RAN, being content with introducing IP as an
> alternate transport layer protocol.
> 
> That said, I agree that header compression will likely play a role
> even in an all IP RAN. 
> 
	=> All IP RAN (at least in 3GPP) means IP transport, user 
	traffic is _always_IP and will _always_ use HC. 

> That does not negate the advantage of removing
> tunnelling overhead. In particular, if the tunnel changes during
> handoff, it could cause the compressor to revert back to the start
> state, resulting in some number (the number is currently disputed)
> of packets required to restart the compressor. I've seen numbers from
> 60-600 ms quoted as required on a radio link with a 20 ms frame transmit
> time, I am trying to reduce the uncertainty by corresponding with the ROHC 
> working group chairs. Any amount of additional delay caused by having
> to restart the compression state machine at the beginning would thoroughly
> negate the low latency handoff work.
> 
	=> I've talked to ROHC authors a few times and that's where I
	got my conclusions. 

> Note that, unlike IPv4, the headers *will* change even if there is no
> tunnel overhead in IPv6 because the CoA will change when the mobile
> moves to the new access point, and the CoA gets sent out over the 
> air. In IPv4, the FA strips the tunnel overhead, so the compressor
> state remains the same and could potentially be shipped across the
> wire in a context transfer protocol (Seamoby). In IPv6, it is as yet
> uncertain if the compressor state could be maintained during handoff.
> And it may turn out that changing the CoA would allow the compressor
> state to be transferred, but changing the tunnel would not.
> 
	=> Yes I realise the difference, but the question is how long does it
	take to restart the compressor. We aleady got some answers 
	from Mikael, so I think that if you're not convinced perhaps 
	it would be good to bring this up on the ROHC mailing list. 
	This would be good for our understanding. I don't think 
	you'll get an answer from this list.

> The ROHC group seems to have been exclusively focused on IPv4. From
> my conversations with the working group chairs at IETF in Minneapolis,
> they seemed unaware that the header would change during handover
> in IPv6.
> 
> My conclusion from this is that it is dangerous to make blanket assumptions that
> header compression will solve problems with fat IPv6 headers lacking
> solid data about whether the compression algorithms can use context
> transfer to reestablish state and also reinitialize the state machines
> with the new CoA. I hope this will become somewhat clearer as we get
> more data from the ROHC working group.
> 
> If you are interested in helping to find this out, I suggest you generate
> a couple of HMIPv6 headers including the tunnelling overhead both
> before and after handover and send them to the ROHC chairs. They requested
> I do this for straight IPv6 headers. They will then be able to tell
> you whether or not the compressor can be restared without moving back
> to the start state. Then you can base your HMIPv6 design on solid data,
> rather than assumptions.
> 
	=> I thought I already did that, are you unhappy with Mikael's 
	and the other authors' analysis ? If so please explain your concerns
	to them and I'll just believe their answers. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:08:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01614
	for ; Tue, 27 Mar 2001 17:08:54 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06648;
	Tue, 27 Mar 2001 14:08:30 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25610;
	Tue, 27 Mar 2001 14:08:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RM75Im007368
	for ; Tue, 27 Mar 2001 14:07:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RM75VO007367
	for mobile-ip-dist; Tue, 27 Mar 2001 14:07:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RM6uIm007360
	for ; Tue, 27 Mar 2001 14:06:56 -0800 (PST)
Received: from locked (locked.Eng.Sun.COM [129.146.85.189])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2RM6rxf401271;
	Tue, 27 Mar 2001 14:06:53 -0800 (PST)
Message-Id: <200103272206.f2RM6rxf401271@jurassic.eng.sun.com>
Date: Tue, 27 Mar 2001 14:05:39 -0800 (PST)
From: Mohan Parthasarathy 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
To: nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: pekka.nikander@nomadiclab.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cuWL39tGfjsujKKkwIajeA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 

> 
> > => we can do something better: send a part of needed things directly
> > to the care-of address and the remainder to the home address (through
> > the home agent) so the MN will need to get the traffic from both paths
> > (and the MITM will need to intercept the traffic on both paths).
> 
> While such complexity helps for some threats it doesn't deal with
> MITM positioned close to the CN.
> But we can't do much about that threat since the CN doesn't have any 
> prestablished association with the HA or MN.
> 
> The most important threat to handle (that we can handle) is MITM
> attacks on the MNs link.
> 
From RFC 2408, ISAKMP, section 1.7.3,

Man in the middle attacks include interception, insertion, deletion,
and modification of messages, reflecting messages back at the
sender, replaying old messages and redirecting messages.


Do we want all this protection ? I am not sure how long/easy is
to analyse all this once we have a solution ? I think ISAKMP/IKE seems
to be safe from all the above.

-mohan



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:14:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01774
	for ; Tue, 27 Mar 2001 17:14:41 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10989;
	Tue, 27 Mar 2001 14:14:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24671;
	Tue, 27 Mar 2001 14:14:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMCpIm007391
	for ; Tue, 27 Mar 2001 14:12:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMCoxa007390
	for mobile-ip-dist; Tue, 27 Mar 2001 14:12:50 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMCfIm007383
	for ; Tue, 27 Mar 2001 14:12:41 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27505
	for ; Tue, 27 Mar 2001 14:12:42 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01397
	for ; Tue, 27 Mar 2001 15:12:40 -0700 (MST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2RMCdC05815
	for ; Wed, 28 Mar 2001 00:12:39 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 28 00:12:38 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 00:08:26 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'Samita Chakrabarti'" ,
        mobile-ip@sunroof.eng.sun.com
Cc: "Karim El-Malki (ERA)" ,
        ludovic.bellier@inria.fr, claude.castelluccia@inria.fr,
        james.kempf@eng.sun.com
Subject: RE: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a 
	third mode
Date: Wed, 28 Mar 2001 00:12:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Samita

> > 	=> As I mentioned earlier, this would work at a cost of 
> > 	more complexity in the MN. 
> > 	Since, ROHC (or other HC techniques) are used 
> > 	in all "BW-challenged" links, I'm inclined to think
> > 	that this should be placed in a separate draft. 
> > 	As you know several people have mentioned that 
> > 	the draft is doing too much and we're working 
> > 	on that. 
> > 	I believe James' comments was related to context 
> > 	transfer which is handled by seamoby. After 
> > 	reading Mikael Degermark's (co-chair of ROHC) emails 
> > 	I'm now convinced that this would work fine. 
> > 
> > 	So to summarise, I think your proposal would 
> > 	work and I (and the rest of the co-authors)
> > 	would be more than happy to assist you in any 
> > 	way if you would like to write another draft that 
> > 	addresses this optimisation for HMIPv6. 
> > 
> > 	Finally, I would strongly recommend that you 
> > 	consult with the IPng folks as this solution
> > 	requires some special tricks in the implementation
> > 	and IPng is the best place to get feedback on 
> > 	this.
> > 
> I thought, at IETF we agreed on this solution :)
> I am not sure if this  option should go into a separate draft.
> But, we can discuss more. Regarding IPng folks, I think many IPng
> folks are also in this working group.
> 
	=> I'm not saynig it's not important or bad 
	(although it is messy to implement). All I'm saying
	is that since cellular networks and low BW 
	dial up lines already have HC, the benefits 
	are minor. The problem that James
	is referring to (compresor restart) will still occur 
	in this scenario since the header will change every
	time the MN moves. 
	So I'm still not saying it shouldn't be done and that's 
	clearly not for me to say, all I'm saying is that 
	it can be an option which would be good to document
	in another draft. We're already removing other 
	parts of the draft based on the WG comments.

	I don't tink that's a bad thing, we're trying to focus on the 
	major issues first.

> > 	We're not saying it's not important,but simply 
> > 	responding to the WG's comments about the 
> > 	size/scope of the draft
> 
> If you include the third option as an optional mode, that will give
> flexibility to the implementors to choose to implement this option.
> When 3GPP and 3GPP2 systems implement ROHC, I understand that then
> this option will be redundant. 
> 
	=> 3GPP has already approved it and I believe 3GPP2 is doing
	the same.

	Cheers,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:16:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01814
	for ; Tue, 27 Mar 2001 17:16:37 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12707;
	Tue, 27 Mar 2001 14:16:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27575;
	Tue, 27 Mar 2001 14:16:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMENIm007404
	for ; Tue, 27 Mar 2001 14:14:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMENdX007403
	for mobile-ip-dist; Tue, 27 Mar 2001 14:14:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMECIm007396
	for ; Tue, 27 Mar 2001 14:14:12 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18942
	for ; Tue, 27 Mar 2001 14:14:13 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02167
	for ; Tue, 27 Mar 2001 15:14:11 -0700 (MST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2RME9d14484
	for ; Wed, 28 Mar 2001 00:14:09 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Mar 28 00:14:08 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 00:14:08 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'James Kempf'" ,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)"
	 ,
        ludovic.bellier@inria.fr
Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode
Date: Wed, 28 Mar 2001 00:14:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

James, 

One other thing I forgot to mention is that whether 
you tunnel or not, the header will change every time 
the MN moves. Unless we assume a MIPv4 model.

Hesham

> -----Original Message-----
> From:	James Kempf [SMTP:kempf@heliopolis.Eng.Sun.COM]
> Sent:	Wednesday, 28 March 2001 2:34
> To:	Samita.Chakrabarti@eng.sun.com; mobile-ip@sunroof.eng.sun.com; Hesham.Soliman@era.ericsson.se
> Cc:	claude.castelluccia@inria.fr; Karim.El-Malki@era.ericsson.se; ludovic.bellier@inria.fr; james.kempf@eng.sun.com
> Subject:	RE: Comments on hmipv6 draft and a proposal on a third mode
> 
> Hesham,
> 
> >
> >> I understand that
> >> this would be useful for IPRAN  as James Kempf had pointed out 
> >> earlier in the list.
> >> 
> >	=> Not really, all IP based cellular systems will use ROHC
> >	or something equivalent. To be more specific 3GPP will
> >	and I believe 3GPP2 is making (or has made a similar 
> >	decision). 
> >
> 
> Neither 3GPP nor 3GPP2 currently has all IP RANs. 3GPP2 is discussing
> whether to start work on a new all IP RAN architecture. 3GPP, having
> just completed the UTRAN architecture, has so far declined to
> investigate all IP RAN, being content with introducing IP as an
> alternate transport layer protocol.
> 
> That said, I agree that header compression will likely play a role
> even in an all IP RAN. That does not negate the advantage of removing
> tunnelling overhead. In particular, if the tunnel changes during
> handoff, it could cause the compressor to revert back to the start
> state, resulting in some number (the number is currently disputed)
> of packets required to restart the compressor. I've seen numbers from
> 60-600 ms quoted as required on a radio link with a 20 ms frame transmit
> time, I am trying to reduce the uncertainty by corresponding with the ROHC 
> working group chairs. Any amount of additional delay caused by having
> to restart the compression state machine at the beginning would thoroughly
> negate the low latency handoff work.
> 
> Note that, unlike IPv4, the headers *will* change even if there is no
> tunnel overhead in IPv6 because the CoA will change when the mobile
> moves to the new access point, and the CoA gets sent out over the 
> air. In IPv4, the FA strips the tunnel overhead, so the compressor
> state remains the same and could potentially be shipped across the
> wire in a context transfer protocol (Seamoby). In IPv6, it is as yet
> uncertain if the compressor state could be maintained during handoff.
> And it may turn out that changing the CoA would allow the compressor
> state to be transferred, but changing the tunnel would not.
> 
> The ROHC group seems to have been exclusively focused on IPv4. From
> my conversations with the working group chairs at IETF in Minneapolis,
> they seemed unaware that the header would change during handover
> in IPv6.
> 
> My conclusion from this is that it is dangerous to make blanket assumptions that
> header compression will solve problems with fat IPv6 headers lacking
> solid data about whether the compression algorithms can use context
> transfer to reestablish state and also reinitialize the state machines
> with the new CoA. I hope this will become somewhat clearer as we get
> more data from the ROHC working group.
> 
> If you are interested in helping to find this out, I suggest you generate
> a couple of HMIPv6 headers including the tunnelling overhead both
> before and after handover and send them to the ROHC chairs. They requested
> I do this for straight IPv6 headers. They will then be able to tell
> you whether or not the compressor can be restared without moving back
> to the start state. Then you can base your HMIPv6 design on solid data,
> rather than assumptions.
> 
> 			jak


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:23:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01919
	for ; Tue, 27 Mar 2001 17:23:31 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00446;
	Tue, 27 Mar 2001 14:23:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29108;
	Tue, 27 Mar 2001 14:23:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMLfIm007483
	for ; Tue, 27 Mar 2001 14:21:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMLfj1007482
	for mobile-ip-dist; Tue, 27 Mar 2001 14:21:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMLWIm007475
	for ; Tue, 27 Mar 2001 14:21:32 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26182
	for ; Tue, 27 Mar 2001 14:21:33 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06471
	for ; Tue, 27 Mar 2001 15:21:29 -0700 (MST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2RMLRC06636
	for ; Wed, 28 Mar 2001 00:21:27 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 28 00:20:55 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 00:20:56 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCDF@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] MIPv6 security issues:  how to move forward
Date: Wed, 28 Mar 2001 00:20:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> >
> >  > Of course, this mandates AAA for (scalable) MIPv6, which is probably
> not a
> >  > good thing.
> >
> >    Amongst other things. Anything that posits DNS
> >    as being a real time transaction system is dead
> >    in the water.
> >
> 
> I'm not suggesting that DNS be updated for this.  I'm not suggesting
> anything different from what we can do today with IPv4 (for the time being).
> 
> I'm not suggesting we need a new AAA infrastructure.
> 
> I'm not suggesting DynDNS.
> 
> I'm not suggesting we stop pursueing true route optimization.
> 
> All I'm saying is that we move forward with a simple form of MIPv6 that
> provides us with no more capability than we have today with MIPv4.  When you
> roam and authenticate with the local AAA infrastrucuture (PPP and RADIUS and
> CHAP or whatever protocols and infrastructure is already out there today),
> you get assigned an address that ties you to a local HA.  When you are
> mobile, traffic still goes through the local HA.  
> 
	=> The problem is that you still need to send a BU to 
	the local HA. That's why (I believe) Francis saw that it is
	basically HMIPv6 with one level of hierarchy. 
	So somehow you need to establish an SA between the 
	MN and the local HA/MAP ...etc

> Your A6 records are not
> updated, so if you want to act as a server, then it must be through your
> true original HA (not local HA).  (Hmmmm, does MIPv6 today allow for the
> possibility of multiple HAs?  
> 
	=> With HMIPv6 you get that effect. But an SA with 
	the local MAP is needed.

	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:26:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01985
	for ; Tue, 27 Mar 2001 17:26:06 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20390;
	Tue, 27 Mar 2001 14:25:45 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29701;
	Tue, 27 Mar 2001 14:25:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMOPIm007509
	for ; Tue, 27 Mar 2001 14:24:25 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMOOAV007508
	for mobile-ip-dist; Tue, 27 Mar 2001 14:24:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMOFIm007501
	for ; Tue, 27 Mar 2001 14:24:16 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29358
	for ; Tue, 27 Mar 2001 14:24:17 -0800 (PST)
Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA02136
	for ; Tue, 27 Mar 2001 14:24:16 -0800 (PST)
Received: (cpmta 8835 invoked from network); 27 Mar 2001 14:24:16 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.64) with SMTP; 27 Mar 2001 14:24:16 -0800
X-Sent: 27 Mar 2001 22:24:16 GMT
Message-ID: <01ff01c0b70c$9600cfa0$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <200103271711.f2RHBVxf335674@jurassic.eng.sun.com>
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ...
Date: Tue, 27 Mar 2001 14:23:43 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> >
> >   Here I think we see several issues. One, there
> >   is again a number of cryptographic operations
> >   which are very heavy this time: Diffie-Hellman,
> >   RSA, ... Second, protocols to negotiate this
> >   are complex. Third, how do we set up the trust
> >   for the protocols to work, do we need a global
> >   PKI?
> >
> I don't think overhead is a real issue. Once an SA is setup,
> it can be used for a lot of BUs.
>

The scenario mentioned by the IESG is a server with many 100,000s of
connections.  Here the overhead seems to be a show-stopper.

Which brings me to another thought.  Do we want different mechanisms for
different cases.  Talking to yahoo.com is completely different from talking
to my PC at home or my corporate VPN.  If I were sitting in starbucks
surfing the web with my PC over 802.11, I don't need any "mobility" at all
and no MITM protection if the 802.11 had individual encryption.  All I want
is to obtain a local IPv6 address...

Not sure one size fits all applies, though I have no idea what the practical
implications of the brilliantly pedantic observation are...

PF




From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:51:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02265
	for ; Tue, 27 Mar 2001 17:51:47 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11037;
	Tue, 27 Mar 2001 14:51:28 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06500;
	Tue, 27 Mar 2001 14:51:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMo4Im007589
	for ; Tue, 27 Mar 2001 14:50:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RMo3B7007588
	for mobile-ip-dist; Tue, 27 Mar 2001 14:50:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RMnsIm007581
	for ; Tue, 27 Mar 2001 14:49:55 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05479
	for ; Tue, 27 Mar 2001 14:49:55 -0800 (PST)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23453
	for ; Tue, 27 Mar 2001 15:49:54 -0700 (MST)
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA21703
	for ; Tue, 27 Mar 2001 17:49:52 -0500 (EST)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA21688
	for ; Tue, 27 Mar 2001 17:49:51 -0500 (EST)
Received: by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id RAA14596; Tue, 27 Mar 2001 17:49:48 -0500
Received: from lucent.com by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id RAA14581; Tue, 27 Mar 2001 17:49:44 -0500
Message-ID: <3AC11908.E9409295@lucent.com>
Date: Tue, 27 Mar 2001 17:49:44 -0500
From: Erik Anderlind 
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Erik,

Erik Nordmark wrote:
> 
> > => we can do something better: send a part of needed things directly
> > to the care-of address and the remainder to the home address (through
> > the home agent) so the MN will need to get the traffic from both paths
> > (and the MITM will need to intercept the traffic on both paths).
> 
> While such complexity helps for some threats it doesn't deal with
> MITM positioned close to the CN.
> But we can't do much about that threat since the CN doesn't have any
> prestablished association with the HA or MN.
> 
> The most important threat to handle (that we can handle) is MITM
> attacks on the MNs link.

Most wireless links provide encryption between mobile and base station.
Examples are GSM, GPRS, IS-95, Cdma-2000, W-cdma. For 802.11b the use of
link encryption (called WEP) is optional to implement. Many 802.11 cards
support it,
but just as for any security, key administration is a hassle and many
sites turn it off.

Is the focus on solving MITM for wired Ethernet and cable? What about
break-ins
to content side DMZs or other places.

Where do we really belive the largest MITM attack risk is? 
(Or is this a faulty approach, since we want to have some assurance that
all places where a MITM attack could be initiated are covered?)

Are we re-solving an 802.11 problem that already has a technical
solution (but which 
perhaps did not take in account "user friendly" key distribution?)


Erik A.

> 
>    Erik


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 17:56:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02294
	for ; Tue, 27 Mar 2001 17:56:09 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03666;
	Tue, 27 Mar 2001 11:11:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12870;
	Tue, 27 Mar 2001 11:11:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJA2Im006699
	for ; Tue, 27 Mar 2001 11:10:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2RJA262006698
	for mobile-ip-dist; Tue, 27 Mar 2001 11:10:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2RJ9rIm006691
	for ; Tue, 27 Mar 2001 11:09:53 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14518
	for ; Tue, 27 Mar 2001 11:09:53 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28331
	for ; Tue, 27 Mar 2001 11:09:53 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18047
	for ; Tue, 27 Mar 2001 11:10:14 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADE14307;
	Tue, 27 Mar 2001 11:09:50 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02905; Tue, 27 Mar 2001 11:09:50 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15040.58750.569690.325591@thomasm-u1.cisco.com>
Date: Tue, 27 Mar 2001 11:09:50 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
In-Reply-To: <4.2.0.58.20010327140052.00aa9330@127.0.0.1>
References: <200103192226.f2JMQUH23623@locked.eng.sun.com>
	<4.2.0.58.20010327140052.00aa9330@127.0.0.1>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I think that the first order question that must be
asked is how we're deriving trust. I believe that
PBK is deriving that trust based on return
routability. If that is the case, I have to wonder
what the initial and subsequent public key
operations are doing to increase security. Why,
for example, can't the CN just continue using the
return routability trust it used to initially
establish trust with the mobile node? What
security function is the public key operations
performing? What vulnerability are they closing?

		 Mike

Stuart Jacobs writes:
 > IMHO the pbk is a specific example of a special pki oriented just for 
 > something like MIP.  I would go farther and say the if these pbkeys were 
 > kept in certificates then they could also be used to initially authenticate 
 > entities.
 > 
 > Stu
 > 
 > At 3/27/01 10:53 AM, you wrote:
 > > >
 > > > > The WG is encouraged to look at the ID
 > > > > http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
 > > > > It was developed specifically as an alternate approach to addressing
 > > > > the problems discussed in this note.
 > > > >
 > > > But this does not address the above problem which is important.
 > > > draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
 > >
 > >Why doesn't pbk solve the problem?
 > >
 > >PF
 > >
 > >
 > 
 > ==========================
 > Stuart Jacobs CISSP
 > Sr. Technologist
 > Verizon Laboratories
 > 40 Sylvan Road Waltham, MA 02451-1128     USA
 > telephone: (781) 466-3076   fax: (781) 466-2838
 > stu.jacobs@verizon.com     sjj0@gte.com
 > ==========================


From owner-mobile-ip@sunroof.eng.sun.com  Tue Mar 27 20:07:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05821
	for ; Tue, 27 Mar 2001 20:07:40 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16408;
	Tue, 27 Mar 2001 17:07:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29984;
	Tue, 27 Mar 2001 17:07:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S15EIm008074
	for ; Tue, 27 Mar 2001 17:05:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S15Err008073
	for mobile-ip-dist; Tue, 27 Mar 2001 17:05:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S153Im008062
	for ; Tue, 27 Mar 2001 17:05:03 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29565;
	Tue, 27 Mar 2001 17:05:03 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA19911;
	Tue, 27 Mar 2001 17:05:02 -0800 (PST)
Message-Id: <200103280105.RAA19911@heliopolis.Eng.Sun.COM>
Date: Tue, 27 Mar 2001 17:05:02 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] Restarting Compressor on Mobile IPv6 Handover
To: micke@sm.luth.se, cabo@tzi.org
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        Hesham.Soliman@era.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kTJrgIDxp6WGVqn0FBhlvw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Carsten & Mikael,

I came away from our discussion in the lobby of the Hilton on Thurs. nite of 
IETF with the impression that the design center of the ROHC work has
been IPv4. In mobile IPv4, the Foreign Agent strips off tunnel overhead
before the packet is sent over the air, so that the IP header remains the
same after the mobile node moves from one FA to another. As a result,
the compressor state can theoretically be moved from one FA to another without 
requiring any changes.

In IPv6, the mobile node handles the care of address itself. This means
that the header will change when the mobile node moves from one Access
Router to another because the care of address will change. As you requested
in our conversation on Thurs nite, I have appended an IPv6 header to this email 
describing what fields change when the mobile node moves (basically, it will be 
the destination address in the uplink direction and the source address in the 
downlink direction).

In addition to this simple case, the mobile IP group is also examining
designs for hierarchical mobile IP. A hierarchical design eliminates
signalling back into the wired network to the home agent when the mobile
node moves within a certain domain. Instead, the mobile node is
only required to report its new care of address to the hierarchical
agent once across the wireless link. Only when the mobile node moves from  one 
hierachical domain to another must signalling be done to the home agent, and any 
corresponding nodes if route optimization is in effect. This substantially
reduces the amount of signalling over the wireless link if the mobile
node has many corresponding nodes.

One of those designs (HMIPv6 extended mode) appends an additional 40 bytes
of tunnel overhead onto the basic mobile IP header. This tunnel header
will also change when the mobile node moves from one subnet to another,
as is the case for the care of address in the simple MIPv6 case, 
and it occurs on every packet that is processed by the hierarchical
agent (called a Mobile Access Point, or MAP). One of the authors of HMIPv6
is asserting that header compression will remove this tunnel overhead
and that restarting the compressor will be
possible by simply transferring context from the old Access Router
to the new, then updating the state with the new parameters, so that
there will be no need for sending any full headers across the radio
link.

Sending full headers across the radio link in either the simple or hierarchical 
case is to be avoided, because it would increase the latency in handoff. Any
increase in handoff latency is extremely undesirable.

I would be interested in hearing your opinion on this, as would, I think
the mobile IP working group in general. If you need more
data about what the headers will look like with the HMIPv6 tunnel
overhead, Hesham Soliman, one of the co-authors of the proposal (who
has been cc'ed on this email) can give it to you.

			jak
			
--------------------------------------------------------------------------------
Source address changes on handoff for downlink direction
Destination address changes on handoff for uplink direction

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




 



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 01:25:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23652
	for ; Wed, 28 Mar 2001 01:25:40 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13206;
	Tue, 27 Mar 2001 22:25:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17608;
	Tue, 27 Mar 2001 22:25:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S6NtIm008733
	for ; Tue, 27 Mar 2001 22:23:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S6Ntot008732
	for mobile-ip-dist; Tue, 27 Mar 2001 22:23:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S6NkIm008725
	for ; Tue, 27 Mar 2001 22:23:46 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17520
	for ; Tue, 27 Mar 2001 22:23:45 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05314
	for ; Tue, 27 Mar 2001 22:23:44 -0800 (PST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f2S6NgC07242
	for ; Wed, 28 Mar 2001 08:23:42 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f2S6NeC29836
	for ; Wed, 28 Mar 2001 09:23:41 +0300 (EET DST)
Message-ID: <3AC1836C.73EE3531@lmf.ericsson.se>
Date: Wed, 28 Mar 2001 09:23:40 +0300
From: Jari Arkko 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ...
References: <200103261738.f2QHc5NI133071@jurassic.eng.sun.com>
		<3ABF8825.8E51BE6E@nomadiclab.com>
		<3AC07CEE.BC5DF2C0@lmf.ericsson.se> <15040.52453.387167.290866@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> One quick clarification:
> 
> Jari Arkko writes:
>  > * Memory consumption. Well, essentially an SA needs
>  >   an SPI number (4 bytes), protocol (1 byte), secret
>  >   (e.g. 16 bytes), various algorithm etc indicators
>  >   (say 4 bytes), and maybe a couple of other things
>  >   such as sequence numbers. So, in conclusion you
>  >   could spend in the best case maybe some dozens
>  >   of bytes, typical implementations perhaps use
>  >   something in the order of a few hundred bytes
>  >   at the worst. (Adding encryption algorithm that
>  >   needs a large table to speed things up could
>  >   set you up for an additional few kilobytes.)
> 
>      Yes. I believe that both twofish and rijndeal
>      are about two orders of magnitude slower (maybe
>      more, my memory is fuzzy) when you don't use the
>      tables. For all practical purposes, you are
>      going to need the tables in all but very special
>      cases (read: not IPsec).

Well, you're going to need the tables *exactly*
when you need the algorithms in question. Has got
nothing to do with the protocol at hand. My ipsec
implementation, for instance, doesn't allocate
the tables unless encryption is used _and_ the
particular algorithm is used. Same principles apply for TLS,
Kerberos, and any other protocol. In my understanding
of the MIP BU protection, we really don't need
encryption so memory usage for the tables isn't
an issue in this discussion.

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 02:06:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06995
	for ; Wed, 28 Mar 2001 02:06:48 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA20666;
	Tue, 27 Mar 2001 22:54:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20060;
	Tue, 27 Mar 2001 22:54:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S6raIm008760
	for ; Tue, 27 Mar 2001 22:53:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S6racd008759
	for mobile-ip-dist; Tue, 27 Mar 2001 22:53:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S6rRIm008752
	for ; Tue, 27 Mar 2001 22:53:27 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19942
	for ; Tue, 27 Mar 2001 22:53:26 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29750
	for ; Tue, 27 Mar 2001 22:53:26 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA23239
	for ; Tue, 27 Mar 2001 22:53:25 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2S6rOE32697
	for ; Tue, 27 Mar 2001 22:53:24 -0800
X-mProtect:  Tue, 27 Mar 2001 22:53:24 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdxCmCZG; Tue, 27 Mar 2001 22:53:20 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id WAA39103 for ; Tue, 27 Mar 2001 22:53:21 -0800 (PST)
Message-ID: <3AC18A61.931A6656@iprg.nokia.com>
Date: Tue, 27 Mar 2001 22:53:21 -0800
From: "Jari T. Malinen" 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
References: <034BEFD03799D411A59F00508BDF7546013DBCCC@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

> > > > I believe we are not overriding routing protocols any more than you
> > > > are, once we compare with your extended mode.
> > > >
> > >         => ??? I don't get that. Multi-level hierarchy forces packets
> > >         into a fixed route between levels. I don't know what you mean ??
> > >         Extended mode != multi-level hierarchy.
> >
> > It seems to resemble a multi-level hierarchy, at least for packets
> > going to previous MAP address or when using nested mobile routers.
> >
>         => No it's certainly not a multi-level hierarchy, the smooth
>         handoff (forwarding from the previous MAP) is a temporary
>         situation during a handoff.
> 
>         As for the MR case, I agree that it would look like a multi-level
>         hierarchy, but in this case routing within the network
>         is not overridden since every packet reaching the MN will
>         go through the AR anyway. (*)

..unless you have two nested mobile network which speak the same routing
protocol and came from the same AO. When lower such network attaches
to the upper using mobile MAP, other gateways can also be formed by
dynamic routing. Then, tunneling through MAPs looks like being able to
override routing. Also, this scenario of dynamic routing may even
be possible with the 2-level case (the upper mobile network being the
fixed network and natural routing being able to go around the one MAP
in non-transient or two MAP hierarchy in the transient MAP-based
forwarding case).

> > In extended mode MN is dislocated as compared to both the fixed and
> > mobile MAP.
> > The mobile node needs to let the lower MAP to know how
> > to route packets to MN. Consider packets coming from CN to old RCoA
> > (CoA registered with CN before MN can register new CoA after lower
> > MAP moved). The packets get re-routed from HA of the mobile MAP to
> >
>         => No they get routed from the HA of the MN which maybe
>         the same as the MR.

I was on the impression that due to basic Mobile IPv6 behavior, only
when the old RCoA binding cache entry is not in use at CN will the
packet from CN to MN go via HA of MN. If HA is the same for MN
and MR, MN is not really MN wrt. MR (lower MAP).

> > wherever the mobile MAP moved, taking them to the higher MAP since
> > this should hold the RCoA for the lower MAP. It will consume the
> > routing header of a route-optimized packet. Now the packet's destination
> > address will be home address of the MN in the mobile network.
> > Could you clarify routing to this address, re-capsulation through
> > lower MAP or perhaps by host-based routing?
> >
>         => Encapsulate to the lower MAP. Again note that the packets
>         have to go through the MR anyway.

> > A second case to consider is when MN can recursively be a mobile
> > router. There is a need for a host-routing protocol or recapsulating
> > tunneling to navigate packets through nested mobile networks.
> >
>         => This is really out there, why does the MN need to be another
>         MR, except for the case of making this proposal look like a
>         tree of routers ???

This looked to me the most generic case of mobile networks with
extended mode - providing mobile MAP service for MNs which
may also be routers. I did not find a restriction that mobile MAP does
not accept mobile routers below it.

>         The scenario you've mentioned is not in the draft and I don't
>         understand the relevance to this discssion.

Maybe relevance is the attempt to understand extended mode to be able
to verify/reject the original argument that only MIPv6RR overrides
routing unlike HMIPv6.

Stepping back, not using natural routing reduces robustness, an important
requirement, which we seem to agree, and maybe sometimes, that neither
design is neither perfect nor very different on that..

> > Using MAP as the connection point of mobile networks looks essential
> > to the method of getting packets to these nested networks thus fixing
> > packets to pass MAPs.
> >
>         => See (*).
> 
> > > > > > Better optimization of last hop bandwidth usage, network-controlled
> > > > > > load balancing (your scheme has hop count and priority in a MAP
> > > > > > option, these trust MN does something it may not be designed to
> > > > > > do and require more than one MAP options to make a choice even
> > > > > > possible).
> > > > > >
> > > > >         => Are you referring to the MAP option ?
> > > > >         I hope this is not the BW argument. This argument is
> > > > >         not valid IMO. RAs are designed to have several
> > > > >         options regardless of the use of MIP. I hope we can agree on that.
> > > >
> > > > We can still try to reduce the size of the RA, i.e. number of extensions
> > > > needed for a load-balancing network.
> > > >
> > >         => Jari, have you read the draft ? What load balancing
> > >         extensions are you referring to ? The load balancig described
> > >         in the draft is something else. Have a look at rev 2 or 3.
> >
> >
> > Considering RA size in IPv6 and cost of last mile bandwidth it is
> > in our requirements advisable trying to avoid extending it further.
> > If we can do with one extension and still distribute signaling load,
> > it extends scalability the bigger the visited domain.
> >
>         => Jari, we're going around in circles here. I've already
>         answered this _several_ times. The rtr adv does NOT
>         need to be frequently advertised. Only when something
>         changes, timers time out ....etc. See the Fast
>         Handoffs draft to see how Fast Handoffs can still work
>         in this scenario.
>         We're talking about 2 options at the most.
> 
>         I hope this is clear now.

There is, though, a requirement of scaling to serve many mobile nodes.
Whether we have frequent RAs may also depend on typical rate of new MNs
(to the visited domain) arriving at a cell +MNs not using fast handoffs.
Each of these may potentially solicit an advertisement. This has less
to do with unsolicited RA frequency.

Fast handoffs can possibly be used to help, provided L2 supports
triggers and anticipation, and conspiring routers (old router)
provide(s) / choose(s) the one new RCoA via the old link. Even though
the discussion has been a bit repetitive, it may have highlighted some
assumptions on both requirements and designs in hierarchical schemes.

>         Regards,
>         Hesham

Best Regards,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 03:02:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10880
	for ; Wed, 28 Mar 2001 03:02:27 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09303;
	Wed, 28 Mar 2001 00:02:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14325;
	Wed, 28 Mar 2001 00:01:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S7xnIm008852
	for ; Tue, 27 Mar 2001 23:59:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S7xnIG008851
	for mobile-ip-dist; Tue, 27 Mar 2001 23:59:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S7xeIm008842
	for ; Tue, 27 Mar 2001 23:59:40 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13913;
	Tue, 27 Mar 2001 23:59:39 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25648;
	Wed, 28 Mar 2001 00:59:38 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id JAA29376;
	Wed, 28 Mar 2001 09:59:21 +0200 (MET DST)
Message-ID: <3AC1999F.752DC845@inrialpes.fr>
Date: Wed, 28 Mar 2001 09:58:23 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (ERA)" 
CC: "'James Kempf'" ,
        Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        claude.castelluccia@inria.fr,
        "Karim El-Malki (ERA)" ,
        ludovic.bellier@inria.fr
Subject: [mobile-ip] Re: Comments on hmipv6 draft and a proposal on a third mode
References: <034BEFD03799D411A59F00508BDF7546013DBCDE@esealnt448.al.sw.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------96449ABD8E7A2C311AF73B3A"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------96449ABD8E7A2C311AF73B3A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

> James,
>
> One other thing I forgot to mention is that whether
> you tunnel or not, the header will change every time
> the MN moves. Unless we assume a MIPv4 model.
>
> Hesham
>

Hello,

I think what James is saying is that header compression
will be difficult for MIPv6...i.e. no packets will be compressed
... it is better not using tunnels...
Am I right James?

I am not completly convinced about this arguments and I am sure that
the RoHc will eventually find a solution...

However if we assume that this problem will not be solved, I think that I would
make more sense to have the wireless access routers decapsulate the packets coming
from the MAP and forward them on the air link... these packets could then be compressed
because the destination address does not change (the destination is the RCoA) as long as the MN
is supported by the same MAP (i.e. the RCoA does not change).

This requires to modify the wireless access routers but you gain even more than the proposed 3rd mode
in term of bandwidth comsumption because header compression is then possible on the air link....

Comments?

thanks,

Claude.




--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------96449ABD8E7A2C311AF73B3A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Hesham Soliman (ERA)" wrote:

James,

One other thing I forgot to mention is that whether

you tunnel or not, the header will change every time

the MN moves. Unless we assume a MIPv4 model.

Hesham

 

Hello,

I think what James is saying is that header compression

will be difficult for MIPv6...i.e. no packets will be compressed

... it is better not using tunnels...

Am I right James?

I am not completly convinced about this arguments and I am sure that

the RoHc will eventually find a solution...

However if we assume that this problem will not be solved, I think that
I would

make more sense to have the wireless access routers decapsulate the
packets coming

from the MAP and forward them on the air link... these packets could
then be compressed

because the destination address does not change (the destination is
the RCoA) as long as the MN

is supported by the same MAP (i.e. the RCoA does not change).

This requires to modify the wireless access routers but you gain even
more than the proposed 3rd mode

in term of bandwidth comsumption because header compression is then
possible on the air link....

Comments?

thanks,

Claude.

 

 

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------96449ABD8E7A2C311AF73B3A--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 04:54:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18287
	for ; Wed, 28 Mar 2001 04:54:11 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26716;
	Wed, 28 Mar 2001 01:53:52 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05495;
	Wed, 28 Mar 2001 01:53:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S9qXIm008995
	for ; Wed, 28 Mar 2001 01:52:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2S9qXhN008994
	for mobile-ip-dist; Wed, 28 Mar 2001 01:52:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2S9qOIm008987
	for ; Wed, 28 Mar 2001 01:52:24 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23793
	for ; Wed, 28 Mar 2001 01:52:23 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA29847
	for ; Wed, 28 Mar 2001 01:52:22 -0800 (PST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:44:10 +0200
Received: from rd.francetelecom.fr (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id G3RXQCTA; Mon, 26 Mar 2001 16:25:40 +0200
Message-ID: <3ABF50FB.737C92AC@rd.francetelecom.fr>
Date: Mon, 26 Mar 2001 16:23:55 +0200
From: Jean-Michel COMBES 
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Claude Castelluccia 
Subject: Re: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt
References: <3AB63A39.49928755@nomadiclab.com> <3AB75389.25077265@inrialpes.fr> <3AB83D9E.B078FAFB@nomadiclab.com>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id BAA26716
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA18287

Hi,

sorry for the delay ...

Pekka Nikander a écrit :

> > The reasons of keeping the Home Address (in cleartext) is:
> > - because IPSec uses it to locate the SA...if you remove the Home Address
> >   option you basically needs to use the CoA and since this CoA changes you
> >   have to reestablished the SA each time you move...
>
> Hmm.  I am unsure about this.  Isn't SAs looked up by the SPI
> and the _destination_ address?  Quoting RFC2401, "A security
> association is uniquely identified by a triple consisting
> of a Security Parameter Index (SPI), an IP Destination Address,
> and a security protocol (AH or ESP) identifier. "  The Home
> Address Destination Option carries the source address, doen't it?

JMC :
yes ... but most of IPsec implementations need to have it (SPD) ...

>
>
> My understanding is that the home address destination option is
> needed _only_ for looking up the right socket, and, as I have
> explained, can be done by other means, too.
>
> > - because some firewalls use it to perform some kind of filtering...
>
> Yes, I know.  But, IMHO, that is _completely_ flawed since the
> the firewalls cannot verify it's validity in any way.

JMC :
I don't think that a firewall have to verify the validity ... but to manage IP
traffic :
so you need Home-Address ...

>
>
> > In the draft  we suggest to generate the TMI as follows:
> > new TMI = MD5 ( Home address | current TMI),
> >
> snip
> >
> > We should probably use something like that:
> >
> > new TMI = MD5 ( Home address | current TMI | random value),
> >
>
> Or maybe you can do even better by calculation a few TMIs beforehand
> and using them then backwards.  But then you'd come directly to a
> solution similar to what I suggest in the forthcoming pbk-addresses
> draft...
>
> --Pekka

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 06:01:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21502
	for ; Wed, 28 Mar 2001 06:01:29 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01770;
	Wed, 28 Mar 2001 03:01:07 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17199;
	Wed, 28 Mar 2001 03:00:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SAxnIm009051
	for ; Wed, 28 Mar 2001 02:59:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SAxnoK009050
	for mobile-ip-dist; Wed, 28 Mar 2001 02:59:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SAxeIm009043
	for ; Wed, 28 Mar 2001 02:59:40 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29121
	for ; Wed, 28 Mar 2001 02:59:39 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA21269
	for ; Wed, 28 Mar 2001 03:59:38 -0700 (MST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:44:40 +0200
Received: from rd.francetelecom.fr (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id G3RXQC41; Mon, 26 Mar 2001 17:01:00 +0200
Message-ID: <3ABF5943.3858302C@rd.francetelecom.fr>
Date: Mon, 26 Mar 2001 16:59:15 +0200
From: Jean-Michel COMBES 
Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D
X-Mailer: Mozilla 4.7 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id DAA01770
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA21502

Hi,

sorry for the delay ...

Thomas Narten a écrit :

> This is a note to summarize some security-related concerns that the
> IESG has with the Mobile IP v6 Draft
> (draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
> follows:
>
> The IESG has concerns about the draft's dependency on IPSEC AH to
> authenticate Binding Updates. There are several issues here.
>
>    a) There is significant overhead associated with building and
>       maintaining AH/IPsec SAs (both in terms of state that needs to
>       be maintained, but also in terms of required message flows, and
>       the processing required to implement those flows). This has
>       negative implications for larger servers that process many 100s
>       of thousands of connections at a time.
>
>    b) The processing rules for authenticating a Binding Update with AH
>       are complex and are apparently not readily supported by the
>       current generation of IPsec/IKE implementations

JMC :
I don't agree : I'm used MobileIPv6+IPsec/IKE implementations (INRIA and
Bull) and all BU/BAck are authenticated with AH (using IKE) ...

> (e.g., the IPsec
>       policies are needed that specify sufficient granularity about
>       IPv6 packets containing binding updates).

JMC :
Agree (maximum granurality is Next Header number) . A solution, perhaps,
would be to allow a different Next Header number to BU and BAck
Destinations Options. Is it possible ?

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : jeanmichel.combes@rd.francetelecom.fr
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 07:14:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24645
	for ; Wed, 28 Mar 2001 07:14:58 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08725;
	Wed, 28 Mar 2001 04:14:29 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09647;
	Wed, 28 Mar 2001 04:14:23 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SCDAIm009131
	for ; Wed, 28 Mar 2001 04:13:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SCDAW6009130
	for mobile-ip-dist; Wed, 28 Mar 2001 04:13:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SCD0Im009123
	for ; Wed, 28 Mar 2001 04:13:00 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04305
	for ; Wed, 28 Mar 2001 04:12:59 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14632
	for ; Wed, 28 Mar 2001 04:12:58 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2SCCsC29216
	for ; Wed, 28 Mar 2001 14:12:54 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 28 14:12:53 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 14:08:40 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCE1@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'James Kempf'" , micke@sm.luth.se,
        cabo@tzi.org
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        "Hesham Soliman  (ERA)" 
Subject: [mobile-ip] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Wed, 28 Mar 2001 14:12:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	Hello,

	Just some clarifications below.


> Carsten & Mikael,
> 
> I came away from our discussion in the lobby of the Hilton on Thurs. nite of 
> IETF with the impression that the design center of the ROHC work has
> been IPv4. In mobile IPv4, the Foreign Agent strips off tunnel overhead
> before the packet is sent over the air, so that the IP header remains the
> same after the mobile node moves from one FA to another. As a result,
> the compressor state can theoretically be moved from one FA to another without 
> requiring any changes.
> 
> In IPv6, the mobile node handles the care of address itself. This means
> that the header will change when the mobile node moves from one Access
> Router to another because the care of address will change. As you requested
> in our conversation on Thurs nite, I have appended an IPv6 header to this email 
> describing what fields change when the mobile node moves (basically, it will be 
> the destination address in the uplink direction and the source address in the 
> downlink direction).
> 
	=> It's actually the opposite. The destination address in the 
	down link and the source address in the uplink. We're talking about 
	the MN right ?

> In addition to this simple case, the mobile IP group is also examining
> designs for hierarchical mobile IP. A hierarchical design eliminates
> signalling back into the wired network to the home agent when the mobile
> node moves within a certain domain. Instead, the mobile node is
> only required to report its new care of address to the hierarchical
> agent once across the wireless link. Only when the mobile node moves from  one 
> hierachical domain to another must signalling be done to the home agent, and any 
> corresponding nodes if route optimization is in effect. This substantially
> reduces the amount of signalling over the wireless link if the mobile
> node has many corresponding nodes.
> 
> One of those designs (HMIPv6 extended mode) appends an additional 40 bytes
> of tunnel overhead onto the basic mobile IP header. This tunnel header
> will also change when the mobile node moves from one subnet to another,
> as is the case for the care of address in the simple MIPv6 case, 
> and it occurs on every packet that is processed by the hierarchical
> agent (called a Mobile Access Point, or MAP). 
> 
	=> Mobility Anchor Point.

> One of the authors of HMIPv6
> is asserting that header compression will remove this tunnel overhead
> 
	=> Yes that's me. Based on some discussions with the authors of ROHC.

> and that restarting the compressor will be
> possible by simply transferring context from the old Access Router
> to the new, then updating the state with the new parameters, so that
> there will be no need for sending any full headers across the radio
> link.
> 
	=> Not me. I said (again based on some discussions with ROHC 
	authors) that restarting the compressor (if there is no context transfer)
	will take very few packets (3-4) with full headers first. 
	I made no statement on how it would work with context transfer, 
	because I don't know.

> Sending full headers across the radio link in either the simple or hierarchical 
> case is to be avoided, because it would increase the latency in handoff. Any
> increase in handoff latency is extremely undesirable.
> 
> I would be interested in hearing your opinion on this, as would, I think
> the mobile IP working group in general. If you need more
> data about what the headers will look like with the HMIPv6 tunnel
> overhead, Hesham Soliman, one of the co-authors of the proposal (who
> has been cc'ed on this email) can give it to you.
> 
	=> Sure. Of course there is always a Home Address option
	in the outgoing packets (from the MN) and it may also
	exist in the incoming (downlink) packets. But this option
	does not change.

	Hesham

> --------------------------------------------------------------------------------
> Source address changes on handoff for downlink direction
> Destination address changes on handoff for uplink direction
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Version| Traffic Class |           Flow Label                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         Payload Length        |  Next Header  |   Hop Limit   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +                         Source Address                        +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +                      Destination Address                      +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> 
>  


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 08:34:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27158
	for ; Wed, 28 Mar 2001 08:34:30 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27466;
	Wed, 28 Mar 2001 05:34:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22093;
	Wed, 28 Mar 2001 05:34:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SDWqIm009226
	for ; Wed, 28 Mar 2001 05:32:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SDWqYJ009225
	for mobile-ip-dist; Wed, 28 Mar 2001 05:32:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SDWhIm009218
	for ; Wed, 28 Mar 2001 05:32:44 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15269
	for ; Wed, 28 Mar 2001 05:32:45 -0800 (PST)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18090
	for ; Wed, 28 Mar 2001 05:32:44 -0800 (PST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 28 Mar 2001 08:27:41 -0500
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] length field
Date: Wed, 28 Mar 2001 08:27:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B78A.DCDE7DF4"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B78A.DCDE7DF4
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Mohamed Khalil [mailto:mkhalil@nortelnetworks.com]
Sent: Tuesday, March 27, 2001 3:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] length field



All, 

to remove the confusion of interpreting the meaning of the length field in
MIER and GNAI, we will change the definition slightly  as follows:

MIER: 

Length 
  
   8-bit unsigned integer. Length of the extension, in octets, 
   excluding the extension Type and the extension Length fields. 
   This field MUST be set to 1 plus the total length of the data field. 
[Phil Roberts] 

I'm assuming this is the Length field for the short extension only?

 

 

GNAI: 

Length 

   8-bit unsigned integer. Length of the extension, in octets, 
   excluding the extension Type and the extension Length fields. 
   This field MUST be set to 1 plus the total length of the NAI field. 



MK 



   




------_=_NextPart_001_01C0B78A.DCDE7DF4
Content-Type: text/html;
	charset="iso-8859-1"




length field




 



  
-----Original Message-----
From: Mohamed Khalil 
  [mailto:mkhalil@nortelnetworks.com]
Sent: Tuesday, March 27, 2001 
  3:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: 
  [mobile-ip] length field


  
All, 

  
to remove the confusion of interpreting the meaning of the 
  length field in MIER and GNAI, we will change the definition slightly  as 
  follows:

  
MIER: 

  
Length 
  
   8-bit unsigned integer. Length of the extension, in 
  octets, 
   excluding the extension Type and 
  the extension Length fields. 
   This field 
  MUST be set to 1 plus the total length of the data field. 
[Phil 
  Roberts] 

  
I'm 
  assuming this is the Length field for the short extension 
  only?

  
 

  
 

  
GNAI: 

  
Length 

  
   8-bit unsigned integer. Length of the extension, 
  in octets, 
   excluding the extension Type 
  and the extension Length fields. 
   This 
  field MUST be set to 1 plus the total length of the NAI field. 
  



  
MK 



  
   




------_=_NextPart_001_01C0B78A.DCDE7DF4--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 10:24:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01027
	for ; Wed, 28 Mar 2001 10:24:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02466;
	Wed, 28 Mar 2001 07:23:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22103;
	Wed, 28 Mar 2001 07:23:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFKnIm009381
	for ; Wed, 28 Mar 2001 07:20:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SFKn1B009380
	for mobile-ip-dist; Wed, 28 Mar 2001 07:20:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SFKeIm009373
	for ; Wed, 28 Mar 2001 07:20:40 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12739
	for ; Wed, 28 Mar 2001 07:20:40 -0800 (PST)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15927
	for ; Wed, 28 Mar 2001 08:20:38 -0700 (MST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 28 Mar 2001 09:05:56 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 28 Mar 2001 09:10:43 -0600
Message-ID: <9A9367D1556AD21182C40000F80930AB025E56D3@crchy28b.us.nortel.com>
From: "Mohamed Khalil" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] length field
Date: Wed, 28 Mar 2001 09:10:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B799.40CB2BB0"
X-Orig: 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B799.40CB2BB0
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, March 28, 2001 7:28 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] length field


 

-----Original Message-----
From: Mohamed Khalil [mailto:mkhalil@nortelnetworks.com]
Sent: Tuesday, March 27, 2001 3:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] length field



All, 

to remove the confusion of interpreting the meaning of the length field in
MIER and GNAI, we will change the definition slightly  as follows:

MIER: 

Length 
  
   8-bit unsigned integer. Length of the extension, in octets, 
   excluding the extension Type and the extension Length fields. 
   This field MUST be set to 1 plus the total length of the data field. 
[Phil Roberts] 

I'm assuming this is the Length field for the short extension only?
 

MK> yes

 

 

GNAI: 

Length 

   8-bit unsigned integer. Length of the extension, in octets, 
   excluding the extension Type and the extension Length fields. 
   This field MUST be set to 1 plus the total length of the NAI field. 



MK 



   




------_=_NextPart_001_01C0B799.40CB2BB0
Content-Type: text/html;
	charset="iso-8859-1"




length field





  
-----Original Message-----
From: Phil Roberts 
  [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, March 28, 2001 7:28 
  AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: 
  [mobile-ip] length field


  
 

  

    
-----Original Message-----
From: Mohamed Khalil 
    [mailto:mkhalil@nortelnetworks.com]
Sent: Tuesday, March 27, 2001 
    3:21 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: 
    [mobile-ip] length field


    
All, 

    
to remove the confusion of interpreting the meaning of the 
    length field in MIER and GNAI, we will change the definition slightly  
    as follows:

    
MIER: 

    
Length 
  
   8-bit unsigned integer. Length of the extension, in 
    octets, 
   excluding the extension Type 
    and the extension Length fields. 
   This 
    field MUST be set to 1 plus the total length of the data field. 
    
[Phil Roberts] 

    
I'm assuming this is the Length field for the short extension 
    only?
 

    
MK> yes

    
 

    
 

    
GNAI: 

    
Length 

    
   8-bit unsigned integer. Length of the 
    extension, in octets, 
   excluding the 
    extension Type and the extension Length fields. 
   This field MUST be set to 1 plus the total length of the 
    NAI field. 



    
MK 



    
   





------_=_NextPart_001_01C0B799.40CB2BB0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 11:22:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03848
	for ; Wed, 28 Mar 2001 11:22:27 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11100;
	Wed, 28 Mar 2001 08:22:07 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13248;
	Wed, 28 Mar 2001 08:22:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SGKmIm009530
	for ; Wed, 28 Mar 2001 08:20:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SGKlSj009529
	for mobile-ip-dist; Wed, 28 Mar 2001 08:20:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SGKbIm009522
	for ; Wed, 28 Mar 2001 08:20:37 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19212;
	Wed, 28 Mar 2001 08:20:37 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA28523;
	Wed, 28 Mar 2001 08:20:36 -0800 (PST)
Message-Id: <200103281620.IAA28523@heliopolis.Eng.Sun.COM>
Date: Wed, 28 Mar 2001 08:20:36 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] Problems with header compression in IPv6
To: Hesham.Soliman@era.ericsson.se, claude.castelluccia@inrialpes.fr
Cc: kempf@heliopolis.eng.sun.com, Samita.Chakrabarti@eng.sun.com,
        mobile-ip@sunroof.eng.sun.com, claude.castelluccia@inria.fr,
        Karim.El-Malki@era.ericsson.se, ludovic.bellier@inria.fr
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3uvvZZImUB27Qs8lxfcDdQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Claude,


>I think what James is saying is that header compression
>will be difficult for MIPv6...i.e. no packets will be compressed
>... it is better not using tunnels...
>Am I right James?
>

Exactly!

>I am not completly convinced about this arguments and I am sure that
>the RoHc will eventually find a solution...
>

Me either, but it is a heavily algorithmic area which I have not
spent time understanding, so I am willing to seek advice from those
who have.

>However if we assume that this problem will not be solved, I think that I would
>make more sense to have the wireless access routers decapsulate the packets 
coming
>from the MAP and forward them on the air link... these packets could then be 
compressed
>because the destination address does not change (the destination is the RCoA) 
as long as the MN
>is supported by the same MAP (i.e. the RCoA does not change).
>
>This requires to modify the wireless access routers but you gain even more than 
the proposed 3rd mode
>in term of bandwidth comsumption because header compression is then possible on 
the air link....

My feelings as well. This is similar to the old IPv4 FA, so the access
router would have to control the care of address, so it would be the
target of the tunnel.

Another possibility would be to simply strip the header and set up
an MPLS label switched path between the access router and the mobile
node. The label would be a small tag to identify the header, so
the mobile node could reassemble it. If the IPv6 flow label is used
as the MPLS label, it would not depend on the address of either the mobile
node or the corresponding node, so the label would not change even
if the corresponding node was a mobile node (and thus was periodically
changing its care of address). Another advantage of this scheme is that
there would only need to be a single, unidirectional packet sent from
one side to the other with full header. After that, the mobile node
and access router record the flow label to header mapping and use that
to reconstruct the packet. Using an arbitrarily assigned label would
work as well, but then there are problems if the corresponding node moves
because the mapping between the corresponding node care of address and the
label would become undone. There would naturally need to be some scheme for 
setting up the flow label end to end, a possible downside. I've got some ideas 
about how that could be done.

As Hesham has stated, this is not a problem only for HMIPv6, but adding
the extra 40 bytes of tunnel overhead will compound the problem if
header compression requires an extensive restart.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 13:47:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07508
	for ; Wed, 28 Mar 2001 13:47:50 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25371;
	Wed, 28 Mar 2001 10:47:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27691;
	Wed, 28 Mar 2001 10:47:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIk9Im009916
	for ; Wed, 28 Mar 2001 10:46:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SIk85R009915
	for mobile-ip-dist; Wed, 28 Mar 2001 10:46:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SIjxIm009908
	for ; Wed, 28 Mar 2001 10:45:59 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03782
	for ; Wed, 28 Mar 2001 10:45:59 -0800 (PST)
Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA02599
	for ; Wed, 28 Mar 2001 10:45:55 -0800 (PST)
Received: (cpmta 27402 invoked from network); 28 Mar 2001 10:42:13 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.64) with SMTP; 28 Mar 2001 10:42:13 -0800
X-Sent: 28 Mar 2001 18:42:13 GMT
Message-ID: <004f01c0b7b6$be12ae00$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu> <3ABF5943.3858302C@rd.francetelecom.fr>
Subject: Re: [mobile-ip] IESG security concerns with MIPv6
Date: Wed, 28 Mar 2001 10:41:46 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> JMC :
> Agree (maximum granurality is Next Header number) . A solution, perhaps,
> would be to allow a different Next Header number to BU and BAck
> Destinations Options. Is it possible ?
>

Or just over UDP, as is done with IPv4.   The optimization of piggy-backing
MIP control traffic onto data traffic has back-fired.

PF




From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 14:03:23 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07982
	for ; Wed, 28 Mar 2001 14:03:22 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10186;
	Wed, 28 Mar 2001 11:03:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01346;
	Wed, 28 Mar 2001 11:02:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ1bIm009952
	for ; Wed, 28 Mar 2001 11:01:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SJ1b2d009951
	for mobile-ip-dist; Wed, 28 Mar 2001 11:01:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ1SIm009944
	for ; Wed, 28 Mar 2001 11:01:28 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08488
	for ; Wed, 28 Mar 2001 11:01:27 -0800 (PST)
Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA08760
	for ; Wed, 28 Mar 2001 11:01:27 -0800 (PST)
Received: (cpmta 29042 invoked from network); 28 Mar 2001 11:01:26 -0800
Received: from unknown (HELO dellchan) (208.135.49.132)
  by smtp.francis.com (209.228.32.71) with SMTP; 28 Mar 2001 11:01:26 -0800
X-Sent: 28 Mar 2001 19:01:26 GMT
Message-ID: <007501c0b7b9$6cb974a0$2000a8c0@dellchan>
From: "Paul Francis" 
To: 
References: <200103192035.f2JKZU501536@hygro.adsl.duke.edu> <3ABF5943.3858302C@rd.francetelecom.fr> <004f01c0b7b6$be12ae00$2000a8c0@dellchan>
Subject: [mobile-ip] route optimization in IPv4
Date: Wed, 28 Mar 2001 11:00:58 -0800
Organization: TAHOE Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

At the risk of exposing my ignorance of security protocols:

I assume that the same scaling problem (load at the CN of establishing SAs)
exists for IPv4 route optimization as well.
(draft-ietf-mobileip-optim-10.txt)

PF




From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 14:04:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08025
	for ; Wed, 28 Mar 2001 14:04:36 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11455;
	Wed, 28 Mar 2001 11:04:22 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19724;
	Wed, 28 Mar 2001 11:04:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ2sIm009962
	for ; Wed, 28 Mar 2001 11:02:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SJ2sRP009961
	for mobile-ip-dist; Wed, 28 Mar 2001 11:02:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ2hIm009954
	for ; Wed, 28 Mar 2001 11:02:43 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08788
	for ; Wed, 28 Mar 2001 11:02:43 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18194
	for ; Wed, 28 Mar 2001 11:02:38 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06817
	for ; Wed, 28 Mar 2001 11:02:38 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SJ2aJ24868
	for ; Wed, 28 Mar 2001 11:02:36 -0800
X-mProtect:  Wed, 28 Mar 2001 11:02:36 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdd07CAb; Wed, 28 Mar 2001 11:02:17 PST
Message-ID: <3AC2353B.C0062215@cs.ucl.ac.uk>
Date: Wed, 28 Mar 2001 11:02:19 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third 
 mode
References: <034BEFD03799D411A59F00508BDF7546013DBCDD@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Claude/Hesham,

  packets that arrive encapsulated from the HA, do they get decapsulated
before encapsulated by the MAP?


Theo


UCL / Mobile Systems




From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 14:06:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08193
	for ; Wed, 28 Mar 2001 14:06:50 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12618;
	Wed, 28 Mar 2001 11:05:24 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26236;
	Wed, 28 Mar 2001 11:05:18 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ3oIm009979
	for ; Wed, 28 Mar 2001 11:03:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SJ3nJV009978
	for mobile-ip-dist; Wed, 28 Mar 2001 11:03:49 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJ3WIm009964
	for ; Wed, 28 Mar 2001 11:03:32 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01579;
	Wed, 28 Mar 2001 11:03:32 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18617;
	Wed, 28 Mar 2001 11:03:31 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11060;
	Wed, 28 Mar 2001 11:03:52 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF03673;
	Wed, 28 Mar 2001 11:03:29 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03277; Wed, 28 Mar 2001 11:03:28 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15042.13696.689969.95104@thomasm-u1.cisco.com>
Date: Wed, 28 Mar 2001 11:03:28 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'Samita Chakrabarti'" ,
        "Karim El-Malki (ERA)" ,
        ludovic.bellier@inria.fr, claude.castelluccia@inria.fr,
        james.kempf@eng.sun.com
Subject: RE: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a 
	third mode
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBCDD@esealnt448.al.sw.ericsson.se>
References: <034BEFD03799D411A59F00508BDF7546013DBCDD@esealnt448.al.sw.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I may be really off base here, but doesn't the 3G
MAC layer require fixed sized bandwidth increments
on the air? Eg, 8 kb/sec or something like that?
If so how well is ROHC really going to work?
Variable rate compression schemes don't usually
work very well with fixed bandwidth slot
architectures. I know that this is the reason, for
example, in DOCSIS (cable) they use a simpler (and
less bw efficient) form of payload header
suppression instead of CRTP/ROHC.

		    Mike

Hesham Soliman  (ERA) writes:
 > Hi Samita
 > 
 > > > 	=> As I mentioned earlier, this would work at a cost of 
 > > > 	more complexity in the MN. 
 > > > 	Since, ROHC (or other HC techniques) are used 
 > > > 	in all "BW-challenged" links, I'm inclined to think
 > > > 	that this should be placed in a separate draft. 
 > > > 	As you know several people have mentioned that 
 > > > 	the draft is doing too much and we're working 
 > > > 	on that. 
 > > > 	I believe James' comments was related to context 
 > > > 	transfer which is handled by seamoby. After 
 > > > 	reading Mikael Degermark's (co-chair of ROHC) emails 
 > > > 	I'm now convinced that this would work fine. 
 > > > 
 > > > 	So to summarise, I think your proposal would 
 > > > 	work and I (and the rest of the co-authors)
 > > > 	would be more than happy to assist you in any 
 > > > 	way if you would like to write another draft that 
 > > > 	addresses this optimisation for HMIPv6. 
 > > > 
 > > > 	Finally, I would strongly recommend that you 
 > > > 	consult with the IPng folks as this solution
 > > > 	requires some special tricks in the implementation
 > > > 	and IPng is the best place to get feedback on 
 > > > 	this.
 > > > 
 > > I thought, at IETF we agreed on this solution :)
 > > I am not sure if this  option should go into a separate draft.
 > > But, we can discuss more. Regarding IPng folks, I think many IPng
 > > folks are also in this working group.
 > > 
 > 	=> I'm not saynig it's not important or bad 
 > 	(although it is messy to implement). All I'm saying
 > 	is that since cellular networks and low BW 
 > 	dial up lines already have HC, the benefits 
 > 	are minor. The problem that James
 > 	is referring to (compresor restart) will still occur 
 > 	in this scenario since the header will change every
 > 	time the MN moves. 
 > 	So I'm still not saying it shouldn't be done and that's 
 > 	clearly not for me to say, all I'm saying is that 
 > 	it can be an option which would be good to document
 > 	in another draft. We're already removing other 
 > 	parts of the draft based on the WG comments.
 > 
 > 	I don't tink that's a bad thing, we're trying to focus on the 
 > 	major issues first.
 > 
 > > > 	We're not saying it's not important,but simply 
 > > > 	responding to the WG's comments about the 
 > > > 	size/scope of the draft
 > > 
 > > If you include the third option as an optional mode, that will give
 > > flexibility to the implementors to choose to implement this option.
 > > When 3GPP and 3GPP2 systems implement ROHC, I understand that then
 > > this option will be redundant. 
 > > 
 > 	=> 3GPP has already approved it and I believe 3GPP2 is doing
 > 	the same.
 > 
 > 	Cheers,
 > 	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 14:59:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09860
	for ; Wed, 28 Mar 2001 14:59:46 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00089;
	Wed, 28 Mar 2001 11:59:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02465;
	Wed, 28 Mar 2001 11:59:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJvtIm010179
	for ; Wed, 28 Mar 2001 11:57:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SJvs5I010178
	for mobile-ip-dist; Wed, 28 Mar 2001 11:57:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SJvjIm010171
	for ; Wed, 28 Mar 2001 11:57:46 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14004
	for ; Wed, 28 Mar 2001 11:57:45 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12357
	for ; Wed, 28 Mar 2001 11:57:44 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2SJvhd02836
	for ; Wed, 28 Mar 2001 21:57:43 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Mar 28 21:57:42 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 21:57:42 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCEE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'James Kempf'" 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] RE: Problems with header compression in IPv6
Date: Wed, 28 Mar 2001 21:57:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	James, 

> >I think what James is saying is that header compression
> >will be difficult for MIPv6...i.e. no packets will be compressed
> >... it is better not using tunnels...
> >Am I right James?
> >
> 
> Exactly!
> 
	=> Ok this is a bit different from what we've been discussing 
	and the proposal you mentioned in this mail. So if I can 
	summarise your concerns I would say you mentioned two
	issues:

	1. Tunnelling adds one more header and there is a question
	    whether HC will handle this or not at no extra cost.

	2. Resync of the compressor after handover. 

	I was told several times that issue 1 is not an issue
	and that current HC does handle this and ROHC 
	definitely will. The same goes for Extension headers. 

	 As for 2, this is independant from tunnelling and 
	we need to have some concrete answers on :

	- Whether the impacts are significant (20 packets
	 or 3)

	- Whether seamoby CT can handle this and minimise
	that time. That is if there are significant impacts. 

	If the answer is no to both questions (ie impacts are
	significant and CT will not help), then we need 
	to seriously consider the impacts on MIP in general
	including HMIP of course. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 15:04:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10012
	for ; Wed, 28 Mar 2001 15:04:11 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03745;
	Wed, 28 Mar 2001 12:03:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23418;
	Wed, 28 Mar 2001 12:03:44 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SK2FIm010208
	for ; Wed, 28 Mar 2001 12:02:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SK2ECl010207
	for mobile-ip-dist; Wed, 28 Mar 2001 12:02:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SK25Im010199
	for ; Wed, 28 Mar 2001 12:02:05 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22965
	for ; Wed, 28 Mar 2001 12:02:04 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02194
	for ; Wed, 28 Mar 2001 12:02:03 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2SK22d03354
	for ; Wed, 28 Mar 2001 22:02:02 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Mar 28 22:02:01 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 22:02:01 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCEF@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a 
	third mode
Date: Wed, 28 Mar 2001 22:02:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> Claude/Hesham,
> 
>   packets that arrive encapsulated from the HA, do they get decapsulated
> before encapsulated by the MAP?
> 
	=> Yes for Extended mode. No for Basic mode. 
	In basic mode the  MAP is basically a HA. 
	So if Basic mode is used with no route optimisation
	(the scenario you gave) packets will be recapsulated
	without decapsulation. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 15:53:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11099
	for ; Wed, 28 Mar 2001 15:53:40 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14329;
	Wed, 28 Mar 2001 12:53:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03374;
	Wed, 28 Mar 2001 12:53:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SKojIm010289
	for ; Wed, 28 Mar 2001 12:50:45 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SKoiv7010288
	for mobile-ip-dist; Wed, 28 Mar 2001 12:50:44 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SKoZIm010281
	for ; Wed, 28 Mar 2001 12:50:35 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24306
	for ; Wed, 28 Mar 2001 12:50:34 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09803
	for ; Wed, 28 Mar 2001 12:50:33 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2SKoVd10044
	for ; Wed, 28 Mar 2001 22:50:32 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Mar 28 22:50:30 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 22:50:30 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF2@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" ,
        "'James Kempf'" , rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
Date: Wed, 28 Mar 2001 22:50:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

James, 

Sorry for the fragmented emails, but it just hit me 
that issue 2 below (if it is an issue) can be solved 
for the uplink by the use of basic mode and forcing the MN to 
use RCoA as a source address in the packets. 
This is specified in rev 3 of the draft. 
Of course this doesn't solve it for MIPv6 (the base draft)
or the rare case of a colocated address in MIPv4. 

My limited knowledge of ROHC tells me that the 
uplink is the hard one to sync so this should do 
the trick since the packets won't change.

Comments ?

Hesham


> -----Original Message-----
> From:	Hesham Soliman  (ERA) [SMTP:Hesham.Soliman@era.ericsson.se]
> Sent:	Thursday, 29 March 2001 5:58
> To:	'James Kempf'
> Cc:	mobile-ip@sunroof.eng.sun.com
> Subject:	[mobile-ip] RE: Problems with header compression in IPv6
> 
> > >I think what James is saying is that header compression
> > >will be difficult for MIPv6...i.e. no packets will be compressed
> > >... it is better not using tunnels...
> > >Am I right James?
> > >
> > 
> > Exactly!
> > 
> 	=> Ok this is a bit different from what we've been discussing 
> 	and the proposal you mentioned in this mail. So if I can 
> 	summarise your concerns I would say you mentioned two
> 	issues:
> 
> 	1. Tunnelling adds one more header and there is a question
> 	    whether HC will handle this or not at no extra cost.
> 
> 	2. Resync of the compressor after handover. 
> 
> 	I was told several times that issue 1 is not an issue
> 	and that current HC does handle this and ROHC 
> 	definitely will. The same goes for Extension headers. 
> 
> 	 As for 2, this is independant from tunnelling and 
> 	we need to have some concrete answers on :
> 
> 	- Whether the impacts are significant (20 packets
> 	 or 3)
> 
> 	- Whether seamoby CT can handle this and minimise
> 	that time. That is if there are significant impacts. 
> 
> 	If the answer is no to both questions (ie impacts are
> 	significant and CT will not help), then we need 
> 	to seriously consider the impacts on MIP in general
> 	including HMIP of course. 
> 
> 	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:01:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11359
	for ; Wed, 28 Mar 2001 16:01:10 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10966;
	Wed, 28 Mar 2001 13:00:45 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26003;
	Wed, 28 Mar 2001 13:00:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SKxGIm010325
	for ; Wed, 28 Mar 2001 12:59:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SKxGvN010324
	for mobile-ip-dist; Wed, 28 Mar 2001 12:59:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SKx6Im010314
	for ; Wed, 28 Mar 2001 12:59:06 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14791;
	Wed, 28 Mar 2001 12:59:06 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA05093;
	Wed, 28 Mar 2001 12:59:05 -0800 (PST)
Message-Id: <200103282059.MAA05093@heliopolis.Eng.Sun.COM>
Date: Wed, 28 Mar 2001 12:59:05 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] RE: Problems with header compression in IPv6
To: kempf@heliopolis.eng.sun.com, Hesham.Soliman@era.ericsson.se
Cc: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: H9GTSc2BIbLjmW6xlm0JZA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham,

You've about summarized it. Until we get an answer from the ROHC group,
we won't know for sure.

		jak

>
>> >I think what James is saying is that header compression
>> >will be difficult for MIPv6...i.e. no packets will be compressed
>> >... it is better not using tunnels...
>> >Am I right James?
>> >
>> 
>> Exactly!
>> 
>	=> Ok this is a bit different from what we've been discussing 
>	and the proposal you mentioned in this mail. So if I can 
>	summarise your concerns I would say you mentioned two
>	issues:
>
>	1. Tunnelling adds one more header and there is a question
>	    whether HC will handle this or not at no extra cost.
>
>	2. Resync of the compressor after handover. 
>
>	I was told several times that issue 1 is not an issue
>	and that current HC does handle this and ROHC 
>	definitely will. The same goes for Extension headers. 
>
>	 As for 2, this is independant from tunnelling and 
>	we need to have some concrete answers on :
>
>	- Whether the impacts are significant (20 packets
>	 or 3)
>
>	- Whether seamoby CT can handle this and minimise
>	that time. That is if there are significant impacts. 
>
>	If the answer is no to both questions (ie impacts are
>	significant and CT will not help), then we need 
>	to seriously consider the impacts on MIP in general
>	including HMIP of course. 
>
>	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:12:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11671
	for ; Wed, 28 Mar 2001 16:12:48 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17207;
	Wed, 28 Mar 2001 13:12:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22925;
	Wed, 28 Mar 2001 13:12:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SL9fIm010370
	for ; Wed, 28 Mar 2001 13:09:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SL9foP010369
	for mobile-ip-dist; Wed, 28 Mar 2001 13:09:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SL9WIm010362
	for ; Wed, 28 Mar 2001 13:09:33 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16621;
	Wed, 28 Mar 2001 13:09:25 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA05334;
	Wed, 28 Mar 2001 13:09:24 -0800 (PST)
Message-Id: <200103282109.NAA05334@heliopolis.Eng.Sun.COM>
Date: Wed, 28 Mar 2001 13:09:24 -0800 (PST)
From: James Kempf 
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
To: mobile-ip@sunroof.eng.sun.com, kempf@heliopolis.eng.sun.com,
        rohc@cdt.luth.se, Hesham.Soliman@era.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: PzrMiBA2NGGwgW9RBjQKTQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham,


>Sorry for the fragmented emails, but it just hit me 

No problem.

>that issue 2 below (if it is an issue) can be solved 
>for the uplink by the use of basic mode and forcing the MN to 
>use RCoA as a source address in the packets. 
>This is specified in rev 3 of the draft. 
>Of course this doesn't solve it for MIPv6 (the base draft)
>or the rare case of a colocated address in MIPv4. 
>

Right, but it does limit the deployment to basic mode and it doesn't
solve the downlink problem. I think we need a solution that works
for all cases and lets the network operator choose the deployment
they need.

>My limited knowledge of ROHC tells me that the 
>uplink is the hard one to sync so this should do 
>the trick since the packets won't change.
>

I'm hoping that the ROHC algorithms are sufficiently parameterized that
restarting the compressor after context transfer will
be possible without going back to the base state. 

Barring that, I think we are going to need a solution like the
old FA or like the MPLS solution I described in the email to Claude.
You could would still need header compression for options and for
UDP/RTP headers in any event.

		jak 

>
>> -----Original Message-----
>> From:	Hesham Soliman  (ERA) [SMTP:Hesham.Soliman@era.ericsson.se]
>> Sent:	Thursday, 29 March 2001 5:58
>> To:	'James Kempf'
>> Cc:	mobile-ip@sunroof.eng.sun.com
>> Subject:	[mobile-ip] RE: Problems with header compression in IPv6
>> 
>> > >I think what James is saying is that header compression
>> > >will be difficult for MIPv6...i.e. no packets will be compressed
>> > >... it is better not using tunnels...
>> > >Am I right James?
>> > >
>> > 
>> > Exactly!
>> > 
>> 	=> Ok this is a bit different from what we've been discussing 
>> 	and the proposal you mentioned in this mail. So if I can 
>> 	summarise your concerns I would say you mentioned two
>> 	issues:
>> 
>> 	1. Tunnelling adds one more header and there is a question
>> 	    whether HC will handle this or not at no extra cost.
>> 
>> 	2. Resync of the compressor after handover. 
>> 
>> 	I was told several times that issue 1 is not an issue
>> 	and that current HC does handle this and ROHC 
>> 	definitely will. The same goes for Extension headers. 
>> 
>> 	 As for 2, this is independant from tunnelling and 
>> 	we need to have some concrete answers on :
>> 
>> 	- Whether the impacts are significant (20 packets
>> 	 or 3)
>> 
>> 	- Whether seamoby CT can handle this and minimise
>> 	that time. That is if there are significant impacts. 
>> 
>> 	If the answer is no to both questions (ie impacts are
>> 	significant and CT will not help), then we need 
>> 	to seriously consider the impacts on MIP in general
>> 	including HMIP of course. 
>> 
>> 	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:21:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11991
	for ; Wed, 28 Mar 2001 16:21:25 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21696;
	Wed, 28 Mar 2001 13:20:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29524;
	Wed, 28 Mar 2001 13:20:40 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLJPIm010396
	for ; Wed, 28 Mar 2001 13:19:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLJPfT010395
	for mobile-ip-dist; Wed, 28 Mar 2001 13:19:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLJAIm010388
	for ; Wed, 28 Mar 2001 13:19:16 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08610
	for ; Wed, 28 Mar 2001 13:19:10 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04271
	for ; Wed, 28 Mar 2001 13:19:08 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2SLJ7C27880
	for ; Wed, 28 Mar 2001 23:19:07 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 28 23:19:06 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 23:19:06 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF3@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
Date: Wed, 28 Mar 2001 23:19:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	James, 


> Barring that, I think we are going to need a solution like the
> old FA or like the MPLS solution I described in the email to Claude.
> 
	=> Nothing against your framework of course, but I really 
	hope we don't resort to either option (especially MPLS). 
	This will only delay deployment. 
	Let's wait and see what the ROHC and CT experts say.

> You could would still need header compression for options and for
> UDP/RTP headers in any event.
> 
	=> Of course. I wasn't ruling that out. This will still work in the 
	solution I mentioned. 

	Hesham


> >
> >> -----Original Message-----
> >> From:	Hesham Soliman  (ERA) [SMTP:Hesham.Soliman@era.ericsson.se]
> >> Sent:	Thursday, 29 March 2001 5:58
> >> To:	'James Kempf'
> >> Cc:	mobile-ip@sunroof.eng.sun.com
> >> Subject:	[mobile-ip] RE: Problems with header compression in IPv6
> >> 
> >> > >I think what James is saying is that header compression
> >> > >will be difficult for MIPv6...i.e. no packets will be compressed
> >> > >... it is better not using tunnels...
> >> > >Am I right James?
> >> > >
> >> > 
> >> > Exactly!
> >> > 
> >> 	=> Ok this is a bit different from what we've been discussing 
> >> 	and the proposal you mentioned in this mail. So if I can 
> >> 	summarise your concerns I would say you mentioned two
> >> 	issues:
> >> 
> >> 	1. Tunnelling adds one more header and there is a question
> >> 	    whether HC will handle this or not at no extra cost.
> >> 
> >> 	2. Resync of the compressor after handover. 
> >> 
> >> 	I was told several times that issue 1 is not an issue
> >> 	and that current HC does handle this and ROHC 
> >> 	definitely will. The same goes for Extension headers. 
> >> 
> >> 	 As for 2, this is independant from tunnelling and 
> >> 	we need to have some concrete answers on :
> >> 
> >> 	- Whether the impacts are significant (20 packets
> >> 	 or 3)
> >> 
> >> 	- Whether seamoby CT can handle this and minimise
> >> 	that time. That is if there are significant impacts. 
> >> 
> >> 	If the answer is no to both questions (ie impacts are
> >> 	significant and CT will not help), then we need 
> >> 	to seriously consider the impacts on MIP in general
> >> 	including HMIP of course. 
> >> 
> >> 	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:31:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12393
	for ; Wed, 28 Mar 2001 16:31:24 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13651;
	Wed, 28 Mar 2001 13:31:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11444;
	Wed, 28 Mar 2001 13:30:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLSfIm010430
	for ; Wed, 28 Mar 2001 13:28:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLSfr7010429
	for mobile-ip-dist; Wed, 28 Mar 2001 13:28:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLSWIm010422
	for ; Wed, 28 Mar 2001 13:28:32 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20248
	for ; Wed, 28 Mar 2001 13:28:31 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27344
	for ; Wed, 28 Mar 2001 13:28:30 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01264;
	Wed, 28 Mar 2001 13:28:33 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF07533;
	Wed, 28 Mar 2001 13:28:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA03306; Wed, 28 Mar 2001 13:28:28 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15042.22395.901016.402212@thomasm-u1.cisco.com>
Date: Wed, 28 Mar 2001 13:28:27 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBCF3@esealnt448.al.sw.ericsson.se>
References: <034BEFD03799D411A59F00508BDF7546013DBCF3@esealnt448.al.sw.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham Soliman  (ERA) writes:
 > 
 > > Barring that, I think we are going to need a solution like the
 > > old FA or like the MPLS solution I described in the email to Claude.
 > > 
 > 	=> Nothing against your framework of course, but I really 
 > 	hope we don't resort to either option (especially MPLS). 
 > 	This will only delay deployment. 
 > 	Let's wait and see what the ROHC and CT experts say.

   I don't think that MPLS helps. The label stack
   is inserted in between the headers, it doesn't
   replace them. After all, labels just reify the
   forwarding equivalence class; once you're done
   label switching, you still need to know how to
   route it to the destination. Also: label
   switching doesn't currently support
   to-the-endpoint as far as I've heard.

		      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:35:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12515
	for ; Wed, 28 Mar 2001 16:35:41 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17494;
	Wed, 28 Mar 2001 13:35:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12515;
	Wed, 28 Mar 2001 13:35:24 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLXsIm010459
	for ; Wed, 28 Mar 2001 13:33:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLXrNa010458
	for mobile-ip-dist; Wed, 28 Mar 2001 13:33:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLXjIm010451
	for ; Wed, 28 Mar 2001 13:33:45 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02461;
	Wed, 28 Mar 2001 13:33:44 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA06040;
	Wed, 28 Mar 2001 13:33:43 -0800 (PST)
Message-Id: <200103282133.NAA06040@heliopolis.Eng.Sun.COM>
Date: Wed, 28 Mar 2001 13:33:43 -0800 (PST)
From: James Kempf 
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
To: mobile-ip@sunroof.eng.sun.com
Cc: rohc@cdt.luth.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: PYpS/eAUB1tYmX0lCiw5xw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mike,


> > > Barring that, I think we are going to need a solution like the
> > > old FA or like the MPLS solution I described in the email to Claude.
> > > 
> > 	=> Nothing against your framework of course, but I really 
> > 	hope we don't resort to either option (especially MPLS). 
> > 	This will only delay deployment. 
> > 	Let's wait and see what the ROHC and CT experts say.
>
>   I don't think that MPLS helps. The label stack
>   is inserted in between the headers, it doesn't
>   replace them. After all, labels just reify the
>   forwarding equivalence class; once you're done
>   label switching, you still need to know how to
>   route it to the destination. Also: label
>   switching doesn't currently support
>   to-the-endpoint as far as I've heard.
>
>

My understanding from reading the MPLS framework RFC is that label stripping
was supported as well, just as long as the LDP communicated the header
to the other end somehow.

		jak
		



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:40:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12652
	for ; Wed, 28 Mar 2001 16:40:23 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02226;
	Wed, 28 Mar 2001 13:39:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03462;
	Wed, 28 Mar 2001 13:39:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLcSIm010484
	for ; Wed, 28 Mar 2001 13:38:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLcRpI010483
	for mobile-ip-dist; Wed, 28 Mar 2001 13:38:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLcHIm010476
	for ; Wed, 28 Mar 2001 13:38:17 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22014
	for ; Wed, 28 Mar 2001 13:38:16 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06245
	for ; Wed, 28 Mar 2001 13:38:11 -0800 (PST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SLcCg19730
	for ; Wed, 28 Mar 2001 15:38:12 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Wed, 28 Mar 2001 15:38:03 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 28 Mar 2001 15:38:03 -0600
Message-ID: 
To: zhigang.liu@nokia.com, Hesham.Soliman@era.ericsson.se,
        kempf@heliopolis.eng.sun.com, micke@sm.luth.se, cabo@tzi.org
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, pat.calhoun@eng.sun.com
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Wed, 28 Mar 2001 15:38:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,

some comments on the thread. 

1. It has become clear to me that there is no clear consensus in rohc on how
many IR packets are needed for context establishment. In the presence of
high error rate, such as the conditions present across cell boundaries
during handover (as Zhigang pointed out), it appears to me that the only
safe approach to be sure that the context is established is if the
compressor receives an appropriate ACK. I am not saying that taking a guess
will not work, I am just not sure what the magic number (of IR packets) is
for the compressor to send. Again, considering the error conditions, it
appears to me that sending "several" packets, as the rohc draft proposes,
might be a good thing to do. 

In the approach that does not wait for an ACK, there is a clear trade-off
between how many IR packets are sent versus the penalty incurred due to
failure to establish contexts; fewer you send, larger the chance of context
establishment failure. If the context cannot be established quickly and
reliably, it will lengthen the initialization process and is not desirable. 

2. Context establishment has to be done for each unidirectional packet
stream. For voice, this means two streams. When you have multimedia, you
will have more streams. In summary, the overhead goes up as the number of
streams increases. 
In comparison, when you do context relocation, you can move all the contexts
over a higher-speed link across routers. Besides, for seamoby, you can
maintain "seamless" header compression across handovers. 

3. With MIPv6, the header overhead is 84 bytes for IPv6/UDP/RTP with Home
Address option! I guess voice payload would occupy about 20-30 bytes ? 
IPv6/TCP header size is also 60 bytes (without TCP options). 

4. For short-lived flows, such as web that get done in 10-20 packets, the
cost of context establishment with respect to flow longevity is a concern.
Thus, a mobile-ip mechanism that relies on header compression should address
this problem. 
I agree with James that there is a problem with changing CoA forcing context
initialization.  One way to address this in context relocation is to send
the new CoA along with the rest of the context. The MN MAY send an update
packet containing the new CoA subsequent to handover as well. I mentioned
this to James.

Regards,

-Rajeev


> -----Original Message-----
> From: ext zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
> Sent: Wednesday, March 28, 2001 9:28 AM
> To: Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM;
> micke@sm.luth.se; cabo@tzi.org
> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se
> Subject: RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
> Hi,
> 
> I've been following this discussion for a while. Please see
> my comments below.
> 
> Br,
> Zhigang
> 
> > > (basically, it will be 
> > > the destination address in the uplink direction and the 
> source address
> in the 
> > > downlink direction).
> > > 
> > 	=> It's actually the opposite. The destination address in the 
> > 	down link and the source address in the uplink. We're 
> talking about 
> > 	the MN right ?
> 
> I guess Hesham is right, if downlink == to the mobile node.
> 
> > > and that restarting the compressor will be
> > > possible by simply transferring context from the old Access Router
> > > to the new, then updating the state with the new 
> parameters, so that
> > > there will be no need for sending any full headers across 
> the radio
> > > link.
> > > 
> > 	=> Not me. I said (again based on some discussions with ROHC 
> > 	authors) that restarting the compressor (if there is no context
> transfer)
> > 	will take very few packets (3-4) with full headers first. 
> > 	I made no statement on how it would work with context transfer, 
> > 	because I don't know.
> 
> There are some guessing/assumptions behind the number (3-4).
> I'm not so sure that's always the case. The radio link condition
> before/after handover is likely be worse than normal condition.
> That may mean more packets could be lost (in this case, IR packets).
> That will has impacts on the guessing of the number.
> 
> Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> for RTP/UDP/IPv6 headers). And most of the header fields are static. 
> That is the issue. With HC context relocation, there is no need to 
> send the static fields over the air. The reduced overhead means
> less pain (e.g. delay, possible stealing or blanking of voice 
> payload).
> 
> Note that smaller packets have lower chance to be hit by transmission 
> errors (even just one bit) and thus lost, assuming no link layer
> retransmission (which makes sense for real-time multimedia). 
>  
> > 	=> Sure. Of course there is always a Home Address option
> > 	in the outgoing packets (from the MN) and it may also
> > 	exist in the incoming (downlink) packets. But this option
> > 	does not change.
> 
> This is another good reason for HC context relocation, as that 
> increase the weight of static header fields.
> 
> 
> > 	Hesham
> > 
> > > 
> > --------------------------------------------------------------
> > ------------------
> > > Source address changes on handoff for downlink direction
> > > Destination address changes on handoff for uplink direction
> > > 
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |Version| Traffic Class |           Flow Label         
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |         Payload Length        |  Next Header  |   
> Hop Limit   |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    +                         Source Address               
>          +
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    +                      Destination Address             
>          +
> > >    |                                                      
>          |
> > >    +                                                      
>          +
> > >    |                                                      
>          |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > 
> > > 
> > > 
> > >  
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
> > 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:43:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12742
	for ; Wed, 28 Mar 2001 16:43:14 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23409;
	Wed, 28 Mar 2001 13:43:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28949;
	Wed, 28 Mar 2001 13:42:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLfcIm010510
	for ; Wed, 28 Mar 2001 13:41:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLfcnf010509
	for mobile-ip-dist; Wed, 28 Mar 2001 13:41:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLfTIm010502
	for ; Wed, 28 Mar 2001 13:41:29 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13785
	for ; Wed, 28 Mar 2001 13:41:28 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07944
	for ; Wed, 28 Mar 2001 13:41:27 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2SLfPC00103
	for ; Wed, 28 Mar 2001 23:41:25 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 28 23:41:24 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 23:37:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF4@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Cc: rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
Date: Wed, 28 Mar 2001 23:41:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

James, 


> > > > Barring that, I think we are going to need a solution like the
> > > > old FA or like the MPLS solution I described in the email to Claude.
> > > > 
> > > 	=> Nothing against your framework of course, but I really 
> > > 	hope we don't resort to either option (especially MPLS). 
> > > 	This will only delay deployment. 
> > > 	Let's wait and see what the ROHC and CT experts say.
> >
> >   I don't think that MPLS helps. The label stack
> >   is inserted in between the headers, it doesn't
> >   replace them. After all, labels just reify the
> >   forwarding equivalence class; once you're done
> >   label switching, you still need to know how to
> >   route it to the destination. Also: label
> >   switching doesn't currently support
> >   to-the-endpoint as far as I've heard.
> >
> >
> 
> My understanding from reading the MPLS framework RFC is that label stripping
> was supported as well, just as long as the LDP communicated the header
> to the other end somehow.
> 
	=> MPLS deals with flows. ROHC deals with connections. 
	A connection != a flow. There are several (major) issues
	to consider here, but this discussion is way beyond the
	scopes of these mailing lists so let's wait. 

	Hesham		


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:46:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12846
	for ; Wed, 28 Mar 2001 16:46:18 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26054;
	Wed, 28 Mar 2001 13:46:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29683;
	Wed, 28 Mar 2001 13:45:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLicIm010539
	for ; Wed, 28 Mar 2001 13:44:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLicrl010538
	for mobile-ip-dist; Wed, 28 Mar 2001 13:44:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLiSIm010528
	for ; Wed, 28 Mar 2001 13:44:28 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23228
	for ; Wed, 28 Mar 2001 13:44:27 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04847
	for ; Wed, 28 Mar 2001 13:44:25 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA04210;
	Wed, 28 Mar 2001 13:44:24 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF07960;
	Wed, 28 Mar 2001 13:44:23 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA03313; Wed, 28 Mar 2001 13:44:22 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15042.23350.662169.612788@thomasm-u1.cisco.com>
Date: Wed, 28 Mar 2001 13:44:22 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
In-Reply-To: <200103282133.NAA06040@heliopolis.Eng.Sun.COM>
References: <200103282133.NAA06040@heliopolis.Eng.Sun.COM>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Mike,
 > 
 > 
 > > > > Barring that, I think we are going to need a solution like the
 > > > > old FA or like the MPLS solution I described in the email to Claude.
 > > > > 
 > > > 	=> Nothing against your framework of course, but I really 
 > > > 	hope we don't resort to either option (especially MPLS). 
 > > > 	This will only delay deployment. 
 > > > 	Let's wait and see what the ROHC and CT experts say.
 > >
 > >   I don't think that MPLS helps. The label stack
 > >   is inserted in between the headers, it doesn't
 > >   replace them. After all, labels just reify the
 > >   forwarding equivalence class; once you're done
 > >   label switching, you still need to know how to
 > >   route it to the destination. Also: label
 > >   switching doesn't currently support
 > >   to-the-endpoint as far as I've heard.
 > >
 > >
 > 
 > My understanding from reading the MPLS framework RFC is that label stripping
 > was supported as well, just as long as the LDP communicated the header
 > to the other end somehow.

   That's just the labels, not the inner headers.
   MPLS is just a way of encoding the the forwarding
   decision back upstream so that the FIB lookup can
   be done with a single lookup for the FEC rather
   than the more conventional MTRIE based lookup.
   Once you're done label switching, you still
   need those IP headers to sort everything else
   out (including TTL processing, etc, etc). I'm
   pretty sure that this is why it doesn't make
   much sense to create LSP's to the host.

		  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:50:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13021
	for ; Wed, 28 Mar 2001 16:50:08 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07715;
	Wed, 28 Mar 2001 13:49:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24153;
	Wed, 28 Mar 2001 13:49:33 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLmQIm010568
	for ; Wed, 28 Mar 2001 13:48:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLmQY0010567
	for mobile-ip-dist; Wed, 28 Mar 2001 13:48:26 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLmHIm010560
	for ; Wed, 28 Mar 2001 13:48:17 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05280;
	Wed, 28 Mar 2001 13:48:11 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA06481;
	Wed, 28 Mar 2001 13:48:11 -0800 (PST)
Message-Id: <200103282148.NAA06481@heliopolis.Eng.Sun.COM>
Date: Wed, 28 Mar 2001 13:48:11 -0800 (PST)
From: James Kempf 
Subject: RE: [mobile-ip] RE: Problems with header compression in IPv6
To: mobile-ip@sunroof.eng.sun.com
Cc: rohc@cdt.luth.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 37Bcu9ro2eCuX/OUjwL6Vg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Mike,


> > 
> > 
> > > > > Barring that, I think we are going to need a solution like the
> > > > > old FA or like the MPLS solution I described in the email to Claude.
> > > > > 
> > > > 	=> Nothing against your framework of course, but I really 
> > > > 	hope we don't resort to either option (especially MPLS). 
> > > > 	This will only delay deployment. 
> > > > 	Let's wait and see what the ROHC and CT experts say.
> > >
> > >   I don't think that MPLS helps. The label stack
> > >   is inserted in between the headers, it doesn't
> > >   replace them. After all, labels just reify the
> > >   forwarding equivalence class; once you're done
> > >   label switching, you still need to know how to
> > >   route it to the destination. Also: label
> > >   switching doesn't currently support
> > >   to-the-endpoint as far as I've heard.
> > >
> > >
> > 
> > My understanding from reading the MPLS framework RFC is that label stripping
> > was supported as well, just as long as the LDP communicated the header
> > to the other end somehow.
>
>   That's just the labels, not the inner headers.
>   MPLS is just a way of encoding the the forwarding
>   decision back upstream so that the FIB lookup can
>   be done with a single lookup for the FEC rather
>   than the more conventional MTRIE based lookup.
>   Once you're done label switching, you still
>   need those IP headers to sort everything else
>   out (including TTL processing, etc, etc). I'm
>   pretty sure that this is why it doesn't make
>   much sense to create LSP's to the host.
>

Even if the LSP were one hop, from the last hop router to the mobile
node? No TTL considerations there...

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 16:55:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13186
	for ; Wed, 28 Mar 2001 16:55:10 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10582;
	Wed, 28 Mar 2001 13:54:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01664;
	Wed, 28 Mar 2001 13:54:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLr8Im010610
	for ; Wed, 28 Mar 2001 13:53:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SLr8LD010609
	for mobile-ip-dist; Wed, 28 Mar 2001 13:53:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SLqxIm010602
	for ; Wed, 28 Mar 2001 13:52:59 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24965
	for ; Wed, 28 Mar 2001 13:52:58 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10088
	for ; Wed, 28 Mar 2001 14:52:57 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA24512
	for ; Wed, 28 Mar 2001 13:52:57 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SLqrM12277
	for ; Wed, 28 Mar 2001 13:52:53 -0800
X-mProtect:  Wed, 28 Mar 2001 13:52:53 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdiF8be2; Wed, 28 Mar 2001 13:50:24 PST
Message-ID: <3AC25CA0.CA189BDB@cs.ucl.ac.uk>
Date: Wed, 28 Mar 2001 13:50:24 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third 
 mode
References: <034BEFD03799D411A59F00508BDF7546013DBCEF@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

> > Claude/Hesham,
> >
> >   packets that arrive encapsulated from the HA, do they get decapsulated
> > before encapsulated by the MAP?
> >
>         => Yes for Extended mode. No for Basic mode.
>         In basic mode the  MAP is basically a HA.
>         So if Basic mode is used with no route optimisation
>         (the scenario you gave) packets will be recapsulated
>         without decapsulation.
>
>         Hesham

Do you configure the interface to the RCoA also (apart from LCoA) to
decapsulate the second decapsulation, as the packet is destined to the RCoA


Theo

UCL /  Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 17:30:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14057
	for ; Wed, 28 Mar 2001 17:30:11 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01535;
	Wed, 28 Mar 2001 14:29:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13642;
	Wed, 28 Mar 2001 14:29:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SMSeIm010672
	for ; Wed, 28 Mar 2001 14:28:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SMSd4A010671
	for mobile-ip-dist; Wed, 28 Mar 2001 14:28:39 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SMSQIm010664
	for ; Wed, 28 Mar 2001 14:28:26 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08597
	for ; Wed, 28 Mar 2001 14:28:27 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27054
	for ; Wed, 28 Mar 2001 14:28:27 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA29787
	for ; Wed, 28 Mar 2001 14:28:23 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2SMSJH17018
	for ; Wed, 28 Mar 2001 14:28:19 -0800
X-mProtect:  Wed, 28 Mar 2001 14:28:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdu4e6iF; Wed, 28 Mar 2001 14:27:40 PST
Message-ID: <3AC2655E.7C16911D@cs.ucl.ac.uk>
Date: Wed, 28 Mar 2001 14:27:42 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Multiple tunnels over unoptimized route packets for Extended mode
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

   I have the impression that the Extended mode actually makes things a
little worse in terms of tunneling.

Consider:

Extended mode

CN send a packet to the Home Addr of the MN (no binding available at CN
yet). The MN's HA intercepts and encapsulates (1)
packet is sent to the LCoA of the MAP (registered as alternate-CoA of
the MN)
MAP is not there (aircraft took-off for Minneapolis)
MAP's HA intercepts packet and encapsulates (2)
packet goes to the RCoA of the MAP/Mobile AR.
packet intercepted by MAP's MAP (this is basic mode for MAP/Mobile AR)
and encapsulated to LCoA of MAP/Mobile AR   (3)


That implies that for every mobile AR you have you will need an extra 2
encapsulations per movement of MAP/Mobile AR

so for N mobile routers you will have 1+N*2 encapsulations......

this is excluding any realistic assumptions about the frequency of
handoffs of either MN or MAP/Mobile ARs
and as a result discpatch of multitunneled packets.


Couldn't that pose scalability problems???



Theo


UCL/ Mobile Systems




From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 17:54:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14056
	for ; Wed, 28 Mar 2001 17:30:11 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01528;
	Wed, 28 Mar 2001 14:29:58 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24159;
	Wed, 28 Mar 2001 14:29:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SMRnIm010662
	for ; Wed, 28 Mar 2001 14:27:50 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2SMRnXj010661
	for mobile-ip-dist; Wed, 28 Mar 2001 14:27:49 -0800 (PST)
Message-Id: <200103282227.f2SMRnXj010661@sunroof.eng.sun.com>
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2SMReIm010652
	for ; Wed, 28 Mar 2001 14:27:40 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23748
	for ; Wed, 28 Mar 2001 14:27:41 -0800 (PST)
Received: from horse.mes.titech.ac.jp (horse.mes.titech.ac.jp [131.112.99.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA29581
	for ; Wed, 28 Mar 2001 14:27:40 -0800 (PST)
Received: (qmail 20812 invoked from network); 28 Mar 2001 22:40:39 -0000
Received: from peacock.mes.titech.ac.jp (HELO peacock) (131.112.99.98)
  by horse.mes.titech.ac.jp with SMTP; 28 Mar 2001 22:40:39 -0000
Date: Thu, 29 Mar 2001 07:29:00 +0900
From: Naoki MIYASHITA 
To: MOBILE-IP@marvin.corpeast.baynetworks.com, mobile-ip@sunroof.eng.sun.com,
        mobile-ip@smallworks.com
Subject: [mobile-ip] Message-Id: <20010329072827.9248.MIYASHITA@horse.mes.titech.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.01
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

signoff mobile-ip


From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 21:37:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19124
	for ; Wed, 28 Mar 2001 21:37:49 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14038;
	Wed, 28 Mar 2001 18:37:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27131;
	Wed, 28 Mar 2001 18:37:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T2aAIm011061
	for ; Wed, 28 Mar 2001 18:36:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2T2a9dA011060
	for mobile-ip-dist; Wed, 28 Mar 2001 18:36:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T2a0Im011053
	for ; Wed, 28 Mar 2001 18:36:00 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26902
	for ; Wed, 28 Mar 2001 18:36:00 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21838
	for ; Wed, 28 Mar 2001 19:35:59 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA25111
	for ; Wed, 28 Mar 2001 18:35:59 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2T2ZuX10940
	for ; Wed, 28 Mar 2001 18:35:56 -0800
X-mProtect:  Wed, 28 Mar 2001 18:35:56 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdXfydbm; Wed, 28 Mar 2001 18:35:24 PST
Message-ID: <3AC29F6D.5558B088@cs.ucl.ac.uk>
Date: Wed, 28 Mar 2001 18:35:25 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets for 
 Extended mode
References: <3AC2655E.7C16911D@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Claude/Hesham,


   why in Basic mode you want to keep the Home addr secret from the MAP.
What good would it do???



Theo


UCL/ Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Wed Mar 28 21:49:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19349
	for ; Wed, 28 Mar 2001 21:49:58 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17622;
	Wed, 28 Mar 2001 18:49:50 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13787;
	Wed, 28 Mar 2001 18:49:37 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T2luIm011092
	for ; Wed, 28 Mar 2001 18:47:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2T2ltq4011091
	for mobile-ip-dist; Wed, 28 Mar 2001 18:47:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T2lkIm011084
	for ; Wed, 28 Mar 2001 18:47:46 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19799
	for ; Wed, 28 Mar 2001 18:47:46 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA26740
	for ; Wed, 28 Mar 2001 19:47:46 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA25689
	for ; Wed, 28 Mar 2001 18:47:45 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2T2lii07356
	for ; Wed, 28 Mar 2001 18:47:44 -0800
X-mProtect:  Wed, 28 Mar 2001 18:47:44 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdj4qg7D; Wed, 28 Mar 2001 18:47:28 PST
Message-ID: <3AC2A241.2194E5A8@cs.ucl.ac.uk>
Date: Wed, 28 Mar 2001 18:47:29 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets for 
 Extended mode
References: <3AC2655E.7C16911D@cs.ucl.ac.uk> <3AC29F6D.5558B088@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Claude/Hesham,


Furthermore,


  It is my impression that by the moment you hide your home address from
the registering MAP, the latter has no means of finding your AAA-H entity
in the home domain (unless you could show us otherwise) and as such you run
the risk of _not_ being admitted in the domain under BASIC mode.....since
the AAA-L cannot contact your home AAA authority for credential
verification....


do you intend to bypass such functions?

If the above is not the case could you please show to the contrary...



Theo


UCL / Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 02:28:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20769
	for ; Thu, 29 Mar 2001 02:28:59 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03765;
	Wed, 28 Mar 2001 23:28:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10491;
	Wed, 28 Mar 2001 23:28:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T7R0Im011238
	for ; Wed, 28 Mar 2001 23:27:00 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2T7Qxes011237
	for mobile-ip-dist; Wed, 28 Mar 2001 23:26:59 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T7QoIm011230
	for ; Wed, 28 Mar 2001 23:26:51 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10247
	for ; Wed, 28 Mar 2001 23:26:51 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15126
	for ; Wed, 28 Mar 2001 23:26:50 -0800 (PST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id JAA12242
	for ; Thu, 29 Mar 2001 09:26:49 +0200 (MET DST)
Message-ID: <3AC2E37E.19E71D5A@inrialpes.fr>
Date: Thu, 29 Mar 2001 09:25:51 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets for 
 Extended mode
References: <3AC2655E.7C16911D@cs.ucl.ac.uk> <3AC29F6D.5558B088@cs.ucl.ac.uk>
Content-Type: multipart/alternative;
 boundary="------------F61D460E6CA8DDF197AC93C7"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------F61D460E6CA8DDF197AC93C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Theo Pagtzis wrote:

> Claude/Hesham,
>
>    why in Basic mode you want to keep the Home addr secret from the MAP.
> What good would it do???
>

Hello Theo,

We actually don't intend to hide the Home Address from the MAP this is just

the way it is... The MAP is a HomeAgent that binds the RCoA to the LCoA...
From the MAP perspective the RCoA is the home address and the LCoA the
CoA...
The MAP is a HomeAgent..it does not even know that it is used by HMIPv6
....

regards,

Claude.


--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------F61D460E6CA8DDF197AC93C7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Theo Pagtzis wrote:

Claude/Hesham,

   why in Basic mode you want to keep the Home addr secret
from the MAP.

What good would it do???

 

Hello Theo,

We actually don't intend to hide the Home Address from the MAP this
is just

the way it is... The MAP is a HomeAgent that binds the RCoA to the
LCoA...

From the MAP perspective the RCoA is the home address and the
LCoA the CoA...

The MAP is a HomeAgent..it does not even know that it is used
by HMIPv6 ....

regards,

Claude.

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------F61D460E6CA8DDF197AC93C7--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 02:42:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21837
	for ; Thu, 29 Mar 2001 02:42:19 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23127;
	Wed, 28 Mar 2001 23:42:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03011;
	Wed, 28 Mar 2001 23:42:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T7epIm011272
	for ; Wed, 28 Mar 2001 23:40:51 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2T7epr0011271
	for mobile-ip-dist; Wed, 28 Mar 2001 23:40:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2T7egIm011264
	for ; Wed, 28 Mar 2001 23:40:42 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16516;
	Wed, 28 Mar 2001 23:40:43 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11870;
	Thu, 29 Mar 2001 00:40:42 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id JAA16365;
	Thu, 29 Mar 2001 09:40:31 +0200 (MET DST)
Message-ID: <3AC2E6B4.C723EDC6@inrialpes.fr>
Date: Thu, 29 Mar 2001 09:39:33 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: zhigang.liu@nokia.com
CC: Hesham.Soliman@era.ericsson.se, kempf@heliopolis.eng.sun.com,
        micke@sm.luth.se, cabo@tzi.org, mobile-ip@sunroof.eng.sun.com,
        rohc@cdt.luth.se
Subject: [mobile-ip] Re: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
References: <8572CF1E2A95D211A1190008C7EAA2460213BB6C@daeis05nok>
Content-Type: multipart/alternative;
 boundary="------------7D185F3E3F97E65A46630F46"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------7D185F3E3F97E65A46630F46
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello Zhigang,

I seems from your email that context relocation will be very useful for RoHC.
Is istalso the case if some packets are lost  when a MN moves from one base
station
to another one?

In this case it is better to restart the context or relocate it?
Do you know of any studies on this topic?

thanks a lot!

Claude.

zhigang.liu@nokia.com wrote:

> Hi,
>
>
>
> There are some guessing/assumptions behind the number (3-4).
> I'm not so sure that's always the case. The radio link condition
> before/after handover is likely be worse than normal condition.
> That may mean more packets could be lost (in this case, IR packets).
> That will has impacts on the guessing of the number.
>
> Although we're talking about "very few" packets (be it 3-4 or 5-6),
> they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes
> for RTP/UDP/IPv6 headers). And most of the header fields are static.
> That is the issue. With HC context relocation, there is no need to
> send the static fields over the air. The reduced overhead means
> less pain (e.g. delay, possible stealing or blanking of voice payload).
>
> Note that smaller packets have lower chance to be hit by transmission
> errors (even just one bit) and thus lost, assuming no link layer
> retransmission (which makes sense for real-time multimedia).
>

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------7D185F3E3F97E65A46630F46
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello Zhigang,

I seems from your email that context relocation will be very useful
for RoHC.

Is istalso the case if some packets are lost  when a MN moves
from one base station

to another one?

In this case it is better to restart the context or relocate it?

Do you know of any studies on this topic?

thanks a lot!

Claude.

zhigang.liu@nokia.com wrote:

Hi,

 

 

There are some guessing/assumptions behind the number (3-4).

I'm not so sure that's always the case. The radio link condition

before/after handover is likely be worse than normal condition.

That may mean more packets could be lost (in this case, IR packets).

That will has impacts on the guessing of the number.

Although we're talking about "very few" packets (be it 3-4 or 5-6),

they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes

for RTP/UDP/IPv6 headers). And most of the header fields are static.

That is the issue. With HC context relocation, there is no need to

send the static fields over the air. The reduced overhead means

less pain (e.g. delay, possible stealing or blanking of voice payload).

Note that smaller packets have lower chance to be hit by transmission

errors (even just one bit) and thus lost, assuming no link layer

retransmission (which makes sense for real-time multimedia).

 



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------7D185F3E3F97E65A46630F46--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 05:08:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02630
	for ; Thu, 29 Mar 2001 05:08:02 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03009;
	Thu, 29 Mar 2001 02:07:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12912;
	Thu, 29 Mar 2001 02:07:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TA6QIm011399
	for ; Thu, 29 Mar 2001 02:06:26 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TA6PWF011398
	for mobile-ip-dist; Thu, 29 Mar 2001 02:06:25 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TA6EIm011390
	for ; Thu, 29 Mar 2001 02:06:15 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12820
	for ; Thu, 29 Mar 2001 02:06:14 -0800 (PST)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA27342
	for ; Thu, 29 Mar 2001 02:06:13 -0800 (PST)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id ; Wed, 28 Mar 2001 08:33:36 +0200
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCD18@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 
To: "'Pekka Nikander'" ,
        KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 
Cc: mobile-ip@sunroof.eng.sun.com,
        Claude Castelluccia
	 
Subject: [mobile-ip] RE: Comments to draft-kassi-mobileip-dmi-00.txt
Date: Fri, 23 Mar 2001 15:12:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f2TA6FIm011391
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id CAA03009
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02630

Hello,

I agree with you, the MN must be authenticated by the access network before
it can exchange a traffic with others (HA, CN...). This will be the case for
all visited (foreign) networks of mobile service provider. And it will be
the same for other mobility situation (between company sites...).

For Input connections, the suggestion is to establish the communication
without using Mobile IP. The security issue between MN and CN is not
discussed in this draft. This issue is a common issue for the mobility in IP
networks.

I'm not attending the meeting, thanks for your comments.

Best regards,

-----Message d'origine-----
De : Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]
Envoyé : mercredi 21 mars 2001 18:07
À : KASSI-LAHLOU Mohammed FTRD/DMI/CAE
Cc : mobile-ip@sunroof.eng.sun.com; Claude Castelluccia
Objet : Comments to draft-kassi-mobileip-dmi-00.txt


KASSI-LAHLOU Mohammed FTRD/DMI/CAE wrote:

> If the home address belongs to a virtual network or if at every new
> communication it uses the address obtained in the visited network as a
> source address (as specified in draft-kassi-mobileip-dmi-00.txt) you can
> know that the mobile node is in movement but without having a point of

Nice draft.  Very much in line with our Homeless Mobile IPv6 thinking,
but not going quite that far as we attempt to go.

However, I think that even though the Security Considerations section
may be technically correct, in the practise the situation is different.
That is, one may reasonably assume that a MN has a permanent security
association (in some form) with its permanent or real HA.  However,
I have serious doubts about our ability to provide a scaleable solution
for creating security associations between an MN and the temporary
HA used to forward connections opened while at a foreign link.
Yes, I know, with AAA we most probably will be able to do that, but
I don't believe that AAA will ever scale enough to cover all of the
Internet.  (This is not a technical concern but a deployment concern.)

The case of not having a (conceptual) security association between a MN
and its HA is much harder from the security point of view than the case
where you do have such a security association.  Your grounds for providing
authorization evidence to the CN are much slimmer.  

I suggest that you reconsider your draft in the light of the Mobile IPv6
security discussion to be held tomorrow at the Mobileip WG meeting.

--Pekka


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 09:55:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16491
	for ; Thu, 29 Mar 2001 09:55:03 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27723;
	Thu, 29 Mar 2001 06:54:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22454;
	Thu, 29 Mar 2001 06:54:41 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TEr2Im011650
	for ; Thu, 29 Mar 2001 06:53:02 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TEr2sO011649
	for mobile-ip-dist; Thu, 29 Mar 2001 06:53:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TEqrIm011642
	for ; Thu, 29 Mar 2001 06:52:53 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25043
	for ; Thu, 29 Mar 2001 06:52:54 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16606
	for ; Thu, 29 Mar 2001 06:52:49 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2TEqms07308
	for ; Thu, 29 Mar 2001 16:52:48 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 29 16:51:22 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 29 Mar 2001 16:52:47 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF7@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f
	or Extended mode
Date: Thu, 29 Mar 2001 16:52:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

>   It is my impression that by the moment you hide your home address from
> the registering MAP, the latter has no means of finding your AAA-H entity
> in the home domain (unless you could show us otherwise) 
> 
	=> I think you're confusing a few different functions together. 
	The MAP doesn't need to contact the MN's AAAH. I don't understand
	why we need to mix these functions. 

> and as such you run
> the risk of _not_ being admitted in the domain under BASIC mode.....since
> the AAA-L cannot contact your home AAA authority for credential
> verification....
> 
	=> AAAL can not contact AAAH ? This is irrelevant for 
	HMIPv6.

	Hesham

	PS: Have a look at the BURP WG archives and drafts. 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 10:35:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18865
	for ; Thu, 29 Mar 2001 10:35:18 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09947;
	Thu, 29 Mar 2001 07:35:00 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16336;
	Thu, 29 Mar 2001 07:34:53 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TFXhIm011747
	for ; Thu, 29 Mar 2001 07:33:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TFXhY9011746
	for mobile-ip-dist; Thu, 29 Mar 2001 07:33:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TFXYIm011739
	for ; Thu, 29 Mar 2001 07:33:34 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16158
	for ; Thu, 29 Mar 2001 07:33:34 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22520
	for ; Thu, 29 Mar 2001 08:33:28 -0700 (MST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2TFXRs02744
	for ; Thu, 29 Mar 2001 17:33:27 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 29 17:32:02 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 29 Mar 2001 17:33:27 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCF8@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f
	or Extended mode
Date: Thu, 29 Mar 2001 17:33:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> Consider:
> 
> Extended mode
> 
> CN send a packet to the Home Addr of the MN (no binding available at CN
> yet). The MN's HA intercepts and encapsulates (1)
> packet is sent to the LCoA of the MAP (registered as alternate-CoA of
> the MN)
> MAP is not there (aircraft took-off for Minneapolis)
> MAP's HA intercepts packet and encapsulates (2)
> packet goes to the RCoA of the MAP/Mobile AR.
> packet intercepted by MAP's MAP (this is basic mode for MAP/Mobile AR)
> and encapsulated to LCoA of MAP/Mobile AR   (3)
> 
> That implies that for every mobile AR you have you will need an extra 2
> encapsulations per movement of MAP/Mobile AR
> 
> so for N mobile routers you will have 1+N*2 encapsulations......
> 
	=> You've managed to confuse me. So let's see if I can 
	clarify a few things here :

	- The MR case does not involve multiple levels of MRs. 

	- A handover works like this :
	The MR moves (uses FH or anything else), it advrtises 
	a new MAP's address for the MNs behind it. The MNs 
	then register the new address with the (fixed) MAP.  

	The entire process can be anticipated as the FH 
	suggests. If you anticipate you can simply 
	register with the MAP insteda of the old AR. 

	But all this is really outside the scope of HMIPv6
	and is part of FH. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 10:56:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20256
	for ; Thu, 29 Mar 2001 10:56:46 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20756;
	Thu, 29 Mar 2001 07:56:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04985;
	Thu, 29 Mar 2001 07:56:13 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TFt3Im011807
	for ; Thu, 29 Mar 2001 07:55:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TFt3kA011806
	for mobile-ip-dist; Thu, 29 Mar 2001 07:55:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TFssIm011799
	for ; Thu, 29 Mar 2001 07:54:54 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04716
	for ; Thu, 29 Mar 2001 07:54:55 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01728
	for ; Thu, 29 Mar 2001 07:54:50 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA28847
	for ; Thu, 29 Mar 2001 07:54:49 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TFskU17973
	for ; Thu, 29 Mar 2001 07:54:46 -0800
X-mProtect:  Thu, 29 Mar 2001 07:54:46 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdH7ZRHf; Thu, 29 Mar 2001 07:54:22 PST
Message-ID: <3AC35AB1.BFAAFA1B@cs.ucl.ac.uk>
Date: Thu, 29 Mar 2001 07:54:25 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets f or 
 Extended mode
References: <034BEFD03799D411A59F00508BDF7546013DBCF7@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

> >   It is my impression that by the moment you hide your home address from
> > the registering MAP, the latter has no means of finding your AAA-H entity
> > in the home domain (unless you could show us otherwise)
> >
>         => I think you're confusing a few different functions together.
>         The MAP doesn't need to contact the MN's AAAH. I don't understand
>         why we need to mix these functions.
>

Well I was wondering about admission control and what sort of ways would the
MAP domain or MAP itself since it is registering with it
would have to proceed with admitting the node to the net...

but then there is GNAI...

Theo


UCL / Mobile Systems



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 11:17:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21470
	for ; Thu, 29 Mar 2001 11:17:47 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09154;
	Thu, 29 Mar 2001 08:17:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08708;
	Thu, 29 Mar 2001 08:17:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGFaIm011882
	for ; Thu, 29 Mar 2001 08:15:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TGFa6G011881
	for mobile-ip-dist; Thu, 29 Mar 2001 08:15:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGFRIm011874
	for ; Thu, 29 Mar 2001 08:15:27 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20888
	for ; Thu, 29 Mar 2001 08:15:28 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15482
	for ; Thu, 29 Mar 2001 08:15:25 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA00500
	for ; Thu, 29 Mar 2001 08:15:24 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TGFOk19116
	for ; Thu, 29 Mar 2001 08:15:24 -0800
X-mProtect:  Thu, 29 Mar 2001 08:15:24 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdWzVjGU; Thu, 29 Mar 2001 08:15:09 PST
Message-ID: <3AC35F8D.5FDE0857@cs.ucl.ac.uk>
Date: Thu, 29 Mar 2001 08:15:09 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets f or 
 Extended mode
References: <034BEFD03799D411A59F00508BDF7546013DBCF8@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:

> > Consider:
> >
> > Extended mode
> >
> > CN send a packet to the Home Addr of the MN (no binding available at CN
> > yet). The MN's HA intercepts and encapsulates (1)
> > packet is sent to the LCoA of the MAP (registered as alternate-CoA of
> > the MN)
> > MAP is not there (aircraft took-off for Minneapolis)
> > MAP's HA intercepts packet and encapsulates (2)
> > packet goes to the RCoA of the MAP/Mobile AR.
> > packet intercepted by MAP's MAP (this is basic mode for MAP/Mobile AR)
> > and encapsulated to LCoA of MAP/Mobile AR   (3)
> >
> > That implies that for every mobile AR you have you will need an extra 2
> > encapsulations per movement of MAP/Mobile AR
> >
> > so for N mobile routers you will have 1+N*2 encapsulations......
> >
>         => You've managed to confuse me. So let's see if I can
>         clarify a few things here :

>
>         - The MR case does not involve multiple levels of MRs.

well the above example involved only one MR. Can you eliminate the case for
multiple MRs so that you do not need to tackle it?



>
>
>         - A handover works like this :
>         The MR moves (uses FH or anything else), it advrtises
>         a new MAP's address for the MNs behind it. The MNs
>         then register the new address with the (fixed) MAP.

sure the moving MAP advertises its new LCoA...to the MN's that hang
underneath it...we knew that

think what happens when a route unoptimized packet leaves the MN's HA..what
happens... (one tunnel already)

it will have to arrive at the domain of the supporting MAP (but this is
mobile). Since the packet is addressed to MR's home address , the MR's HA
will HAVE to intercept it and tunnel it to the RCoA it has for it MR (here
the MR acts as a plain HMIPv6 node). We have two tunnels already..

Once the packet arrives at the RCoA of the MR it will have to be intercepted
by its MAP (which must be working at Basic mode since it is not an MR)
As such it MUST simply tunnel it again (tunnel number 3) and send it to the
respective LCoA that it registered for that node (the MR) in its B-Cache.

The packet will arrive now at the LCoA of the MR, detunneled once, blah blah

on this one just try to explain what happens for route-unoptimized packets
from a CN to the true MN not the pseudo MN (i.e. the MR)...

I cannot see how you can have the MNs registering with the fixed MAP when
the MR/MAP has got a shorter distance metric as said in the spec. The spec
says that you select according to shortest distance. If you don't then what
is the distance according to which you opt for a MAP in Extended mode. It
must either be specific or you need an algorithm for that...what is that?

I cannot see what is the relation of FH..I am not talking about FH in the
slightest, and on top of it FH is not tackled in the draft or even referred
as a means in Extended mode.

I am talking about the core of the HMIPv6 protocol which is Basic Mode
operation for an MN which happens to be an MR..the Extended mode effects on
the MN's hanging underneath that MR which also serves as a MAP. The issue is
somewhat complex but that's what the draft is about...


Theo


UCL/ Mobile Systems

>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 11:50:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23784
	for ; Thu, 29 Mar 2001 11:50:44 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08482;
	Thu, 29 Mar 2001 08:50:33 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14513;
	Thu, 29 Mar 2001 08:50:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGnGIm011977
	for ; Thu, 29 Mar 2001 08:49:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TGnGZe011976
	for mobile-ip-dist; Thu, 29 Mar 2001 08:49:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TGn7Im011969
	for ; Thu, 29 Mar 2001 08:49:07 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14257
	for ; Thu, 29 Mar 2001 08:49:07 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20232
	for ; Thu, 29 Mar 2001 08:49:06 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2TGn5s04886
	for ; Thu, 29 Mar 2001 18:49:05 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 29 18:49:05 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 29 Mar 2001 18:49:05 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCFD@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f
	 or Extended mode
Date: Thu, 29 Mar 2001 18:49:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> >         - A handover works like this :
> >         The MR moves (uses FH or anything else), it advrtises
> >         a new MAP's address for the MNs behind it. The MNs
> >         then register the new address with the (fixed) MAP.
> 
> sure the moving MAP advertises its new LCoA...to the MN's that hang
> underneath it...we knew that
> 
	=> Then why do you assume that packets are sent to the MR's 
	Home address (below)? Are these packets addressed to
	the MN or the MR ?

> think what happens when a route unoptimized packet leaves the MN's HA..what
> happens... (one tunnel already)
> 
> it will have to arrive at the domain of the supporting MAP (but this is
> mobile). Since the packet is addressed to MR's home address , the MR's HA
> will HAVE to intercept it
> 
	=> As the draft says the packets are addressed to the MR's CoA.

>  and tunnel it to the RCoA it has for it MR (here
> the MR acts as a plain HMIPv6 node). We have two tunnels already..
> 
> Once the packet arrives at the RCoA of the MR it will have to be intercepted
> by its MAP (which must be working at Basic mode since it is not an MR)
> 
	=> From the draft:
	" 7. Extended mode: Supporting Mobile Nodes and Mobile Networks"
	   The Extended mode of operation can support both Mobile Nodes and
	   Mobile networks."

	I don't know why you assume the a MAP is only operating in 
	extended mode if it's MR. Did the draft give that impression ?
	If so please let us know where.


	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 12:04:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24591
	for ; Thu, 29 Mar 2001 12:04:26 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29806;
	Thu, 29 Mar 2001 09:04:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05086;
	Thu, 29 Mar 2001 09:04:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TH2vIm012052
	for ; Thu, 29 Mar 2001 09:02:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TH2vBO012051
	for mobile-ip-dist; Thu, 29 Mar 2001 09:02:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TH2lIm012044
	for ; Thu, 29 Mar 2001 09:02:48 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17394
	for ; Thu, 29 Mar 2001 09:02:48 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18996
	for ; Thu, 29 Mar 2001 09:02:46 -0800 (PST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2TH2jI14282
	for ; Thu, 29 Mar 2001 19:02:45 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 29 19:02:44 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 29 Mar 2001 18:58:31 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBCFE@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'zhigang.liu@nokia.com'" 
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Thu, 29 Mar 2001 19:02:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Zhiang, 

So it seems ot me that there is no clear consensus in ROHC
on context relocation. Is that because the need is not proven ?

I guess we need to know how bad a channel can be. I might 
be completely wrong here but if we're only talking about 
a couple of packets to sync the compressor, then context
relocation seems to be an overkill. However, if the amount 
of packets sent with full headers is significant, then I can 
understand the need. 
But either way it doesn't seem to be a problem since you 
said that context relocation (if needed) will solve this. Right ?

So I don't know why we (MIP WG) should be involved. 
It seems to be a ROHC/SEAMOBY issue. 

Regards,
Hesham

> -----Original Message-----
> From:	zhigang.liu@nokia.com [SMTP:zhigang.liu@nokia.com]
> Sent:	Friday, 30 March 2001 2:53
> To:	claude.castelluccia@inrialpes.fr; zhigang.liu@nokia.com
> Cc:	Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM; micke@sm.luth.se; cabo@tzi.org; mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se
> Subject:	RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> Hi Claude,
> 
> Context relocation is useful regardless of the loss of packets during 
> handover as the bulk of the saving (of bytes over the radio links) comes 
> from the static header fields. For example, the new compressor (for
> downlink) 
> can jump start in FO state in stead of going through IR state all over
> again.
> 
> We have been studying HC context relocation since spring 1999 (when we 
> started ACE). Khiem has proposed text to ROHC list in June 2000 
> (http://www.cdt.luth.se/robhc/msg00508.html). Unfortunately, that item was 
> not included in ROHC I-D, partially due to the urgency to finish the basic
> ROHC scheme (plus objections from some of the ROHC authors). 
> 
> Now, it's time we give it a serious look.
> 
> Br,
> Zhigang
> 
> -----Original Message-----
> From: ext Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
> Sent: Thursday, March 29, 2001 1:40 AM
> To: zhigang.liu@nokia.com
> Cc: Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM;
> micke@sm.luth.se; cabo@tzi.org; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se
> Subject: Re: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
>   
> Hello Zhigang, 
> I seems from your email that context relocation will be very useful for
> RoHC. 
> Is istalso the case if some packets are lost  when a MN moves from one base
> station 
> to another one? 
> In this case it is better to restart the context or relocate it? 
> Do you know of any studies on this topic? 
> thanks a lot! 
> Claude. 
> zhigang.liu@nokia.com wrote: 
> Hi, 
>   
>   
> There are some guessing/assumptions behind the number (3-4). 
> I'm not so sure that's always the case. The radio link condition 
> before/after handover is likely be worse than normal condition. 
> That may mean more packets could be lost (in this case, IR packets). 
> That will has impacts on the guessing of the number. 
> Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> for RTP/UDP/IPv6 headers). And most of the header fields are static. 
> That is the issue. With HC context relocation, there is no need to 
> send the static fields over the air. The reduced overhead means 
> less pain (e.g. delay, possible stealing or blanking of voice payload). 
> Note that smaller packets have lower chance to be hit by transmission 
> errors (even just one bit) and thus lost, assuming no link layer 
> retransmission (which makes sense for real-time multimedia). 
>  
> -- 
> 
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes  
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>   


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 13:10:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28897
	for ; Thu, 29 Mar 2001 13:10:04 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02709;
	Thu, 29 Mar 2001 10:09:33 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20422;
	Thu, 29 Mar 2001 10:09:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TI83Im012195
	for ; Thu, 29 Mar 2001 10:08:03 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TI82Ct012194
	for mobile-ip-dist; Thu, 29 Mar 2001 10:08:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TI7pIm012187
	for ; Thu, 29 Mar 2001 10:07:52 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20149
	for ; Thu, 29 Mar 2001 10:07:52 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14287
	for ; Thu, 29 Mar 2001 10:07:51 -0800 (PST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TI9qw22178
	for ; Thu, 29 Mar 2001 12:09:52 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 12:07:42 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 12:07:42 -0600
Message-ID: 
To: zhigang.liu@nokia.com, claude.castelluccia@inrialpes.fr
Cc: Hesham.Soliman@era.ericsson.se, kempf@heliopolis.eng.sun.com,
        micke@sm.luth.se, cabo@tzi.org, mobile-ip@sunroof.eng.sun.com,
        rohc@cdt.luth.se
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Thu, 29 Mar 2001 12:07:40 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Just a quick addition: even if the packets are lost, a good compression
algorithm re-syncs itself with the successfully received packets. We have
done some experimental study on context relocation using ACE as the
compression algorithm (I believe it is used as the basis for the R-mode in
rohc) and ACE can continue in FO state. This study is currently under
submission, so I cannot provide the document. In any case, the summary is
that context relocation works even with reactive handovers such as the basic
MIPv6 ones. We believe that with fast handovers, it will get better. 

There is also the draft
 
http://search.ietf.org/internet-drafts/draft-koodli-seamoby-hc-relocate-00.t
xt

Sorry my quick comment took so long!

Regards,

-Rajeev


> -----Original Message-----
> From: ext zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
> Sent: Thursday, March 29, 2001 8:53 AM
> To: claude.castelluccia@inrialpes.fr; zhigang.liu@nokia.com
> Cc: Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM;
> micke@sm.luth.se; cabo@tzi.org; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se
> Subject: RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
> Hi Claude,
> 
> Context relocation is useful regardless of the loss of packets during 
> handover as the bulk of the saving (of bytes over the radio 
> links) comes 
> from the static header fields. For example, the new compressor (for
> downlink) 
> can jump start in FO state in stead of going through IR state all over
> again.
> 
> We have been studying HC context relocation since spring 1999 
> (when we 
> started ACE). Khiem has proposed text to ROHC list in June 2000 
> (http://www.cdt.luth.se/robhc/msg00508.html). Unfortunately, 
> that item was 
> not included in ROHC I-D, partially due to the urgency to 
> finish the basic
> ROHC scheme (plus objections from some of the ROHC authors). 
> 
> Now, it's time we give it a serious look.
> 
> Br,
> Zhigang
> 
> -----Original Message-----
> From: ext Claude Castelluccia 
> [mailto:claude.castelluccia@inrialpes.fr]
> Sent: Thursday, March 29, 2001 1:40 AM
> To: zhigang.liu@nokia.com
> Cc: Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM;
> micke@sm.luth.se; cabo@tzi.org; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se
> Subject: Re: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
> 
> 
>   
> Hello Zhigang, 
> I seems from your email that context relocation will be very 
> useful for
> RoHC. 
> Is istalso the case if some packets are lost  when a MN moves 
> from one base
> station 
> to another one? 
> In this case it is better to restart the context or relocate it? 
> Do you know of any studies on this topic? 
> thanks a lot! 
> Claude. 
> zhigang.liu@nokia.com wrote: 
> Hi, 
>   
>   
> There are some guessing/assumptions behind the number (3-4). 
> I'm not so sure that's always the case. The radio link condition 
> before/after handover is likely be worse than normal condition. 
> That may mean more packets could be lost (in this case, IR packets). 
> That will has impacts on the guessing of the number. 
> Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> for RTP/UDP/IPv6 headers). And most of the header fields are static. 
> That is the issue. With HC context relocation, there is no need to 
> send the static fields over the air. The reduced overhead means 
> less pain (e.g. delay, possible stealing or blanking of voice 
> payload). 
> Note that smaller packets have lower chance to be hit by transmission 
> errors (even just one bit) and thus lost, assuming no link layer 
> retransmission (which makes sense for real-time multimedia). 
>  
> -- 
> 
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes  
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>   
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 13:48:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02453
	for ; Thu, 29 Mar 2001 13:48:27 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19872;
	Thu, 29 Mar 2001 10:48:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26424;
	Thu, 29 Mar 2001 10:48:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TIkXIm012261
	for ; Thu, 29 Mar 2001 10:46:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TIkWwC012260
	for mobile-ip-dist; Thu, 29 Mar 2001 10:46:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TIkLIm012253
	for ; Thu, 29 Mar 2001 10:46:22 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26004
	for ; Thu, 29 Mar 2001 10:46:21 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25233
	for ; Thu, 29 Mar 2001 11:46:20 -0700 (MST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TIkMg06058
	for ; Thu, 29 Mar 2001 12:46:22 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 12:46:19 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 12:46:19 -0600
Message-ID: 
To: Hesham.Soliman@era.ericsson.se, zhigang.liu@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Thu, 29 Mar 2001 12:46:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Hesham,

> 
> Hello Zhiang, 
> 
> So it seems ot me that there is no clear consensus in ROHC
> on context relocation. Is that because the need is not proven ?
> 

I did not get this picture when reading Zhigang's e-mail. I believe he said
rohc had to attend the urgent matter of a draft for IP/UDP/RTP compression.
I guess the focus was on coming with a scheme that described the functioning
of an rohc compression mechanism that would also include context
initialization! Mobility, handover was perhaps outside the scope..


> I guess we need to know how bad a channel can be. I might 
> be completely wrong here but if we're only talking about 
> a couple of packets to sync the compressor, then context
> relocation seems to be an overkill. However, if the amount 
> of packets sent with full headers is significant, then I can 
> understand the need. 

I agree that we need a reasonable number. The number of packets needed to
initialize the context, it appears, can vary. I have heard 3 packets before,
but not two! The key issue is the compressor has to have "sufficient
confidence" according to rohc draft. The issue of confidence is critical
because of error conditions prevalent on cellular links. These errors could
be worse across cell boundaries during handovers. Furthermore, you have to
do context initialization for _each_ packet stream!

Also, I don't agree that context relocation is an overkill when few IR
packets are needed. Consider a channel optimized for sending 24 bytes of
voice payload and 4 bytes of header. Such CBR-like channels are common in
cellular, I gather. Now, if you have to send a header 84 bytes long
(IPv6/UDP/RTP + Home Address option), that is 3 voice packets. One approach
used to handle surges in bandwidth is to puncture bits in payload. If you
were to do that, you need to effectively live with the drop of 9 voice
packets (24 bytes of payload + 4 bytes of header) for 3 IR headers! This is
user-perceived disruption _due to context initialization_. 


> But either way it doesn't seem to be a problem since you 
> said that context relocation (if needed) will solve this. Right ?
> 
> So I don't know why we (MIP WG) should be involved. 
> It seems to be a ROHC/SEAMOBY issue. 
> 

Well, I think header compression context relocation is doable in seamoby. We
need some help from rohc in defining what a context is, say e.g.,
IPv6/UDP/RTP/voice-G.723.1. 

I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
provide header compression support, which involves context initialization,
which in turn could be avoided during handovers using context relocation!

Regards,

-Rajeev


> Regards,
> Hesham
> 
> > -----Original Message-----
> > From:	zhigang.liu@nokia.com [SMTP:zhigang.liu@nokia.com]
> > Sent:	Friday, 30 March 2001 2:53
> > To:	claude.castelluccia@inrialpes.fr; zhigang.liu@nokia.com
> > Cc:	Hesham.Soliman@era.ericsson.se; 
> kempf@heliopolis.Eng.Sun.COM; micke@sm.luth.se; cabo@tzi.org; 
> mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se
> > Subject:	RE: [rohc] RE: Restarting Compressor on Mobile 
> IPv6 Handover
> > 
> > Hi Claude,
> > 
> > Context relocation is useful regardless of the loss of 
> packets during 
> > handover as the bulk of the saving (of bytes over the radio 
> links) comes 
> > from the static header fields. For example, the new compressor (for
> > downlink) 
> > can jump start in FO state in stead of going through IR 
> state all over
> > again.
> > 
> > We have been studying HC context relocation since spring 
> 1999 (when we 
> > started ACE). Khiem has proposed text to ROHC list in June 2000 
> > (http://www.cdt.luth.se/robhc/msg00508.html). 
> Unfortunately, that item was 
> > not included in ROHC I-D, partially due to the urgency to 
> finish the basic
> > ROHC scheme (plus objections from some of the ROHC authors). 
> > 
> > Now, it's time we give it a serious look.
> > 
> > Br,
> > Zhigang
> > 
> > -----Original Message-----
> > From: ext Claude Castelluccia 
> [mailto:claude.castelluccia@inrialpes.fr]
> > Sent: Thursday, March 29, 2001 1:40 AM
> > To: zhigang.liu@nokia.com
> > Cc: Hesham.Soliman@era.ericsson.se; kempf@heliopolis.Eng.Sun.COM;
> > micke@sm.luth.se; cabo@tzi.org; mobile-ip@sunroof.eng.sun.com;
> > rohc@cdt.luth.se
> > Subject: Re: [rohc] RE: Restarting Compressor on Mobile 
> IPv6 Handover
> > 
> > 
> >   
> > Hello Zhigang, 
> > I seems from your email that context relocation will be 
> very useful for
> > RoHC. 
> > Is istalso the case if some packets are lost  when a MN 
> moves from one base
> > station 
> > to another one? 
> > In this case it is better to restart the context or relocate it? 
> > Do you know of any studies on this topic? 
> > thanks a lot! 
> > Claude. 
> > zhigang.liu@nokia.com wrote: 
> > Hi, 
> >   
> >   
> > There are some guessing/assumptions behind the number (3-4). 
> > I'm not so sure that's always the case. The radio link condition 
> > before/after handover is likely be worse than normal condition. 
> > That may mean more packets could be lost (in this case, IR 
> packets). 
> > That will has impacts on the guessing of the number. 
> > Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> > they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> > for RTP/UDP/IPv6 headers). And most of the header fields 
> are static. 
> > That is the issue. With HC context relocation, there is no need to 
> > send the static fields over the air. The reduced overhead means 
> > less pain (e.g. delay, possible stealing or blanking of 
> voice payload). 
> > Note that smaller packets have lower chance to be hit by 
> transmission 
> > errors (even just one bit) and thus lost, assuming no link layer 
> > retransmission (which makes sense for real-time multimedia). 
> >  
> > -- 
> > 
> > ----------------------------------------
> > Claude CASTELLUCCIA, INRIA Rhone-Alpes  
> > ph:  +33 4.76.61.52.15 (fax: 52.52)
> > http://www.inrialpes.fr/planete/
> >   
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 14:02:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03906
	for ; Thu, 29 Mar 2001 14:02:17 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02968;
	Thu, 29 Mar 2001 11:02:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03181;
	Thu, 29 Mar 2001 11:01:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJ0IIm012320
	for ; Thu, 29 Mar 2001 11:00:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TJ0HTg012319
	for mobile-ip-dist; Thu, 29 Mar 2001 11:00:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJ08Im012312
	for ; Thu, 29 Mar 2001 11:00:08 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16238
	for ; Thu, 29 Mar 2001 11:00:08 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03798
	for ; Thu, 29 Mar 2001 12:00:06 -0700 (MST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2TJ05s11177
	for ; Thu, 29 Mar 2001 21:00:05 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 29 20:58:39 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 29 Mar 2001 21:00:04 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD01@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'rajeev.koodli@nokia.com'" ,
        zhigang.liu@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Thu, 29 Mar 2001 21:00:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Rajeev, 

> > So it seems ot me that there is no clear consensus in ROHC
> > on context relocation. Is that because the need is not proven ?
> > 
> 
> I did not get this picture when reading Zhigang's e-mail. 
> 
	=> Well I got the picture from other emails though ;)

> I believe he said
> rohc had to attend the urgent matter of a draft for IP/UDP/RTP compression.
> I guess the focus was on coming with a scheme that described the functioning
> of an rohc compression mechanism that would also include context
> initialization! Mobility, handover was perhaps outside the scope..
> 
	=> Ok. I'm not active in ROHC so I can't really guess the reasons,
	what I'm observing though is that the ROHC experts 
	do not have consensus on this. But this is outside our scope.

> > I guess we need to know how bad a channel can be. I might 
> > be completely wrong here but if we're only talking about 
> > a couple of packets to sync the compressor, then context
> > relocation seems to be an overkill. However, if the amount 
> > of packets sent with full headers is significant, then I can 
> > understand the need. 
> 
> I agree that we need a reasonable number. The number of packets needed to
> initialize the context, it appears, can vary. I have heard 3 packets before,
> but not two! The key issue is the compressor has to have "sufficient
> confidence" according to rohc draft. The issue of confidence is critical
> because of error conditions prevalent on cellular links. These errors could
> be worse across cell boundaries during handovers. Furthermore, you have to
> do context initialization for _each_ packet stream!
> 
> Also, I don't agree that context relocation is an overkill when few IR
> packets are needed. Consider a channel optimized for sending 24 bytes of
> voice payload and 4 bytes of header. Such CBR-like channels are common in
> cellular, I gather. Now, if you have to send a header 84 bytes long
> (IPv6/UDP/RTP + Home Address option), that is 3 voice packets. One approach
> used to handle surges in bandwidth is to puncture bits in payload. If you
> were to do that, you need to effectively live with the drop of 9 voice
> packets (24 bytes of payload + 4 bytes of header) for 3 IR headers! This is
> user-perceived disruption _due to context initialization_. 
> 
	=> I'm neutral to the above. All I wanted to know was if there
	was a problem ? and can this problem be solved ? The clear
	answer I'm getting is yes for the second part and that's 
	all I wanted to know.


> > But either way it doesn't seem to be a problem since you 
> > said that context relocation (if needed) will solve this. Right ?
> > 
> > So I don't know why we (MIP WG) should be involved. 
> > It seems to be a ROHC/SEAMOBY issue. 
> > 
> 
> Well, I think header compression context relocation is doable in seamoby. We
> need some help from rohc in defining what a context is, say e.g.,
> IPv6/UDP/RTP/voice-G.723.1. 
> 
	=> Good.

> I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
> provide header compression support, which involves context initialization,
> which in turn could be avoided during handovers using context relocation!
> 
	=> No, I disagree. IP_deployment_in cellular networks relies 
	on ROHC. MIPv4/v6 in general relies on ROHC to be deployed
	in cellular networks. This is the reality. If you're sending complete
	IP headers in a VOIP call, then I'll just stick to my GSM phone.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 14:08:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04416
	for ; Thu, 29 Mar 2001 14:08:29 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08222;
	Thu, 29 Mar 2001 11:08:10 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02197;
	Thu, 29 Mar 2001 11:08:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJ6gIm012354
	for ; Thu, 29 Mar 2001 11:06:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TJ6gZ9012353
	for mobile-ip-dist; Thu, 29 Mar 2001 11:06:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJ6XIm012346
	for ; Thu, 29 Mar 2001 11:06:33 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04288
	for ; Thu, 29 Mar 2001 11:06:33 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04476
	for ; Thu, 29 Mar 2001 11:06:32 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA08717;
	Thu, 29 Mar 2001 11:06:12 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF25815;
	Thu, 29 Mar 2001 11:06:06 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03709; Thu, 29 Mar 2001 11:06:06 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15043.34717.849084.517703@thomasm-u1.cisco.com>
Date: Thu, 29 Mar 2001 11:06:05 -0800 (PST)
To: zhigang.liu@nokia.com
Cc: Hesham.Soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com,
        rohc@cdt.luth.se, seamoby@diameter.org
Subject: [mobile-ip] [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460213BB73@daeis05nok>
References: <8572CF1E2A95D211A1190008C7EAA2460213BB73@daeis05nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

zhigang.liu@nokia.com writes:
 > (Side note: for hisorical and technical reasons, dealing with 
 > realtime VBR over radio links is much a headache than over wired 
 > links. )

   A-ha! That's one of the reasons I question whether
   ROHC is even appropriate on the air except in a
   very small subset of cases (usually long lived streams
   like RTP for which it was originally intended) As
   a general purpose tunnel/header compressor, I suspect it is going
   to have severe thrashing with the way that radio
   resources are doled out by the AP.

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 14:47:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06637
	for ; Thu, 29 Mar 2001 14:47:58 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06986;
	Thu, 29 Mar 2001 11:42:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10856;
	Thu, 29 Mar 2001 11:42:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJeaIm012468
	for ; Thu, 29 Mar 2001 11:40:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TJea4a012467
	for mobile-ip-dist; Thu, 29 Mar 2001 11:40:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJeOIm012460
	for ; Thu, 29 Mar 2001 11:40:24 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03389
	for ; Thu, 29 Mar 2001 11:40:24 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05314
	for ; Thu, 29 Mar 2001 11:40:23 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TJePg13136
	for ; Thu, 29 Mar 2001 13:40:25 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 13:40:22 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 13:40:22 -0600
Message-ID: 
To: zhigang.liu@nokia.com, Lars-Erik.Jonsson@epl.ericsson.se,
        micke@cs.arizona.edu, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        seamoby@cdma-2000.org
Subject: [mobile-ip] RE: [rohc] Compression startup behavior
Date: Thu, 29 Mar 2001 13:40:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> -----Original Message-----
> From: Liu Zhigang (NRC/Dallas) 
> Sent: Thursday, March 29, 2001 9:35 AM
> To: 'ext Lars-Erik Jonsson (EPL)'; Koodli Rajeev (NRC/MtView);
> micke@cs.arizona.edu; mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> seamoby@cdma-2000.org
> Subject: RE: [rohc] Compression startup behavior
> 
> 
> > No, the best case would be 1, 
> 
> ... if there are no transmission errors and the compressor knows
> this.
> 
> > while 3 probably would be a 
> > good candidate for realistic conditions and VERY FEASIBLE IN 
> > PRACTICE. If the systems are providing acceptable service 
> > quality, higher numbers should not be needed. 
> 
> 3 may or may not work. It depends. In cellular, "acceptable 
> service quality" means different thing at different time and 
> location (of the mobile node). When you are driving in your car 
> in a traffic jam at 5pm, a higher packet loss rate is acceptable 
> (to the operator, not you). The very reason that a handover
> occurs is due to poor radio conditions at the edge of a cell,
> which means you are also at the edge of the new cell after
> handover, which means the condition of the new channel probably
> will not be very good either. Those factors have to be 
> considered.
> 
> > We could probably argue about this for months (see ROHC 
> > mailing list from April 2000), so I will try not to continue 
> > this discussion. 
> 
> Oops, I just did. 
> 
> > I guess that context transfer is a mechanism 
> > that will be developed (snip)
> 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a good starting position.

Regards,

-Rajeev

> Good, at least we agree on one thing.
> 
    


> Br,
> Zhigang
>  
>  
> > Rgds,
> > /L-E
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
> > 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 15:00:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07448
	for ; Thu, 29 Mar 2001 15:00:44 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22291;
	Thu, 29 Mar 2001 12:00:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15594;
	Thu, 29 Mar 2001 12:00:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJwfIm012520
	for ; Thu, 29 Mar 2001 11:58:41 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TJwfZl012519
	for mobile-ip-dist; Thu, 29 Mar 2001 11:58:41 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJwWIm012512
	for ; Thu, 29 Mar 2001 11:58:32 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08412;
	Thu, 29 Mar 2001 11:58:31 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA28525;
	Thu, 29 Mar 2001 11:58:31 -0800 (PST)
Message-Id: <200103291958.LAA28525@heliopolis.Eng.Sun.COM>
Date: Thu, 29 Mar 2001 11:58:31 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
To: zhigang.liu@nokia.com, mobile-ip@sunroof.eng.sun.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mzGC3ZtgiJm5vHWIq1HmIg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham,


>So I don't know why we (MIP WG) should be involved. 
>It seems to be a ROHC/SEAMOBY issue. 
>

The reason the MIP working group has to be involved is we currently
have a design team working on MIPv6 fast handoff. If it takes
120 ms to restart the header compressor when the mobile node moves,
that work will be negated. We don't have to be involved in the
details, but we at least have to know:

	1) That either header compression can restart fast
	or with context transfer and updating of the context using
	the new CoA.
	
	2) That the same fast restart of header compression will work
	for proposed additions where extra header state is involved,
	such as HMIPv6 extended mode.
	
We can't simply assume that a technology is there and works the way
we want it without verifying the facts.

That said, there is no reason why the MIP group needs to be involved in the 
details of the design. We just need to state our requirements to Seamoby and
ROHC and let them take it from there. The above two points represent
requirements, IMHO.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 15:14:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08304
	for ; Thu, 29 Mar 2001 15:14:12 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00798;
	Thu, 29 Mar 2001 12:01:48 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16005;
	Thu, 29 Mar 2001 12:01:36 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TK01Im012533
	for ; Thu, 29 Mar 2001 12:00:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TK00cn012532
	for mobile-ip-dist; Thu, 29 Mar 2001 12:00:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TJxoIm012525
	for ; Thu, 29 Mar 2001 11:59:51 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17984
	for ; Thu, 29 Mar 2001 11:59:50 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12051
	for ; Thu, 29 Mar 2001 12:59:49 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22651
	for ; Thu, 29 Mar 2001 11:59:48 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2TJxin03482
	for ; Thu, 29 Mar 2001 11:59:44 -0800
X-mProtect:  Thu, 29 Mar 2001 11:59:44 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdPeCZ7a; Thu, 29 Mar 2001 11:59:31 PST
Message-ID: <3AC39427.1628C65F@cs.ucl.ac.uk>
Date: Thu, 29 Mar 2001 11:59:35 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets f or 
 Extended mode
References: <034BEFD03799D411A59F00508BDF7546013DBCFD@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

   you either don't want to understand what I am saying or the email program
manages to shuffle my writing so that it arrives
to you in the way you want to interpret it... :)

The MN's HA has a binding. The first time that the MN moves under the MR/MAP it
will use as CoA the LCoA. But hey this is the home address of the MR. Needless to
say the protocol couldn't care less about that. It is just a LCoA of the MR/MAP
(So forget the term home address of the MR in this book..)

Packets from the MN's HA would arrive tunneled at that LCoA (route unoptimized)
(one tunnel)
In that time the vehicle that was carrying that MR/MAP  went away. That means to
me, that the MR acts as an HMIPv6 node and as a MR/MAP. So what does it do? It
gets itself a RCoA on a fixed MAP (Hello Basic Mode). That fixed MAP will tunnel
all packets sent to that RCoA.


NOW......the packet that was destined to the old LCoA of the MR/MAP (binding did
not get updated yet since the packet left after the vehicle went away, like an
aircraft would do). So what happens, the packet arrives at the domain of the
MR/MAP (since destined to its LCoA), the HA  of THAT MR/MAP will intercept it and
tunnel it blindly to the RCoA of its node (MR/MAP).

So the fixed MAP will receive it. As a nice HA instantiation it will see it was
destined for the RCoA get the binding entry and tunnel again the packet to the
LCoA of the MR/MAP. That is the binding of the node that registered THAT RCoA.

If you count the tunnelings are 3.

At some time point X the MN will send a BU to the HA that updates the binding, to
be the MAP/MR. However, in the mean time the MN's HA would have to send packets
to its old CoA (MR old LCoA).


I do not think I confuse anything. I simply describe how your protocol works in
that case.

Also you have not mentioned how is the distance metric evaluated in the selection
of the MAP in the extended mode. I can only assume shortest one is selected.

Theo

UCL/ Mobile Systems


"Hesham Soliman (ERA)" wrote:

> > >         - A handover works like this :
> > >         The MR moves (uses FH or anything else), it advrtises
> > >         a new MAP's address for the MNs behind it. The MNs
> > >         then register the new address with the (fixed) MAP.
> >
> > sure the moving MAP advertises its new LCoA...to the MN's that hang
> > underneath it...we knew that
> >
>         => Then why do you assume that packets are sent to the MR's
>         Home address (below)? Are these packets addressed to
>         the MN or the MR ?
>
> > think what happens when a route unoptimized packet leaves the MN's HA..what
> > happens... (one tunnel already)
> >
> > it will have to arrive at the domain of the supporting MAP (but this is
> > mobile). Since the packet is addressed to MR's home address , the MR's HA
> > will HAVE to intercept it
> >
>         => As the draft says the packets are addressed to the MR's CoA.
>
> >  and tunnel it to the RCoA it has for it MR (here
> > the MR acts as a plain HMIPv6 node). We have two tunnels already..
> >
> > Once the packet arrives at the RCoA of the MR it will have to be intercepted
> > by its MAP (which must be working at Basic mode since it is not an MR)
> >
>         => From the draft:
>         " 7. Extended mode: Supporting Mobile Nodes and Mobile Networks"
>            The Extended mode of operation can support both Mobile Nodes and
>            Mobile networks."
>
>         I don't know why you assume the a MAP is only operating in
>         extended mode if it's MR. Did the draft give that impression ?
>         If so please let us know where.
>
>         Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 16:10:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11097
	for ; Thu, 29 Mar 2001 16:10:55 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14041;
	Thu, 29 Mar 2001 13:10:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17044;
	Thu, 29 Mar 2001 13:10:30 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TL8IIm012857
	for ; Thu, 29 Mar 2001 13:08:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TL8Il3012856
	for mobile-ip-dist; Thu, 29 Mar 2001 13:08:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TL81Im012849
	for ; Thu, 29 Mar 2001 13:08:01 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02020
	for ; Thu, 29 Mar 2001 13:07:55 -0800 (PST)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11906
	for ; Thu, 29 Mar 2001 13:07:54 -0800 (PST)
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 29 Mar 2001 16:02:48 -0500
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] QoS Work Item
Date: Thu, 29 Mar 2001 16:02:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


	We have a charter item to consider the relationship between MIP and
QoS.  That's pretty vague.  We've seen a couple of drafts on this, and
actually have a request to make one a working group item.  This is
premature.  The working group needs to consider what exactly we need to do.

Our charter says:  "In the longer term, the WG needs to address: 
- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP." 

The problem is that MNs may be using QoS mechanisms on their flows and these
MNs will sometimes move using MIP mechanisms.  We have some options to
explore about how to address this.  We could address QoS issues related
specifically to mobile IP in this WG based on QoS work done in other WGs
(DiffServ, IntServ).  We could just provide requirements from a MIP
perspective to WGs working on these QoS mechanisms and ask them to solve it.
We could work jointly with folks in other working groups to produce some
proposals about how to proceed.  It is clear we don't have the option to
invent another QoS protocol and we shouldn't be doing this work in
isolation.

So, we'd like to know the working group's opinion on the direction we take.





From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 16:38:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12464
	for ; Thu, 29 Mar 2001 16:38:27 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14239;
	Thu, 29 Mar 2001 13:37:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22566;
	Thu, 29 Mar 2001 13:36:52 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TLZ4Im012916
	for ; Thu, 29 Mar 2001 13:35:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TLZ4aG012915
	for mobile-ip-dist; Thu, 29 Mar 2001 13:35:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TLYuIm012908
	for ; Thu, 29 Mar 2001 13:34:56 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2TLYsWI445297;
	Thu, 29 Mar 2001 13:34:54 -0800 (PST)
Message-Id: <200103292134.f2TLYsWI445297@jurassic.eng.sun.com>
Date: Thu, 29 Mar 2001 13:35:55 -0800 (PST)
From: Samita Chakrabarti 
Subject: Re: [mobile-ip] QoS Work Item
To: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: gvZJkBkEAYCuvR3WRzFZuQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Phil,

> Our charter says:  "In the longer term, the WG needs to address: 
> - QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP." 
> 
> The problem is that MNs may be using QoS mechanisms on their flows and these
> MNs will sometimes move using MIP mechanisms.  We have some options to
> explore about how to address this.  We could address QoS issues related
> specifically to mobile IP in this WG based on QoS work done in other WGs
> (DiffServ, IntServ).  We could just provide requirements from a MIP
> perspective to WGs working on these QoS mechanisms and ask them to solve it.
> We could work jointly with folks in other working groups to produce some
> proposals about how to proceed.  It is clear we don't have the option to
> invent another QoS protocol and we shouldn't be doing this work in
> isolation.
> 

Having requirements from mobile-ip WG is an excellent idea.
In addition to Qos behavior in MNs, we would also need to find 
out Qos requirements in Home agents, access routers  and as well
as qos in hierarchical mobile IP scenarios. An analysis of diffserv and
intserv  cases will be also useful.

Thanks,
-Samita

> So, we'd like to know the working group's opinion on the direction we take.
> 
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 17:22:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14380
	for ; Thu, 29 Mar 2001 17:22:24 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13329;
	Thu, 29 Mar 2001 14:22:05 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22467;
	Thu, 29 Mar 2001 14:22:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMKWIm012991
	for ; Thu, 29 Mar 2001 14:20:32 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TMKWgo012990
	for mobile-ip-dist; Thu, 29 Mar 2001 14:20:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMKNIm012983
	for ; Thu, 29 Mar 2001 14:20:23 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22032
	for ; Thu, 29 Mar 2001 14:20:24 -0800 (PST)
Received: from hotmail.com (f86.law7.hotmail.com [216.33.237.86])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06609
	for ; Thu, 29 Mar 2001 15:20:18 -0700 (MST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Mar 2001 14:20:18 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;	Thu, 29 Mar 2001 22:20:18 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
Date: Thu, 29 Mar 2001 22:20:18 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 29 Mar 2001 22:20:18.0261 (UTC) FILETIME=[6F92D050:01C0B89E]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,
It will be a good idea to use some premises while discussing this issue 
(please feel free to add to this list):

1. We should concentrate on QoS _signaling_ protocol that a  _host _ would 
use to signal the QoS requirement of its flows along the new end-to-end 
path. Please note the distinction between the

QoS protocols as used by network domains/routers for purposes such as QoS 
management, admission control, setting up LSPs or Label switched paths, 
MPLS-TE, Diffserv SLAs etc.

and

the QoS _signaling_ protocol used by _host_.
As long as the QoS _signaling_ protocol can deliver sufficient (possible 
more) information to the network/router level QoS modules, it interoperates 
with the QoS modules in the end-to-end path. It should not matter if this 
flow-level information (QoS requirement, traffic volume, packet 
classification parameters etc.) is delivered to the router by QoS signaling 
protocol X or Y.

2. QoS signaling protocol must work with heterogeneous QoS schemes: IntServ, 
DiffServ or MPLS. MN may switch between IntServ and DiffServ access domains 
due to handovers. Also, handover may cause the path in the core network 
(which may be using MPLS) to change as well (consider handover between 
indoor LAN and cellular network).

3. We need to consider _fast_ QoS signaling along the new end-to-end path 
after handover. It is not acceptable that the QoS signaling scheme takes one 
round trip time (as in RSVP) before QoS contexts are set up in the 
intermediate nodes after handover. Note that handover may occur in the 
middle of running QoS-sensitive session such as VoIP session.

4. We need to discuss what is more important from mobility perspective. Few 
examples are as follows:

- QoS signaling protocol such as RSVP has been optimized with central focus 
on multicast. However, Mobile IP is not used if MN is receiving multicast 
session. In other words, in multicast case there are no binding messages, MN 
uses IGMP to register at the new AR.

- Should QoS signaling protocol be designed with central focus on topology 
changes or frequent handoffs.

- Pure static policy based QoS may not work in mobile environment. For 
example, MN may land up in the visited domain during a session where its 
flow parameters are not compliant with the QoS policy parameters in that 
domain. For example, the policy in the visited network may be to use port 
number x for an EF call and y for best effort if you are accessing Internet 
from that domain. However, MN already using port y for VoIP session may land 
up in this visited domain.

Prioritizing these issues from mobility perspective will be important as 
single QoS _signaling_ protocol may not satisfy all the requirements.

5. Interoperability and optimization with micro-mobility solutions. Here, we 
should also think if we need to provide QoS _signaling_ solution at IP layer 
or transport layer. Micro-mobility information is most readily available at 
IP layer. A secondary issue that arises here is whether CoA information 
should be accessible anywhere above IP layer. Because if transport layer 
protocol can grab this information, any other application can also do so 
thereby causing privacy concerns.

6. We need thin protocol as it may not be desirable to add another protocol 
software on sleek mobile terminals.

7. Issues like security, scalability are important as they always have been.

8. What other working groups may find this item within their scope? 
Definitely not MPLS, DiffServ or IntServ as they would not care how the 
information used by them arrives at a router. RSVP WG studies RSVP by its 
very name. However, RSVP, at least as it exists today, is not suitable to be 
used with Mobile IP. And also, its not only a small tweak to it that would 
work. It would be a major revision.

Hemant


>From: Phil Roberts Reply-To: mobile-ip@sunroof.eng.sun.com To: 
>"'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] QoS Work Item Date: 
>Thu, 29 Mar 2001 16:02:43 -0500
>
>
>We have a charter item to consider the relationship between MIP and QoS. 
>That's pretty vague. We've seen a couple of drafts on this, and actually 
>have a request to make one a working group item. This is premature. The 
>working group needs to consider what exactly we need to do.
>
>Our charter says: "In the longer term, the WG needs to address: - QoS in 
>the mobile IP environment using diff-serv and/or int-serv/RSVP."
>
>The problem is that MNs may be using QoS mechanisms on their flows and 
>these MNs will sometimes move using MIP mechanisms. We have some options to 
>explore about how to address this. We could address QoS issues related 
>specifically to mobile IP in this WG based on QoS work done in other WGs 
>(DiffServ, IntServ). We could just provide requirements from a MIP 
>perspective to WGs working on these QoS mechanisms and ask them to solve 
>it. We could work jointly with folks in other working groups to produce 
>some proposals about how to proceed. It is clear we don't have the option 
>to invent another QoS protocol and we shouldn't be doing this work in 
>isolation.
>
>So, we'd like to know the working group's opinion on the direction we take.
>
>
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 17:41:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15261
	for ; Thu, 29 Mar 2001 17:41:45 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12366;
	Thu, 29 Mar 2001 14:34:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07677;
	Thu, 29 Mar 2001 14:33:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMVqIm013044
	for ; Thu, 29 Mar 2001 14:31:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TMVpHJ013043
	for mobile-ip-dist; Thu, 29 Mar 2001 14:31:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMVgIm013036
	for ; Thu, 29 Mar 2001 14:31:42 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07309
	for ; Thu, 29 Mar 2001 14:31:44 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA02586
	for ; Thu, 29 Mar 2001 14:31:43 -0800 (PST)
Message-Id: <200103292231.OAA02586@heliopolis.Eng.Sun.COM>
Date: Thu, 29 Mar 2001 14:31:43 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] QoS Work Item
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: luuIbm39P5uB3ku2NrO9tQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Phil,

I believe there was a Next Steps in Signalling BOF at IETF 50 where many people
presented requirements for mobile QoS. I do not know what the outcome
of that BOF will be, but I think we should work together with them,
closely, to make sure the next QoS signalling protocol meets the
needs of mobile IP.  If we do make any QoS drafts working group
drafts (and I will reserve my opinion on whether that should be done
until I know the draft), I think they should be informational only.

My 0.02 won.

		jak





From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 17:47:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15569
	for ; Thu, 29 Mar 2001 17:47:31 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05040;
	Thu, 29 Mar 2001 14:47:12 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11454;
	Thu, 29 Mar 2001 14:47:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMjvIm013109
	for ; Thu, 29 Mar 2001 14:45:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TMjvbH013108
	for mobile-ip-dist; Thu, 29 Mar 2001 14:45:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMjiIm013095
	for ; Thu, 29 Mar 2001 14:45:44 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28413
	for ; Thu, 29 Mar 2001 14:45:45 -0800 (PST)
Received: from sun.com (vpn-129-150-4-14.EBay.Sun.COM [129.150.4.14])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA19203
	for ; Thu, 29 Mar 2001 14:45:43 -0800 (PST)
Message-ID: <3AC3B7C2.8E2A3420@sun.com>
Date: Fri, 30 Mar 2001 00:31:30 +0200
From: gabriel montenegro 
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hemant Chaskar wrote:

> 8. What other working groups may find this item within their scope?
> Definitely not MPLS, DiffServ or IntServ as they would not care how the
> information used by them arrives at a router. RSVP WG studies RSVP by its
> very name. However, RSVP, at least as it exists today, is not suitable to be
> used with Mobile IP. And also, its not only a small tweak to it that would
> work. It would be a major revision.

did anybody follow or try to submit requirements to the nsis bof?
does that seem like an appropriate venue for this?

http://www.ietf.org/ietf/01mar/nsis-agenda.txt

-gabriel



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 17:54:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15978
	for ; Thu, 29 Mar 2001 17:54:45 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19755;
	Thu, 29 Mar 2001 14:50:28 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10894;
	Thu, 29 Mar 2001 14:44:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMhYIm013083
	for ; Thu, 29 Mar 2001 14:43:35 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TMhYQ6013082
	for mobile-ip-dist; Thu, 29 Mar 2001 14:43:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMhPIm013075
	for ; Thu, 29 Mar 2001 14:43:25 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10553
	for ; Thu, 29 Mar 2001 14:43:26 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02005
	for ; Thu, 29 Mar 2001 14:43:26 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01972;
	Thu, 29 Mar 2001 14:43:28 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF31671;
	Thu, 29 Mar 2001 14:43:24 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03728; Thu, 29 Mar 2001 14:43:23 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15043.47754.920212.285536@thomasm-u1.cisco.com>
Date: Thu, 29 Mar 2001 14:43:22 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: PRoberts@MEGISTO.com
Subject: Re: [mobile-ip] QoS Work Item
In-Reply-To: <200103292134.f2TLYsWI445297@jurassic.eng.sun.com>
References: <200103292134.f2TLYsWI445297@jurassic.eng.sun.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Samita, 

You might take a look at my draft about RSVP and
mobility if you haven't already
(draft-thomas-seamoby-rsvp-analysis-00). It goes
into some detail trying to make sense of what the
current state of affairs is with the intersection
of Intserv and MIPv6. It's not perfect, but it at
least outlines quite a few of the challenges we
face. The same kind of analysis needs to be done
for diffserv and MIP too, as you suggest.

The one thing I would add to your and Phil's list
is cross-realm policy. QoS models currently are
very single domain oriented. From what I can
gather, how policy based admission control works
when you're visiting a different domain is not
especially well understood. I tried to lay out
some of the issues with it as well (and some of
them probably apply to diffserv as well), but much
more work is needed here. Cross realm policy in
the form of the correct settlement models and user
authentication are going to be interesting
problems for interesting times.

	     Mike

Samita Chakrabarti writes:
 > Hi Phil,
 > 
 > > Our charter says:  "In the longer term, the WG needs to address: 
 > > - QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP." 
 > > 
 > > The problem is that MNs may be using QoS mechanisms on their flows and these
 > > MNs will sometimes move using MIP mechanisms.  We have some options to
 > > explore about how to address this.  We could address QoS issues related
 > > specifically to mobile IP in this WG based on QoS work done in other WGs
 > > (DiffServ, IntServ).  We could just provide requirements from a MIP
 > > perspective to WGs working on these QoS mechanisms and ask them to solve it.
 > > We could work jointly with folks in other working groups to produce some
 > > proposals about how to proceed.  It is clear we don't have the option to
 > > invent another QoS protocol and we shouldn't be doing this work in
 > > isolation.
 > > 
 > 
 > Having requirements from mobile-ip WG is an excellent idea.
 > In addition to Qos behavior in MNs, we would also need to find 
 > out Qos requirements in Home agents, access routers  and as well
 > as qos in hierarchical mobile IP scenarios. An analysis of diffserv and
 > intserv  cases will be also useful.
 > 
 > Thanks,
 > -Samita
 > 
 > > So, we'd like to know the working group's opinion on the direction we take.
 > > 
 > > 
 > > 
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:00:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16243
	for ; Thu, 29 Mar 2001 18:00:39 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24432;
	Thu, 29 Mar 2001 14:59:45 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01428;
	Thu, 29 Mar 2001 14:59:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMw9Im013143
	for ; Thu, 29 Mar 2001 14:58:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TMw8kO013141
	for mobile-ip-dist; Thu, 29 Mar 2001 14:58:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TMvwIm013132
	for ; Thu, 29 Mar 2001 14:57:59 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01116
	for ; Thu, 29 Mar 2001 14:58:00 -0800 (PST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01155
	for ; Thu, 29 Mar 2001 15:57:58 -0700 (MST)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 29 Mar 2001 16:42:57 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 29 Mar 2001 16:42:42 -0600
Message-ID: 
From: "Haseeb Akhtar" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] QoS Work Item
Date: Thu, 29 Mar 2001 16:42:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B8A1.8F3478C0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B8A1.8F3478C0
Content-Type: text/plain;
	charset="iso-8859-1"

Phil,

It is obvious from the long email exchanges that we have seen 
before the IETF week that the QoS groups, at least as it 
exists today, may not necessarily cater to the problems/perspectives
that are germane to mobility. 

Having said that, I also believe we should utilize the rich 
experiences of the intserv/diffserv/RSVP folks.

I propose this group comes up with the requirements and then form
a design team (that comprises of the both sides - QoS groups and us) 
to come up with a solution.

Regards,

Haseeb


-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Thursday, March 29, 2001 3:03 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] QoS Work Item



	We have a charter item to consider the relationship between MIP and
QoS.  That's pretty vague.  We've seen a couple of drafts on this, and
actually have a request to make one a working group item.  This is
premature.  The working group needs to consider what exactly we need to do.

Our charter says:  "In the longer term, the WG needs to address: 
- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP." 

The problem is that MNs may be using QoS mechanisms on their flows and these
MNs will sometimes move using MIP mechanisms.  We have some options to
explore about how to address this.  We could address QoS issues related
specifically to mobile IP in this WG based on QoS work done in other WGs
(DiffServ, IntServ).  We could just provide requirements from a MIP
perspective to WGs working on these QoS mechanisms and ask them to solve it.
We could work jointly with folks in other working groups to produce some
proposals about how to proceed.  It is clear we don't have the option to
invent another QoS protocol and we shouldn't be doing this work in
isolation.

So, we'd like to know the working group's opinion on the direction we take.




------_=_NextPart_001_01C0B8A1.8F3478C0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] QoS Work Item




Phil,




It is obvious from the long email exchanges that we have seen 

before the IETF week that the QoS groups, at least as it 

exists today, may not necessarily cater to the problems/perspectives

that are germane to mobility. 




Having said that, I also believe we should utilize the rich 

experiences of the intserv/diffserv/RSVP folks.




I propose this group comes up with the requirements and then form

a design team (that comprises of the both sides - QoS groups and us) 

to come up with a solution.




Regards,




Haseeb






-----Original Message-----

From: Phil Roberts [mailto:PRoberts@MEGISTO.com]

Sent: Thursday, March 29, 2001 3:03 PM

To: 'mobile-ip@sunroof.eng.sun.com'

Subject: [mobile-ip] QoS Work Item








        We have a charter item to consider the relationship between MIP and

QoS.  That's pretty vague.  We've seen a couple of drafts on this, and

actually have a request to make one a working group item.  This is

premature.  The working group needs to consider what exactly we need to do.




Our charter says:  "In the longer term, the WG needs to address: 

- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP." 




The problem is that MNs may be using QoS mechanisms on their flows and these

MNs will sometimes move using MIP mechanisms.  We have some options to

explore about how to address this.  We could address QoS issues related

specifically to mobile IP in this WG based on QoS work done in other WGs

(DiffServ, IntServ).  We could just provide requirements from a MIP

perspective to WGs working on these QoS mechanisms and ask them to solve it.

We could work jointly with folks in other working groups to produce some

proposals about how to proceed.  It is clear we don't have the option to

invent another QoS protocol and we shouldn't be doing this work in

isolation.




So, we'd like to know the working group's opinion on the direction we take.









------_=_NextPart_001_01C0B8A1.8F3478C0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:04:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16506
	for ; Thu, 29 Mar 2001 18:04:51 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26846;
	Thu, 29 Mar 2001 15:04:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02401;
	Thu, 29 Mar 2001 15:04:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN37Im013185
	for ; Thu, 29 Mar 2001 15:03:08 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TN37nT013184
	for mobile-ip-dist; Thu, 29 Mar 2001 15:03:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN2pIm013177
	for ; Thu, 29 Mar 2001 15:02:51 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21006
	for ; Thu, 29 Mar 2001 15:02:52 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06202
	for ; Thu, 29 Mar 2001 15:02:50 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA14680;
	Thu, 29 Mar 2001 15:02:28 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADF32227;
	Thu, 29 Mar 2001 15:02:22 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA03731; Thu, 29 Mar 2001 15:02:22 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15043.48894.645943.523182@thomasm-u1.cisco.com>
Date: Thu, 29 Mar 2001 15:02:22 -0800 (PST)
To: "Dr. Carsten Bormann" 
Cc: "Michael Thomas" , ,
        , ,
        , 
Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
In-Reply-To: 
References: <15043.34717.849084.517703@thomasm-u1.cisco.com>
	
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Dr. Carsten Bormann writes:
 > >  > (Side note: for hisorical and technical reasons, dealing with
 > >  > realtime VBR over radio links is much a headache than over wired
 > >  > links. )
 > >
 > >    A-ha! That's one of the reasons I question whether
 > >    ROHC is even appropriate on the air except in a
 > >    very small subset of cases (usually long lived streams
 > >    like RTP for which it was originally intended) As
 > >    a general purpose tunnel/header compressor, I suspect it is going
 > >    to have severe thrashing with the way that radio
 > >    resources are doled out by the AP.
 > 
 > I'm not sure why you are saying that (apart from the fact that we haven't
 > really done anything else but ROHC RTP yet).  How is ROHC worse than
 > uncompressed IP or 2507-compressed IP?

Carsten,

My understanding about cellular traffic channels
-- and I would be happy to find out differently --
is that they do not deal well with variable rate
traffic well. This is unsurprising since they are
heavily optimized for voice traffic which has very
regular periodicity and payload sizes. DOCSIS
cable is somewhat similar (with which I'm much
more familar), and the fixed size slots cause
variable rate coders like CRTP and ROHC much grief
because the MAC scheduler does not have the
ability to occassionally allow larger packets in
real time on an unsolicited grant SID; if you
start a session with packets every 20ms with 80
bytes of payload, that's exactly what you get. If
you occasionally need to send 81 bytes, you cannot
send it on that traffic channel.

This presents a real problem for CRTP and ROHC
when they need to send full headers or first order
changes.  For this reason, the cable folks perform
what they call Payload Header Suppression instead.
Basically, it's just a first order compressor
which is always on (sorry, if I've got your
nomenclature mixed up). This obviously works, but
is not as efficient. Also, I have no idea how it
compares in robustness.

Now, it may be that the cellular MAC's and PHY's
need some retooling in the long run in which case
ROHC will work better, but if they work like I
think they do, it's going to be problematic in the
intervening time.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:07:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16677
	for ; Thu, 29 Mar 2001 18:07:45 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20090;
	Thu, 29 Mar 2001 15:07:27 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03317;
	Thu, 29 Mar 2001 15:07:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN66Im013217
	for ; Thu, 29 Mar 2001 15:06:06 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TN65sR013216
	for mobile-ip-dist; Thu, 29 Mar 2001 15:06:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN5rIm013206
	for ; Thu, 29 Mar 2001 15:05:53 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02860
	for ; Thu, 29 Mar 2001 15:05:49 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08041
	for ; Thu, 29 Mar 2001 15:05:48 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id SAA23926
	for ; Thu, 29 Mar 2001 18:05:38 -0500 (EST)
Posted-Date: Thu, 29 Mar 2001 18:10:19 -0500
Message-Id: <10103292310.AA15275@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
	id ; Thu, 29 Mar 01 18:10:20 EST
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item 
In-Reply-To: Your message of Fri, 30 Mar 2001 00:31:30 +0200.
             <3AC3B7C2.8E2A3420@sun.com> 
Date: Thu, 29 Mar 2001 18:10:19 -0500
From: Allison Mankin 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Gabriel Montenegro wrote:

> did anybody follow or try to submit requirements to the nsis bof?
> does that seem like an appropriate venue for this?
> 
> http://www.ietf.org/ietf/01mar/nsis-agenda.txt
> 

The NSIS BOF did surface a lot of requirements for QoS signaling
in mobile IP.  

Scott and I (the ADs) are starting to formulate a possible
working group that would address the topic.  Watch the IETF
mailing list for an announcement of an nsis discussion mailing
list and more progress soon.

Allison 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:16:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17108
	for ; Thu, 29 Mar 2001 18:16:36 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26929;
	Thu, 29 Mar 2001 15:04:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21356;
	Thu, 29 Mar 2001 15:04:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN2MIm013175
	for ; Thu, 29 Mar 2001 15:02:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TN2M9j013174
	for mobile-ip-dist; Thu, 29 Mar 2001 15:02:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TN2DIm013167
	for ; Thu, 29 Mar 2001 15:02:13 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14874
	for ; Thu, 29 Mar 2001 15:02:14 -0800 (PST)
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27851
	for ; Thu, 29 Mar 2001 15:02:12 -0800 (PST)
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id SAA11256 for ; Thu, 29 Mar 2001 18:02:09 -0500 (EST)
From: "Andrew T. Campbell" 
To: 
Subject: RE: [mobile-ip] QoS Work Item
Date: Thu, 29 Mar 2001 18:01:34 -0800
Message-ID: <005501c0b8bd$59c0a120$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: 
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

I think the application of diffserv control to the
wireless domain make good sense as a starting
point. But there are many open questions there.

Signaling is another issue. May be point-to-point
implicit/explicit signaling makes sense for some
continuous media services with holding times. But for web
data its not practical - but some QOS control
may be need for that web data.

Clearly, there is no divorcing the wireless MAC capability
from the solution space. We found that you could
provide some simple support for wireless diffserv
providing effective admission control:

Barry, M., Campbell, A.T and A. Veres , "Distributed Control Algorithms for
Service Differentiation in Wireless Packet Networks ", Proc. IEEE
INFOCOM'2001, Anchorage, Alaska, 2001

http://www.comet.columbia.edu/~campbell/andrew/publications/papers/infocom20
01.pdf

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of
> Hemant Chaskar
> Sent: Thursday, March 29, 2001 10:20 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] QoS Work Item
>
>
> Hi,
> It will be a good idea to use some premises while discussing
> this issue
> (please feel free to add to this list):
>
> 1. We should concentrate on QoS _signaling_ protocol that a
> _host _ would
> use to signal the QoS requirement of its flows along the new
> end-to-end
> path. Please note the distinction between the
>
> QoS protocols as used by network domains/routers for purposes
> such as QoS
> management, admission control, setting up LSPs or Label
> switched paths,
> MPLS-TE, Diffserv SLAs etc.
>
> and
>
> the QoS _signaling_ protocol used by _host_.
> As long as the QoS _signaling_ protocol can deliver
> sufficient (possible
> more) information to the network/router level QoS modules, it
> interoperates
> with the QoS modules in the end-to-end path. It should not
> matter if this
> flow-level information (QoS requirement, traffic volume, packet
> classification parameters etc.) is delivered to the router by
> QoS signaling
> protocol X or Y.
>
> 2. QoS signaling protocol must work with heterogeneous QoS
> schemes: IntServ,
> DiffServ or MPLS. MN may switch between IntServ and DiffServ
> access domains
> due to handovers. Also, handover may cause the path in the
> core network
> (which may be using MPLS) to change as well (consider
> handover between
> indoor LAN and cellular network).
>
> 3. We need to consider _fast_ QoS signaling along the new
> end-to-end path
> after handover. It is not acceptable that the QoS signaling
> scheme takes one
> round trip time (as in RSVP) before QoS contexts are set up in the
> intermediate nodes after handover. Note that handover may
> occur in the
> middle of running QoS-sensitive session such as VoIP session.
>
> 4. We need to discuss what is more important from mobility
> perspective. Few
> examples are as follows:
>
> - QoS signaling protocol such as RSVP has been optimized with
> central focus
> on multicast. However, Mobile IP is not used if MN is
> receiving multicast
> session. In other words, in multicast case there are no
> binding messages, MN
> uses IGMP to register at the new AR.
>
> - Should QoS signaling protocol be designed with central
> focus on topology
> changes or frequent handoffs.
>
> - Pure static policy based QoS may not work in mobile
> environment. For
> example, MN may land up in the visited domain during a
> session where its
> flow parameters are not compliant with the QoS policy
> parameters in that
> domain. For example, the policy in the visited network may be
> to use port
> number x for an EF call and y for best effort if you are
> accessing Internet
> from that domain. However, MN already using port y for VoIP
> session may land
> up in this visited domain.
>
> Prioritizing these issues from mobility perspective will be
> important as
> single QoS _signaling_ protocol may not satisfy all the requirements.
>
> 5. Interoperability and optimization with micro-mobility
> solutions. Here, we
> should also think if we need to provide QoS _signaling_
> solution at IP layer
> or transport layer. Micro-mobility information is most
> readily available at
> IP layer. A secondary issue that arises here is whether CoA
> information
> should be accessible anywhere above IP layer. Because if
> transport layer
> protocol can grab this information, any other application can
> also do so
> thereby causing privacy concerns.
>
> 6. We need thin protocol as it may not be desirable to add
> another protocol
> software on sleek mobile terminals.
>
> 7. Issues like security, scalability are important as they
> always have been.
>
> 8. What other working groups may find this item within their scope?
> Definitely not MPLS, DiffServ or IntServ as they would not
> care how the
> information used by them arrives at a router. RSVP WG studies
> RSVP by its
> very name. However, RSVP, at least as it exists today, is not
> suitable to be
> used with Mobile IP. And also, its not only a small tweak to
> it that would
> work. It would be a major revision.
>
> Hemant
>
>
> >From: Phil Roberts Reply-To: mobile-ip@sunroof.eng.sun.com To:
> >"'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] QoS
> Work Item Date:
> >Thu, 29 Mar 2001 16:02:43 -0500
> >
> >
> >We have a charter item to consider the relationship between
> MIP and QoS.
> >That's pretty vague. We've seen a couple of drafts on this,
> and actually
> >have a request to make one a working group item. This is
> premature. The
> >working group needs to consider what exactly we need to do.
> >
> >Our charter says: "In the longer term, the WG needs to
> address: - QoS in
> >the mobile IP environment using diff-serv and/or int-serv/RSVP."
> >
> >The problem is that MNs may be using QoS mechanisms on their
> flows and
> >these MNs will sometimes move using MIP mechanisms. We have
> some options to
> >explore about how to address this. We could address QoS
> issues related
> >specifically to mobile IP in this WG based on QoS work done
> in other WGs
> >(DiffServ, IntServ). We could just provide requirements from a MIP
> >perspective to WGs working on these QoS mechanisms and ask
> them to solve
> >it. We could work jointly with folks in other working groups
> to produce
> >some proposals about how to proceed. It is clear we don't
> have the option
> >to invent another QoS protocol and we shouldn't be doing
> this work in
> >isolation.
> >
> >So, we'd like to know the working group's opinion on the
> direction we take.
> >
> >
> >
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:17:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17167
	for ; Thu, 29 Mar 2001 18:17:46 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28167;
	Thu, 29 Mar 2001 15:17:33 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05521;
	Thu, 29 Mar 2001 15:17:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNG3Im013254
	for ; Thu, 29 Mar 2001 15:16:03 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TNG2le013253
	for mobile-ip-dist; Thu, 29 Mar 2001 15:16:02 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNFrIm013246
	for ; Thu, 29 Mar 2001 15:15:54 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17674
	for ; Thu, 29 Mar 2001 15:15:34 -0800 (PST)
From: Basavaraj.Patil@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11011
	for ; Thu, 29 Mar 2001 16:15:33 -0700 (MST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TNFZg10950
	for ; Thu, 29 Mar 2001 17:15:35 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 17:15:17 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 17:15:17 -0600
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213712@daeis07nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: mankin@isi.edu
Subject: RE: [mobile-ip] QoS Work Item 
Date: Thu, 29 Mar 2001 17:15:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Allison,

Based on what I heard at tge nsis BOF and your e-mail below, do you
believe that the QoS work associated with mobility and specifically
Mobile IP can be potentially handled in a new WG if it is formed?

-Basavaraj

> -----Original Message-----
> From: ext Allison Mankin [mailto:mankin@isi.edu]
> Sent: Thursday, March 29, 2001 5:10 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] QoS Work Item 
> 
> 
> Gabriel Montenegro wrote:
> 
> > did anybody follow or try to submit requirements to the nsis bof?
> > does that seem like an appropriate venue for this?
> > 
> > http://www.ietf.org/ietf/01mar/nsis-agenda.txt
> > 
> 
> The NSIS BOF did surface a lot of requirements for QoS signaling
> in mobile IP.  
> 
> Scott and I (the ADs) are starting to formulate a possible
> working group that would address the topic.  Watch the IETF
> mailing list for an announcement of an nsis discussion mailing
> list and more progress soon.
> 
> Allison 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:23:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17426
	for ; Thu, 29 Mar 2001 18:23:24 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02287;
	Thu, 29 Mar 2001 15:23:11 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25708;
	Thu, 29 Mar 2001 15:23:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNLJIm013283
	for ; Thu, 29 Mar 2001 15:21:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TNLIKG013282
	for mobile-ip-dist; Thu, 29 Mar 2001 15:21:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNL7Im013275
	for ; Thu, 29 Mar 2001 15:21:07 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02792
	for ; Thu, 29 Mar 2001 15:21:08 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08991
	for ; Thu, 29 Mar 2001 15:21:06 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id SAA24184;
	Thu, 29 Mar 2001 18:20:55 -0500 (EST)
Posted-Date: Thu, 29 Mar 2001 18:25:36 -0500
Message-Id: <10103292325.AA15303@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
	id ; Thu, 29 Mar 01 18:25:37 EST
To: Basavaraj.Patil@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, sob@harvard.edu
Subject: Re: [mobile-ip] QoS Work Item 
In-Reply-To: Your message of Thu, 29 Mar 2001 17:15:16 -0600.
             <7B5C0390ACE7D211BC9C0008C7EABA2B03213712@daeis07nok> 
Date: Thu, 29 Mar 2001 18:25:36 -0500
From: Allison Mankin 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Basavaraj,

> Based on what I heard at tge nsis BOF and your e-mail below, do you
> believe that the QoS work associated with mobility and specifically
> Mobile IP can be potentially handled in a new WG if it is formed?

I think they should be.  The topics are coming up in Seamoby as well,
and the message from the many speakers about wireless and mobile
at the nsis bof was clear.

It will take us a while (using the mailing list-to-be) to get a
charter formulated and a working group proposed, but I expect the
Transport area will take this on.

Allison


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:39:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18250
	for ; Thu, 29 Mar 2001 18:39:28 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15144;
	Thu, 29 Mar 2001 15:39:15 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22946;
	Thu, 29 Mar 2001 15:39:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNbuIm013319
	for ; Thu, 29 Mar 2001 15:37:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TNbtIq013318
	for mobile-ip-dist; Thu, 29 Mar 2001 15:37:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNbkIm013311
	for ; Thu, 29 Mar 2001 15:37:46 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28702
	for ; Thu, 29 Mar 2001 15:37:47 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25052
	for ; Thu, 29 Mar 2001 15:37:46 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2TNbis01380
	for ; Fri, 30 Mar 2001 01:37:45 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 30 01:37:44 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 01:37:44 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD03@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f
	 or Extended mode
Date: Fri, 30 Mar 2001 01:37:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

>    you either don't want to understand what I am saying or the email program
> manages to shuffle my writing so that it arrives
> to you in the way you want to interpret it... :)
> 
	=> I don't normally respond to statements like these but 
	I'll do this one more time, so concentrate.

> The MN's HA has a binding. The first time that the MN moves under the MR/MAP it
> will use as CoA the LCoA. But hey this is the home address of the MR. 
> 
	=> NO. the MN uses the advertised MAP address as an alternate
	COA. That's what the 'T' flag is for. OK ?
	The MN knows that it moved because it receives an RA. This RA
	will "tell" the MN that it MUST use the MAP's address as an alt-COA.
	The MAP's (MR) address is the one obtained from the RA it received
	from the "fixed" AR which has a different prefix from the the MR's 
	home prefix. 

	Now if you read this part of the draft and didn't get that understanding
	tell me where the draft failed to deliver the message. But make sure
	that you say that in a respectable way if you want to get an answer.

> Needless to
> say the protocol couldn't care less about that. It is just a LCoA of the MR/MAP
> (So forget the term home address of the MR in this book..)
> 
> 
> 
> 
> Packets from the MN's HA would arrive tunneled at that LCoA (route unoptimized)
> (one tunnel)
> In that time the vehicle that was carrying that MR/MAP  went away. That means to
> me, that the MR acts as an HMIPv6 node and as a MR/MAP. So what does it do? It
> gets itself a RCoA on a fixed MAP (Hello Basic Mode). That fixed MAP will tunnel
> all packets sent to that RCoA.
> 
	=> For the second time, a fixed MAP does NOT mean basic mode. It 
	can be an Extended mode MAP.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:43:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18428
	for ; Thu, 29 Mar 2001 18:43:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14749;
	Thu, 29 Mar 2001 15:42:46 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29567;
	Thu, 29 Mar 2001 15:42:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNeYIm013342
	for ; Thu, 29 Mar 2001 15:40:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TNeYmZ013341
	for mobile-ip-dist; Thu, 29 Mar 2001 15:40:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNePIm013334
	for ; Thu, 29 Mar 2001 15:40:26 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23207
	for ; Thu, 29 Mar 2001 15:40:26 -0800 (PST)
From: zhigang.liu@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16164
	for ; Thu, 29 Mar 2001 15:40:26 -0800 (PST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2TNgSw05832
	for ; Thu, 29 Mar 2001 17:42:28 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 17:40:22 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 17:40:22 -0600
Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213BB77@daeis05nok>
To: mat@cisco.com, cabo@tzi.org
Cc: Hesham.Soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com,
        rohc@cdt.luth.se, seamoby@diameter.org, zhigang.liu@nokia.com
Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6
	 Handover
Date: Thu, 29 Mar 2001 17:40:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Mike,

Your concern is very valid and has been looked into by ROHC WG.
Just a few clarifications:

1) The compressed header size will likely be 1 byte most of the time
(>90%). Then, some first order headers (3~5 bytes). Then, few full
header. As you said, how to send the last two types of packets is
non-trivial. But it is doable. For example, very large headers can
be handled by segmentation either at link layer of by ROHC itself
(see section 5.2.5 of ROHC-09).

2) I guess you're referring to TDMA radio. My understanding is that
CDMA may have a better handle on (slight) VBR.

IMHO, ROHC has done a good job to achieve both robustness and
efficiency. Let me rephrase Carsten's question this way: if 
ROHC is not "appropriate on the air", do you have better approaches
in mind?

Br,
Zhigang

> -----Original Message-----
> From: ext Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, March 29, 2001 5:02 PM
> To: Dr. Carsten Bormann
> Cc: Michael Thomas; Hesham.Soliman@era.ericsson.se;
> mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org;
> zhigang.liu@nokia.com
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> Dr. Carsten Bormann writes:
>  > >  > (Side note: for hisorical and technical reasons, dealing with
>  > >  > realtime VBR over radio links is much a headache than 
> over wired
>  > >  > links. )
>  > >
>  > >    A-ha! That's one of the reasons I question whether
>  > >    ROHC is even appropriate on the air except in a
>  > >    very small subset of cases (usually long lived streams
>  > >    like RTP for which it was originally intended) As
>  > >    a general purpose tunnel/header compressor, I suspect 
> it is going
>  > >    to have severe thrashing with the way that radio
>  > >    resources are doled out by the AP.
>  > 
>  > I'm not sure why you are saying that (apart from the fact 
> that we haven't
>  > really done anything else but ROHC RTP yet).  How is ROHC 
> worse than
>  > uncompressed IP or 2507-compressed IP?
> 
> Carsten,
> 
> My understanding about cellular traffic channels
> -- and I would be happy to find out differently --
> is that they do not deal well with variable rate
> traffic well. This is unsurprising since they are
> heavily optimized for voice traffic which has very
> regular periodicity and payload sizes. DOCSIS
> cable is somewhat similar (with which I'm much
> more familar), and the fixed size slots cause
> variable rate coders like CRTP and ROHC much grief
> because the MAC scheduler does not have the
> ability to occassionally allow larger packets in
> real time on an unsolicited grant SID; if you
> start a session with packets every 20ms with 80
> bytes of payload, that's exactly what you get. If
> you occasionally need to send 81 bytes, you cannot
> send it on that traffic channel.
> 
> This presents a real problem for CRTP and ROHC
> when they need to send full headers or first order
> changes.  For this reason, the cable folks perform
> what they call Payload Header Suppression instead.
> Basically, it's just a first order compressor
> which is always on (sorry, if I've got your
> nomenclature mixed up). This obviously works, but
> is not as efficient. Also, I have no idea how it
> compares in robustness.
> 
> Now, it may be that the cellular MAC's and PHY's
> need some retooling in the long run in which case
> ROHC will work better, but if they work like I
> think they do, it's going to be problematic in the
> intervening time.
> 
> 		Mike
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 18:56:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19129
	for ; Thu, 29 Mar 2001 18:56:35 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19934;
	Thu, 29 Mar 2001 15:56:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09991;
	Thu, 29 Mar 2001 15:56:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNskIm013379
	for ; Thu, 29 Mar 2001 15:54:46 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2TNsjnD013378
	for mobile-ip-dist; Thu, 29 Mar 2001 15:54:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2TNsZIm013371
	for ; Thu, 29 Mar 2001 15:54:36 -0800 (PST)
Received: from lillen (d-mpk17-85-194.Eng.Sun.COM [129.146.85.194])
	by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id BAA04098;
	Fri, 30 Mar 2001 01:54:33 +0200 (MET DST)
Date: Thu, 29 Mar 2001 15:54:30 -0800 (PST)
From: Erik Nordmark 
Subject: Re: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
To: mobile-ip@sunroof.eng.sun.com
Cc: Hesham.Soliman@era.ericsson.se, zhigang.liu@nokia.com, rohc@cdt.luth.se
In-Reply-To: "Your message with ID" 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Rajeev,

> Also, I don't agree that context relocation is an overkill when few IR
> packets are needed. Consider a channel optimized for sending 24 bytes of
> voice payload and 4 bytes of header. Such CBR-like channels are common in
> cellular, I gather. Now, if you have to send a header 84 bytes long
> (IPv6/UDP/RTP + Home Address option), that is 3 voice packets. One approach
> used to handle surges in bandwidth is to puncture bits in payload. If you
> were to do that, you need to effectively live with the drop of 9 voice
> packets (24 bytes of payload + 4 bytes of header) for 3 IR headers! This is
> user-perceived disruption _due to context initialization_. 

Are you aware of any quantitative analysis of the wire cost and delay's
involved in any proposed context relocation protocol?
I assume it doesn't come for free thus a comparison is needed between
context initialization and conext relocation.
(For instance, I think some of the context relocation protocols that 
were discussed in seamoby involved a roundtrip between the mobile and 
the old access router as well as between the mobile and the new 
access router which would add significant delay before the context is
relocated.)

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:12:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19970
	for ; Thu, 29 Mar 2001 19:12:02 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09031;
	Thu, 29 Mar 2001 16:11:49 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05401;
	Thu, 29 Mar 2001 16:11:38 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U09sIm013422
	for ; Thu, 29 Mar 2001 16:09:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U09s8X013421
	for mobile-ip-dist; Thu, 29 Mar 2001 16:09:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U09jIm013414
	for ; Thu, 29 Mar 2001 16:09:45 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28792
	for ; Thu, 29 Mar 2001 16:09:46 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07513
	for ; Thu, 29 Mar 2001 16:09:41 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA15787
	for ; Thu, 29 Mar 2001 16:09:40 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2U09bc24982
	for ; Thu, 29 Mar 2001 16:09:37 -0800
X-mProtect:  Thu, 29 Mar 2001 16:09:37 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdLK0Lf7; Thu, 29 Mar 2001 16:09:13 PST
Message-ID: <3AC3CEAC.F2BA2214@cs.ucl.ac.uk>
Date: Thu, 29 Mar 2001 16:09:16 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets f or 
 Extended mode
References: <034BEFD03799D411A59F00508BDF7546013DBD03@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>

Hesham,


please don't be irritated by the comments, they are not intended to harm...only to
challenge for elaboration...and the clarity of the spec  :))


> > The MN's HA has a binding. The first time that the MN moves under the MR/MAP it
> > will use as CoA the LCoA. But hey this is the home address of the MR.
> >
>         => NO. the MN uses the advertised MAP address as an alternate
>         COA. That's what the 'T' flag is for. OK ?
>         The MN knows that it moved because it receives an RA. This RA
>         will "tell" the MN that it MUST use the MAP's address as an alt-COA.
>         The MAP's (MR) address is the one obtained from the RA it received
>         from the "fixed" AR which has a different prefix from the the MR's
>         home prefix.
>
>         Now if you read this part of the draft and didn't get that understanding
>         tell me where the draft failed to deliver the message. But make sure
>         that you say that in a respectable way if you want to get an answer.
>

This is crystal clear from the spec. But please continue your elaboration I am dying
to hear the rest of you
description...


>
> >
> > Packets from the MN's HA would arrive tunneled at that LCoA (route unoptimized)
> > (one tunnel)
> > In that time the vehicle that was carrying that MR/MAP  went away. That means to
> > me, that the MR acts as an HMIPv6 node and as a MR/MAP. So what does it do? It
> > gets itself a RCoA on a fixed MAP (Hello Basic Mode). That fixed MAP will tunnel
> > all packets sent to that RCoA.
> >

>
>         => For the second time, a fixed MAP does NOT mean basic mode. It
>         can be an Extended mode MAP.
>

Now allow me to say that the spec (v2) mentioned explicitly that the MR case is
explicitly worked through extended mode. In that case I can only assume that the
fixed MAP case is dealt by the Basic mode. If you say that the fixed map case is NOW,
NOT dealt by basic mode, I am left with no option but AGREE with Charlie on his
request that the Basic mode should really go AWAY... I cannot see any point why the
basic mode need stay there anymore. I would be grateful if you could convince me for
the opposite....

I need not emphasize further as negative point of Basic mode,  that the generation of
multiple RCoA for MN so as to sustain unique representation of the MN in the visited
domain, while you have a unique Home Addr already at hand (but you don't divulge that
to the MAP - I wonder why???) is also bound to find problems:

1) by the management of MANY RCoA for no apparent reason
2) DAD checks by the hunderds for no apparent reason



If however the Basic mode is destined for fixed MAPs then, all I am crying out loud
is that when route unoptimized packets leaving from the MN's HA (when that HA has not
received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the
mean time)

towards the MN,  AND the MR is away but the BU from the MN has not reached the MN's
HA (MR/MAP has not got yet  its own LCoA), then the MR/MAP's HA will have to
intercept the packet and tunnel it to the RCoA  (2 tunnels already). Add another
tunnel for the fixed MAP propagation of the packet and there you have it...


Theo


UCL / Mobile Systems





>
>         Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:16:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20224
	for ; Thu, 29 Mar 2001 19:16:27 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12388;
	Thu, 29 Mar 2001 16:16:10 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17595;
	Thu, 29 Mar 2001 16:16:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0ENIm013450
	for ; Thu, 29 Mar 2001 16:14:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0ENH3013449
	for mobile-ip-dist; Thu, 29 Mar 2001 16:14:23 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0EEIm013442
	for ; Thu, 29 Mar 2001 16:14:14 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06147
	for ; Thu, 29 Mar 2001 16:14:15 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04688
	for ; Thu, 29 Mar 2001 16:14:13 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2U0ECs07326
	for ; Fri, 30 Mar 2001 02:14:12 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 30 02:14:12 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 02:14:12 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] Mobile Netwoks in MIPv6
Date: Fri, 30 Mar 2001 02:14:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Raj and Phil, 

I've been meaning to suggest this since the San Diego meeting
but never got around to it. 

Thierry Ernst has brought up a valid scenario in which the MIPv6
spec does not work. This is reagrding the support of Mobile 
Networks in MIPv6. 

The scenario and solution are explained in :
http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt

This draft was presented in Pittsburgh (00) and San Diego (01).
Personally I think this is a good solution and it deserves the 
WG support. 

While we have addressed one aspect of mobile networks 
in HMIPv6. The solution only addresses certain scenarios
(As per my email discussion with Mike Thomas before the
IETF meeting ) and we don't expect every MN with MIPv6 
implementation to support HMIPv6 (of course some won't even 
support the MIPv6 MN functionality which puts a higher
demand on Thierry's draft). 

So do you think the draft or at least the problem should 
be considered as part of the charter ?
If so, you might like to consider this draft as one proposal
(a good one IMHO). 

Comments ?

Regards,
Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:17:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20293
	for ; Thu, 29 Mar 2001 19:17:32 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13476;
	Thu, 29 Mar 2001 16:17:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06797;
	Thu, 29 Mar 2001 16:17:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0F8Im013466
	for ; Thu, 29 Mar 2001 16:15:09 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0F8Hx013465
	for mobile-ip-dist; Thu, 29 Mar 2001 16:15:08 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0EqIm013455
	for ; Thu, 29 Mar 2001 16:14:53 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29791;
	Thu, 29 Mar 2001 16:14:52 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA05556;
	Thu, 29 Mar 2001 16:14:52 -0800 (PST)
Message-Id: <200103300014.QAA05556@heliopolis.Eng.Sun.COM>
Date: Thu, 29 Mar 2001 16:14:52 -0800 (PST)
From: James Kempf 
Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6  Handover
To: zhigang.liu@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org,
        zhigang.liu@nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WiAlF8F+JoX2JZd5z24fcQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Zhigang,

>IMHO, ROHC has done a good job to achieve both robustness and
>efficiency. Let me rephrase Carsten's question this way: if 
>ROHC is not "appropriate on the air", do you have better approaches
>in mind?
>

I agree that ROHC has done a good job and I don't want to imply by the
following proposal that ROHC, perhaps modified to deal with context
transfer and parameterized restart in IPv6, could not handle the
problems with IPv6. This is just something I've been thinking about
that might work if modifying ROHC is too difficult, or if the ROHC
group has other priorities, like completing compression work on IPv4
algorithms. Maybe it is completely unworkable in the end.

Assume that the Access Router and the mobile node could set up a 
unique IPv6 flow label between them. This could also be done end to
end with the corresponding node, if one wanted to preserve end to end
semantics on the flow label.

Now, the Access Router can send exactly one packet with full header.
The mobile node records the header and notes the flow label, as does
the Access Router. After that, the Access Router strips the header and
substitutes the flow label. Similarly in the uplink direction from
the mobile node to the Access Router. If the flow label were negotiated end to
end, it might take more than one packet, but the negotiation only
needs to be done once, and not every time the mobile node moves.

Since the flow label is 20 bits, the Access Router might want to hash
the flow label to one byte rather than send the full flow label across,
since the Access Router knows the mobile node that is to get the flow.

When the mobile node moves to a new Access Router, the flow label/header
context is transferred via context transfer. The mobile node maintains
the mapping. The new Access Router performs the same stripping function, even 
though the care of address has changed, as does the mobile node. 

Note that the compressor would still be needed for UDP/RTP headers.

If one doesn't want to use the flow label, a separately computed tag
(like an MPLS label) could be used, based on the source address, but
this would have to be recomputed if the corresponding node were a mobile
node and was changing its care of address. A flow label would remain
constant.

Comments?

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:25:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20789
	for ; Thu, 29 Mar 2001 19:25:35 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18808;
	Thu, 29 Mar 2001 16:25:21 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08507;
	Thu, 29 Mar 2001 16:25:05 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0NEIm013513
	for ; Thu, 29 Mar 2001 16:23:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0NEad013512
	for mobile-ip-dist; Thu, 29 Mar 2001 16:23:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0N5Im013505
	for ; Thu, 29 Mar 2001 16:23:06 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01276
	for ; Thu, 29 Mar 2001 16:23:06 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA05791
	for ; Thu, 29 Mar 2001 16:23:06 -0800 (PST)
Message-Id: <200103300023.QAA05791@heliopolis.Eng.Sun.COM>
Date: Thu, 29 Mar 2001 16:23:06 -0800 (PST)
From: James Kempf 
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mCScKhNmoI6OTTa4RUlpow==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham/All,


>So do you think the draft or at least the problem should 
>be considered as part of the charter ?
>If so, you might like to consider this draft as one proposal
>(a good one IMHO). 
>

I think MIPv6 and any hierarchical scheme needs to support mobile
networks. I also think there should be no qualifications on the
support provided, that is, it should be possible to compose an
arbitrary network behind a mobile router and have it work. I also
think this should be a working group item. If we transfer the
QoS item off the charter to the new NSIS group, then we would
have room for a new one supporting mobile networks without causing
the charter to increase in size. 

The other possibility would be to have Seamoby work on mobile networks,
but since it is an explictly mobile IP related item, it seems more
appropriate for the mobile IP group.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:32:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21086
	for ; Thu, 29 Mar 2001 19:32:51 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05525;
	Thu, 29 Mar 2001 16:32:34 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16901;
	Thu, 29 Mar 2001 16:32:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0VGIm013539
	for ; Thu, 29 Mar 2001 16:31:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0VGZB013538
	for mobile-ip-dist; Thu, 29 Mar 2001 16:31:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0V7Im013531
	for ; Thu, 29 Mar 2001 16:31:07 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21165
	for ; Thu, 29 Mar 2001 16:31:07 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12476
	for ; Thu, 29 Mar 2001 16:31:06 -0800 (PST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2U0V4I05660
	for ; Fri, 30 Mar 2001 02:31:04 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 30 02:31:04 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 02:26:50 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD05@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6
Date: Fri, 30 Mar 2001 02:31:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	James, 

> >So do you think the draft or at least the problem should 
> >be considered as part of the charter ?
> >If so, you might like to consider this draft as one proposal
> >(a good one IMHO). 
> >
> 
> I think MIPv6 and any hierarchical scheme needs to support mobile
> networks. I also think there should be no qualifications on the
> support provided, that is, it should be possible to compose an
> arbitrary network behind a mobile router and have it work. I also
> think this should be a working group item. If we transfer the
> QoS item off the charter to the new NSIS group, then we would
> have room for a new one supporting mobile networks without causing
> the charter to increase in size. 
> 
	=> Agreed. But my intention was to specifically propose 
	that draft independantly of any hierarchical scheme because 
	it is intended for the basic MIPv6 => more generic.
	Ie. it's needed for MIPv6 (base) to be complete.

> The other possibility would be to have Seamoby work on mobile networks,
> but since it is an explictly mobile IP related item, it seems more
> appropriate for the mobile IP group.
> 
	=> Definitely a MIP issue IMO. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:54:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21829
	for ; Thu, 29 Mar 2001 19:54:54 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12499;
	Thu, 29 Mar 2001 16:54:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13742;
	Thu, 29 Mar 2001 16:54:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0qdIm013581
	for ; Thu, 29 Mar 2001 16:52:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0qcY5013580
	for mobile-ip-dist; Thu, 29 Mar 2001 16:52:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0qTIm013573
	for ; Thu, 29 Mar 2001 16:52:29 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06984
	for ; Thu, 29 Mar 2001 16:52:29 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27990
	for ; Thu, 29 Mar 2001 16:52:29 -0800 (PST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2U0qSs12832
	for ; Fri, 30 Mar 2001 02:52:28 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Mar 30 02:52:28 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 02:48:13 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD06@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f
	 or Extended mode
Date: Fri, 30 Mar 2001 02:52:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
	Theo,


> > >
> > > Packets from the MN's HA would arrive tunneled at that LCoA (route unoptimized)
> > > (one tunnel)
> > > In that time the vehicle that was carrying that MR/MAP  went away. That means to
> > > me, that the MR acts as an HMIPv6 node and as a MR/MAP. So what does it do? It
> > > gets itself a RCoA on a fixed MAP (Hello Basic Mode). That fixed MAP will tunnel
> > > all packets sent to that RCoA.
> > >
> 
> >
> >         => For the second time, a fixed MAP does NOT mean basic mode. It
> >         can be an Extended mode MAP.
> >
> 
> Now allow me to say that the spec (v2) mentioned explicitly that the MR case is
> explicitly worked through extended mode. 
> 
	=> Correct.

> In that case I can only assume that the
> fixed MAP case is dealt by the Basic mode. 
> 
	=> The spec says, that Extended mode can handle the MR case and 
	the normal (fixed) case. Basic mode can only handle the fixed case. 

	So just because a MAP is fixed that doesn't mean it has to be 
	Basic mode, either one would work.

> If you say that the fixed map case is NOW,
> NOT dealt by basic mode, 
> 
	=> Did I say that ??? I said both modes can handle it.

> I am left with no option but AGREE with Charlie on his
> request that the Basic mode should really go AWAY... I cannot see any point why the
> basic mode need stay there anymore. I would be grateful if you could convince me for
> the opposite....
> 
	=> I can try. BTW there is a coparison between the two modes 
	in the draft. 
	Anyway, Basic mode provides some features that Extended mode
	doesn't. For example location privacy is one of the major advantages. 

	Also Basic mode does not require any modification to the HA. 
	Extended mode does. This is needed to enable forwarding of 
	packets addressed to the MN's Site local home address. 

	In addition if we work out a redundancy mechnism for MAPs
	or HA's then it would be much easier to design it for 
	Basic mode.

	So there are pros and cons for each one. Since the interface
	(MAP option and BU) to the MN is very similar, we thought 
	it would be a good idea to have both. 
	Also people on this list and others expressed interest in 
	having Basic mode for location privacy to hide the 
	operator's addresses (in outgoing packets). 

> I need not emphasize further as negative point of Basic mode,  that the generation of
> multiple RCoA for MN so as to sustain unique representation of the MN in the visited
> domain, while you have a unique Home Addr already at hand (but you don't divulge that
> to the MAP - I wonder why???) is also bound to find problems:
> 
> 1) by the management of MANY RCoA for no apparent reason
> 
	=> Where does MANY come from ? Only one is needed.
	or does MANY = MANY MNs ? If so how is it different 
	in the HA case.

> 2) DAD checks by the hunderds for no apparent reason
> 
	=> hundreds ? where does a hundred come from ?
	You mean hundreds of MNs ? Actually there 
	maybe hundreds of thousands ! But the same goes 
	for the HA. 

> If however the Basic mode is destined for fixed MAPs then, all I am crying out loud
> is that when route unoptimized packets leaving from the MN's HA (when that HA has not
> received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the
> mean time) 
> 
	=> Let me get this right. You're saying the MN's HA already has a binding 
	for the MN. This binding was based on the MN's previous location (before
	it appeared on the MR's subnet) Correct ?

	If the MN doesn't / can't send another BU to its HA because it doesn't 
	have the MR/MAP's address or because the MR disappeared (ie. no 
	connectivity) then packets from its HA will be delivered to the old 
	address, ie. lost. 

> towards the MN,  AND the MR is away but the BU from the MN has not reached the MN's> 
> HA (MR/MAP has not got yet  its own LCoA), then the MR/MAP's HA will have to> 
> intercept the packet and tunnel it to the RCoA
> 
	=> How does the MR's HA do that ? How can it even receive the 
	MN's packets ?
	If the MR's HA is the same as the MN's HA then the MN isn't
	 reachable and it doesn't even know that it
	moved because it is still receiving its Home RA. 

	If the MN's HA is different from the MR's HA, then the packets 
	will never be tunnelled or even received by the MR's HA. 
	This is the problem identified by Thierry's draft. This is 
	a problem in MIPv6 but you seem to assume that it's 
	solved and that the MR's HA will just tunnel packets
	for the MR's entire subnet.
	Have you read Thierry's draft ? If not then reading it 
	would help.

	Packets from the CN to the MN will be tunnelled by the MN's 
	HA to the CoA in the Binding Cache. If there is no entry
	there is no tunnelling. If there is an entry that is no longer
	valid (because the MN moved) the HA will comtinue tunnelling
	to that CoA in the Binding Cache regardless, until it's 
	given a new CoA. I really can't see how the scenario you're
	describing is possible.

	Hesham
	


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 19:59:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22047
	for ; Thu, 29 Mar 2001 19:59:06 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10613;
	Thu, 29 Mar 2001 16:58:54 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26265;
	Thu, 29 Mar 2001 16:58:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0viIm013610
	for ; Thu, 29 Mar 2001 16:57:44 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U0vhZZ013609
	for mobile-ip-dist; Thu, 29 Mar 2001 16:57:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U0vWIm013602
	for ; Thu, 29 Mar 2001 16:57:33 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14288
	for ; Thu, 29 Mar 2001 16:57:33 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02242
	for ; Thu, 29 Mar 2001 17:57:31 -0700 (MST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2U0xXw07590
	for ; Thu, 29 Mar 2001 18:59:33 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 18:57:29 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 18:57:29 -0600
Message-ID: 
To: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com
Cc: Hesham.Soliman@era.ericsson.se, zhigang.liu@nokia.com, rohc@cdt.luth.se
Subject: RE: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IP
	v6 Handover
Date: Thu, 29 Mar 2001 18:57:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello Erik,

> 
> 
> Rajeev,
> 
> > Also, I don't agree that context relocation is an overkill 
> when few IR
> > packets are needed. Consider a channel optimized for 
> sending 24 bytes of
> > voice payload and 4 bytes of header. Such CBR-like channels 
> are common in
> > cellular, I gather. Now, if you have to send a header 84 bytes long
> > (IPv6/UDP/RTP + Home Address option), that is 3 voice 
> packets. One approach
> > used to handle surges in bandwidth is to puncture bits in 
> payload. If you
> > were to do that, you need to effectively live with the drop 
> of 9 voice
> > packets (24 bytes of payload + 4 bytes of header) for 3 IR 
> headers! This is
> > user-perceived disruption _due to context initialization_. 
> 
> Are you aware of any quantitative analysis of the wire cost 
> and delay's
> involved in any proposed context relocation protocol?


I am not aware of proposals on context relocation protocol other than our
own! See 
http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt

I can certainly say few things about how I see the cost with the above draft
in mind. We allow using our context transfer options (IPv6 destination
options and ICMP options) with MIPv6 fast handover signaling to accomplish
"fast context transfers". 

1. The MN gets a trigger from old AR to undergo handover (e.g., proxy Router
Advertisement in fast-v6 draft). The MN sends a message back to old AR prior
to relinquishing its link with old AR. This message could be the fast
Binding Update. In this message, it includes a destination option containing
context relocation request. The old AR sends context to the new AR (e.g., in
the HI message). 
Note that until the fast BU goes out, the MN is using the context present at
old AR.

2. MN establishes a new link with new AR. Here is a L2 establishment delay.
MN does Neighbor Discovery, and starts using the new IP address according to
the fast handover specification. In our draft, the MN sends a Seamless
Handover Initiate (SHIN) message with destination option along with a normal
Binding Update as encapsulation. This SHIN option, which can also be sent
along with fast handover ND message to expedite the process, indicates to
the new AR that the MN wishes to make use of its context. When the new AR
processes the SHIN option, it relates it to the context transferred during
fast handover signaling.  

3. The application packet streams can use compression assuming that context
is present at the new AR. Here, some extensions are needed to take into
account the new IP address. 
There is a companion header compression-specific draft that explains how the
context transfer framework draft is used for effecting header compression
context relocation. See

http://search.ietf.org/internet-drafts/draft-koodli-seamoby-hc-relocate-00.t
xt


This is a somewhat simplified description of what we propose in the drafts.
In summary, the cost of our proposal, in terms of delay over the air
interface, is no worse than what you incur with fast handover signaling.
Indeed, some additional bits are sent to effect context transfers, e.g., the
MN requesting old AR (in the fast BU message) to send contexts. It is
possible that this explicit request can be assumed in network-controlled
handovers (for e.g.), thus avoiding those bits to be sent.  

Just for completeness, I should also mention that our drafts also specify
how context transfer works with reactive signaling, e.g., with basic MIPv6.

> I assume it doesn't come for free thus a comparison is needed between
> context initialization and conext relocation.

My explanation above is somewhat coarse. I agree that the comparison would
be good first step towards specifying context relocation. 

> (For instance, I think some of the context relocation protocols that 
> were discussed in seamoby involved a roundtrip between the mobile and 
> the old access router as well as between the mobile and the new 
> access router which would add significant delay before the context is
> relocated.)

I can't speak for other proposals (BTW, could you point me to those
proposals ?). As far as our proposal is concerned, I don't perceive
additional overheads you mention, since, we piggy-back on fast handover
signals. I would be happy to address any specific questions/comments you may
have. 


Regards,

-Rajeev


> 
>   Erik
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 20:23:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23203
	for ; Thu, 29 Mar 2001 20:23:48 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24977;
	Thu, 29 Mar 2001 17:23:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00123;
	Thu, 29 Mar 2001 17:23:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U1MGIm013670
	for ; Thu, 29 Mar 2001 17:22:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U1MGVo013669
	for mobile-ip-dist; Thu, 29 Mar 2001 17:22:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U1M6Im013662
	for ; Thu, 29 Mar 2001 17:22:07 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29987
	for ; Thu, 29 Mar 2001 17:22:07 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24260
	for ; Thu, 29 Mar 2001 17:22:06 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA22517;
	Thu, 29 Mar 2001 17:21:47 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2U1LjT05305;
	Thu, 29 Mar 2001 17:21:45 -0800
X-mProtect:  Thu, 29 Mar 2001 17:21:45 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdpiGLCd; Thu, 29 Mar 2001 17:21:23 PST
Message-ID: <3AC3DF76.E6DA14D4@iprg.nokia.com>
Date: Thu, 29 Mar 2001 17:20:54 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dr. Carsten Bormann" 
CC: rajeev.koodli@nokia.com, Hesham.Soliman@era.ericsson.se,
        zhigang.liu@nokia.com, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        seamoby@diameter.org
Subject: [mobile-ip] Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 
 Handover
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Carsten,


"Dr. Carsten Bormann" wrote:

> > Well, I think header compression context relocation is doable in
> > seamoby. We
> > need some help from rohc in defining what a context is, say e.g.,
> > IPv6/UDP/RTP/voice-G.723.1.
>
> Rajeev,
>
> while this is only a rough overview of the information set, you might want
> to start with section 6.5 of the ROHC RTP document.  I tend to believe that
> for most applications, just transferring the static chain will be fine,
> though; this is resilient to race conditions and can simply use the data
> format already defined in section 5.7.7.
>

Ok. I agree this is a good start.

Regards,

-Rajeev



>
> One thing that needs to be defined as well is the signaling between the old
> compressor and the new decompressor (and v.v.) so they know context transfer
> is in use and contexts have been successfully transferred.  This may be
> implicit in the handover or explicitly signalled *).  This signalling may
> also be a good place to fix the apparent deficiency in ROHC that there is no
> good way to update an address in the outermost IP header (needed for Mobile
> IPv6).

> *) ROHCers: maybe we need to reserve some bit combinations for ROHC-over-X
> signalling...
>
> Gruesse, Carsten



From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 20:37:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24027
	for ; Thu, 29 Mar 2001 20:37:45 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05153;
	Thu, 29 Mar 2001 17:37:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02424;
	Thu, 29 Mar 2001 17:37:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U1aEIm013705
	for ; Thu, 29 Mar 2001 17:36:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U1aE7G013704
	for mobile-ip-dist; Thu, 29 Mar 2001 17:36:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U1a5Im013697
	for ; Thu, 29 Mar 2001 17:36:05 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27329
	for ; Thu, 29 Mar 2001 17:36:06 -0800 (PST)
From: zhigang.liu@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03955
	for ; Thu, 29 Mar 2001 17:36:05 -0800 (PST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2U1a7g19104
	for ; Thu, 29 Mar 2001 19:36:07 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Thu, 29 Mar 2001 19:36:04 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 29 Mar 2001 19:36:04 -0600
Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok>
To: kempf@heliopolis.eng.sun.com
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org
Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6
	  Handover
Date: Thu, 29 Mar 2001 19:36:03 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi James,

Using the flow label (to identify a context) is certainly a good 
idea. I'm wondering if the ROHC CID (may need re-mapping during 
handover) can achieve the same goal. The former hinges on that the 
flow label is unique between the Access Router (AR) and the mobile 
node (MN) and remains constant when the MN attaches to a new AR 
(need re-negotiation if clashes with flow from other IP address?). 
The latter requires the mapping of old COA and the new one (details
unclear).

Somehow, I feel further thinking might be needed. On the other hand, 
they're not in conflict since the ROHC CID can be viewed as the 
result of hash function of the flow label. In addition, it could be 
a zero-bye CID (just for one flow) under the ROHC framework.

Br,
Zhigang

> -----Original Message-----
> From: ext James Kempf [mailto:kempf@heliopolis.Eng.Sun.COM]
> Sent: Thursday, March 29, 2001 6:15 PM
> To: zhigang.liu@nokia.com
> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> seamoby@diameter.org; zhigang.liu@nokia.com
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> Zhigang,
> 
> >IMHO, ROHC has done a good job to achieve both robustness and
> >efficiency. Let me rephrase Carsten's question this way: if 
> >ROHC is not "appropriate on the air", do you have better approaches
> >in mind?
> >
> 
> I agree that ROHC has done a good job and I don't want to imply by the
> following proposal that ROHC, perhaps modified to deal with context
> transfer and parameterized restart in IPv6, could not handle the
> problems with IPv6. This is just something I've been thinking about
> that might work if modifying ROHC is too difficult, or if the ROHC
> group has other priorities, like completing compression work on IPv4
> algorithms. Maybe it is completely unworkable in the end.
> 
> Assume that the Access Router and the mobile node could set up a 
> unique IPv6 flow label between them. This could also be done end to
> end with the corresponding node, if one wanted to preserve end to end
> semantics on the flow label.
> 
> Now, the Access Router can send exactly one packet with full header.
> The mobile node records the header and notes the flow label, as does
> the Access Router. After that, the Access Router strips the header and
> substitutes the flow label. Similarly in the uplink direction from
> the mobile node to the Access Router. If the flow label were 
> negotiated end to
> end, it might take more than one packet, but the negotiation only
> needs to be done once, and not every time the mobile node moves.
> 
> Since the flow label is 20 bits, the Access Router might want to hash
> the flow label to one byte rather than send the full flow 
> label across,
> since the Access Router knows the mobile node that is to get the flow.
> 
> When the mobile node moves to a new Access Router, the flow 
> label/header
> context is transferred via context transfer. The mobile node maintains
> the mapping. The new Access Router performs the same 
> stripping function, even 
> though the care of address has changed, as does the mobile node. 
> 
> Note that the compressor would still be needed for UDP/RTP headers.
> 
> If one doesn't want to use the flow label, a separately computed tag
> (like an MPLS label) could be used, based on the source address, but
> this would have to be recomputed if the corresponding node 
> were a mobile
> node and was changing its care of address. A flow label would remain
> constant.
> 
> Comments?
> 
> 		jak
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Mar 29 21:17:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26316
	for ; Thu, 29 Mar 2001 21:17:46 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05233;
	Thu, 29 Mar 2001 18:17:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08130;
	Thu, 29 Mar 2001 18:17:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U2EGIm013760
	for ; Thu, 29 Mar 2001 18:14:18 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U2EF7e013759
	for mobile-ip-dist; Thu, 29 Mar 2001 18:14:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U2DkIm013752
	for ; Thu, 29 Mar 2001 18:13:47 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19485
	for ; Thu, 29 Mar 2001 18:13:46 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07536
	for ; Thu, 29 Mar 2001 19:13:45 -0700 (MST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA26495
	for ; Thu, 29 Mar 2001 18:13:45 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2U2Dfu16031
	for ; Thu, 29 Mar 2001 18:13:41 -0800
X-mProtect:  Thu, 29 Mar 2001 18:13:41 -0800 Nokia Silicon Valley Messaging Protection
Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdBht7V1; Thu, 29 Mar 2001 18:13:23 PST
Message-ID: <3AC3EBC6.A8B9C32C@Kniveton.com>
Date: Thu, 29 Mar 2001 18:13:26 -0800
From: "T.J. Kniveton" 
Organization: NOKIA Research
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Hesham Soliman (ERA)" wrote:
> 
> Hello Raj and Phil,

Since you posted this to Mobile-IP list, I'll take the liberty to assume
you want responses from others than Raj or Phil.

> 
> I've been meaning to suggest this since the San Diego meeting
> but never got around to it.
> 
> Thierry Ernst has brought up a valid scenario in which the MIPv6
> spec does not work. This is reagrding the support of Mobile
> Networks in MIPv6.
> 
> The scenario and solution are explained in :
> http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt


I don't see exactly why this scenario is a problem. As long as the
network is in the routing tables of the home link's routers as having a
next hop of the MR, there's no problem.

This draft states in section 3.2.4:
      When the packet gets to the home
      network, BR checks its routing table to reach SN1. BR has a route
      to the mobile network; MR's home address is the next hop towards
      SN1. . . The HA intercepts
      the packet, but does not have a route to the mobile network.

Why would the BR have a route to the mobile node, and the HA wouldn't?
They are on the same link, so it seems like the HA is not picking up the
same routing info as the BR. This would be a configuration issue.

> So do you think the draft or at least the problem should
> be considered as part of the charter ?
> If so, you might like to consider this draft as one proposal
> (a good one IMHO).

Can you please give an example of how a network which is properly
configured would fail in this circumstance? It seems like it would
already be handled by whatever routing protocol is used, and the base
Mobile IPv6 spec.

-- 
T.J. Kniveton
NOKIA Research


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 03:00:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17025
	for ; Fri, 30 Mar 2001 03:00:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22334;
	Thu, 29 Mar 2001 23:59:38 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28477;
	Thu, 29 Mar 2001 23:59:34 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U7wKIm014098
	for ; Thu, 29 Mar 2001 23:58:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U7wKEL014097
	for mobile-ip-dist; Thu, 29 Mar 2001 23:58:20 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U7wBIm014090
	for ; Thu, 29 Mar 2001 23:58:11 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29793
	for ; Thu, 29 Mar 2001 23:58:12 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15204
	for ; Fri, 30 Mar 2001 00:58:11 -0700 (MST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id JAA12102;
	Fri, 30 Mar 2001 09:58:09 +0200 (MET DST)
Message-ID: <3AC43C55.DF840666@inrialpes.fr>
Date: Fri, 30 Mar 2001 09:57:09 +0200
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: zhigang.liu@nokia.com, rohc@cdt.luth.se
Subject: Re: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 
 Handover
References: <200103291958.LAA28525@heliopolis.Eng.Sun.COM>
Content-Type: multipart/alternative;
 boundary="------------1C6823158E87C973E62B3C6A"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------1C6823158E87C973E62B3C6A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James Kempf wrote:

>  We don't have to be involved in the
> details, but we at least have to know:
>
>         1) That either header compression can restart fast
>         or with context transfer and updating of the context using
>         the new CoA.
>

just a quick comment: in HMIPv6 basic mode, the MN uses the RCoA as source
address ...this address
only changes when the MN moves from one MAP to another...

HMIPv6 might actually make things easier than MIPv6 concerning header
compression....

regards,

Claude.


>

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------1C6823158E87C973E62B3C6A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



James Kempf wrote:

 We don't have to be involved in the

details, but we at least have to know:

        1) That either header compression
can restart fast

        or with context transfer
and updating of the context using

        the new CoA.

 

just a quick comment: in HMIPv6 basic mode, the MN uses the RCoA
as source address ...this address

only changes when the MN moves from one MAP to another...

HMIPv6 might actually make things easier than MIPv6 concerning header
compression....

regards,

Claude.

 

 



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------1C6823158E87C973E62B3C6A--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 04:13:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26728
	for ; Fri, 30 Mar 2001 04:13:09 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08113;
	Fri, 30 Mar 2001 01:10:56 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06527;
	Fri, 30 Mar 2001 01:10:51 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U97lIm014155
	for ; Fri, 30 Mar 2001 01:07:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2U97l24014154
	for mobile-ip-dist; Fri, 30 Mar 2001 01:07:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2U97cIm014147
	for ; Fri, 30 Mar 2001 01:07:38 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13329
	for ; Fri, 30 Mar 2001 01:07:37 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16670
	for ; Fri, 30 Mar 2001 02:07:36 -0700 (MST)
Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id LAA14216
	for ; Fri, 30 Mar 2001 11:07:35 +0200 (MET DST)
Message-ID: <3AC44CD7.FDCAD5B2@inrialpes.fr>
Date: Fri, 30 Mar 2001 11:07:35 +0200
From: Thierry Ernst 
Organization: INRIA Rhone-Alpes
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <200103300023.QAA05791@heliopolis.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi all,

First, thanks to Hesham.

> I think MIPv6 and any hierarchical scheme needs to support mobile
> networks. I also think there should be no qualifications on the
> support provided, that is, it should be possible to compose an
> arbitrary network behind a mobile router and have it work. I also
> think this should be a working group item. If we transfer the
> QoS item off the charter to the new NSIS group, then we would
> have room for a new one supporting mobile networks without causing
> the charter to increase in size.

Mobile IPv6 is meant to support mobile nodes, and a mobile node could be
a host or a router.  As long as you are dealing with mobile routers, you
also have to deal with the mobile network behind the mobile router, and
it is not limited to a sole subnet.   As a matter of fact, it is already
explicitly stated in the Mobile IP WG charter that the group should
address mobile host AND ROUTERS:   "The Mobile IP Working Group has
developed routing support to permit IP nodes (hosts and routers) using
either IPv4 or IPv6 (...)".   

> The other possibility would be to have Seamoby work on mobile networks,
> but since it is an explictly mobile IP related item, it seems more
> appropriate for the mobile IP group.

IMHO, It should definitely be discussed in the Mobile IP WG, and not
anywhere else.    At the present time, MIPv6 does only support the
moving node, not what is behind.     The reason is explained in the
draft.  If it is not sufficiently well explained, please speak up.


Thanks,
Thierry.


--
* mailto:Thierry.Ernst@inrialpes.fr  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 05:01:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01488
	for ; Fri, 30 Mar 2001 05:01:53 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10394;
	Fri, 30 Mar 2001 02:01:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23070;
	Fri, 30 Mar 2001 02:01:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UA0LIm014253
	for ; Fri, 30 Mar 2001 02:00:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UA0LXQ014252
	for mobile-ip-dist; Fri, 30 Mar 2001 02:00:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UA0CIm014245
	for ; Fri, 30 Mar 2001 02:00:12 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22956
	for ; Fri, 30 Mar 2001 02:00:11 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09293
	for ; Fri, 30 Mar 2001 02:00:06 -0800 (PST)
Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id MAA15939
	for ; Fri, 30 Mar 2001 12:00:01 +0200 (MET DST)
Message-ID: <3AC45921.270FFB2F@inrialpes.fr>
Date: Fri, 30 Mar 2001 12:00:01 +0200
From: Thierry Ernst 
Organization: INRIA Rhone-Alpes
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se> <3AC3EBC6.A8B9C32C@Kniveton.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

> I don't see exactly why this scenario is a problem. As long as the
> network is in the routing tables of the home link's routers as having a
> next hop of the MR, there's no problem.

Yes there is a problem because the prefix of the mobile network is not
the same as the prefix of the MR's home address.

> This draft states in section 3.2.4:
>       When the packet gets to the home
>       network, BR checks its routing table to reach SN1. BR has a route
>       to the mobile network; MR's home address is the next hop towards
>       SN1. . . The HA intercepts
>       the packet, but does not have a route to the mobile network.
> 
> Why would the BR have a route to the mobile node, and the HA wouldn't?

Both BR and HA have one, and this route is via the MR (i.e. via
int0).    I used the BR to point out the problem.  

Then, the route recorded in the routing table says "route packets which
destination is the mobile network prefix to the MR".   Unfortunately, MR
has moved, what do you do then ?  HA does only know how to encapsulate a
packet which destination = MR, not a packet which next hop = MR.    We
have done the experiment on FreeBSD, has it is described in the draft.

 ---          ---
 |BR|          |HA|
 ---          ---
   |               |
   |               |
 _____________ home link  P1::/64
          |
          | int0 P1::/64
          |
        ---
        |MR|
        ---
         |
         | int1 P2::/64
         |
   __________________  link internal to the home network
      |                     | 
      | int3  P2::64    |  int4 P2::/64
      |                     |
    ---               ---
   | H  |               | R  |
    ---               - --

o The mobile network is attached to the Internet via the mobile router
MR

o MR has (at least) 2 interfaces:
	- int0 points to the home link, and has prefix 
	- int1 points to a link internal to the mobile network and has prefix

	
o All addresses in the mobile network have the same prefix P = the
mobile network prefix
	- length P = Lp  /   length P1 = Lp1 / length P2 = Lp2
	- Lp  < Lp2.
	- Lp first bits of P2 = P
	- Lp first bits of P1 <> P
	- Lp fitst bits of P1 <> Lp first bits of P2

o Both BR and HA have an entry in their routing table corresponding to
the mobile network prefix : this entry says that packets to the
mobile network should be routed to MR via int0.

o HA has received a binding update which says "packets sent to
int0::/128  should be encapsulated".  Then, HA pretends to be int0.  It
gets the packets directed to P2 and those directed to int0.
	- Once HA gets a packet to MR (int0), no problem, encapsulation to MR's
COA.
	- If packet has a destination in the mobile network with prefix P2, HA
won't know what to do with it, because the next hop to P2 is the HA
itself.  It does not know how to handle it because it has only been
instructed to redirected packet sent a 128 bits address, and not to
prefix P.

> They are on the same link, so it seems like the HA is not picking up the
> same routing info as the BR. This would be a configuration issue.

You may configure your routing tables in a way that it works, but this
is more like a hack.  MIPv6 does not says how to re-route a packet wich
is not sent to the home address.

The problem comes from the information carried in the Binding update
which says "it destination = int0::/128 bits, encapsulate packet to the
MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
work, but you need to specify it in the spec.

> Can you please give an example of how a network which is properly
> configured would fail in this circumstance? It seems like it would
> already be handled by whatever routing protocol is used, and the base
> Mobile IPv6 spec.

There is nothing to do with the routing protocol unless you want to
update the routing tables of all nodes in the AS.    My draft proposes
to use base Mobile IPv6, but we need an extension to specify to the HA
that it should also encapsulate packets intended to nodes in the mobile
network with prefix P2.


Is this clearer ?
Thierry

--
* mailto:Thierry.Ernst@inrialpes.fr  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 07:36:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11271
	for ; Fri, 30 Mar 2001 07:36:39 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02347;
	Fri, 30 Mar 2001 04:36:13 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03584;
	Fri, 30 Mar 2001 04:36:08 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UCZ1Im014451
	for ; Fri, 30 Mar 2001 04:35:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UCZ1kx014450
	for mobile-ip-dist; Fri, 30 Mar 2001 04:35:01 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UCYpIm014440
	for ; Fri, 30 Mar 2001 04:34:51 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28331
	for ; Fri, 30 Mar 2001 04:34:50 -0800 (PST)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01267
	for ; Fri, 30 Mar 2001 05:34:48 -0700 (MST)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA05748
	for ; Fri, 30 Mar 2001 14:34:46 +0200 (MET DST)
Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA03653
	for ; Fri, 30 Mar 2001 14:34:16 +0200 (MET DST)
Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 14:34:11 +0200
Message-ID: 
From: Erdmann Antonius  ICM N MC MI E 3 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] CNs in/near MN's home subnetwork
Date: Fri, 30 Mar 2001 14:34:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,

I'm a bit confused about the following problem(s):

Here the possible configuration:

Rx is a router


    CN1                 R                R                 CN2
     |                  |                |                  |
-----+--------+---------+--            --+------+-----------+------
              |                                 |
             R1 (HA1)                          R2 (not HA)
              |                                 |
    --+-------+---------------+-----------------+-------+---
      |                       |                         |
     CN3                     (MN)                       R
                   (home network of MN,
                    but MN is away from home)


1. CN1 has no problems with MN being away from home, because R1-HA1 _can_
   intercept any packets to MN and tunnel them to the CoA

2. CN2 has problemes, because AFAIK R2 will send
   a message "host unreachable" to CN2

3. CN3 has problems, because CN3 himself will find out (by neighbor
discovery)
   that MN is "unreachable". No router is involved in the traffic CN3 <->
MN,
   when MN is at home.


Consequences for a network allowing mobility for its nodes:

- must every leaf-router be a HA to be able to intercept all packets
destined to any MN
  coming from any CN ???

  and/or

- must a MN (being away from home) send BUs to all HAs on its home link ???

  and/or

- must every HA listen for all packets for all MNs that have an entry in the
"binding cache"


What's wrong with my understanding ???

Toni


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 08:12:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13352
	for ; Fri, 30 Mar 2001 08:12:32 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23828;
	Fri, 30 Mar 2001 05:12:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00394;
	Fri, 30 Mar 2001 05:12:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UDArIm014517
	for ; Fri, 30 Mar 2001 05:10:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UDAqeC014516
	for mobile-ip-dist; Fri, 30 Mar 2001 05:10:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UDAiIm014509
	for ; Fri, 30 Mar 2001 05:10:44 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00299
	for ; Fri, 30 Mar 2001 05:10:43 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17127
	for ; Fri, 30 Mar 2001 05:10:41 -0800 (PST)
Received: from darmstadt.gmd.de (pc-morion [141.12.35.155])
	by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA07054;
	Fri, 30 Mar 2001 15:10:40 +0200 (MET DST)
Message-ID: <3AC485DB.C3A42234@darmstadt.gmd.de>
Date: Fri, 30 Mar 2001 15:10:51 +0200
From: Wolfgang Schoenfeld 
Organization: GMD
X-Mailer: Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language: en,de
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] CNs in/near MN's home subnetwork
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Toni,

it seems to me that your understanding of "intercept" is incorrect.
In the context of MIP, it is not meant topologically
(some router on the packet's path grabs it ...).
Instead, the packet is intercepted
while it is sent on the final link:
HA intercepts packets addressed to MN
by binding its MAC address to the MN's IP address
(very similar to proxy ARP).

This should answer all your questions...
(I remember I had the same problem when working through MIP.)

Wolfgang

Erdmann Antonius ICM N MC MI E 3 schrieb:
> 
> Hi,
> 
> I'm a bit confused about the following problem(s):
> 
> Here the possible configuration:
> 
> Rx is a router
> 
>     CN1                 R                R                 CN2
>      |                  |                |                  |
> -----+--------+---------+--            --+------+-----------+------
>               |                                 |
>              R1 (HA1)                          R2 (not HA)
>               |                                 |
>     --+-------+---------------+-----------------+-------+---
>       |                       |                         |
>      CN3                     (MN)                       R
>                    (home network of MN,
>                     but MN is away from home)
> 
> 1. CN1 has no problems with MN being away from home, because R1-HA1 _can_
>    intercept any packets to MN and tunnel them to the CoA
> 
> 2. CN2 has problemes, because AFAIK R2 will send
>    a message "host unreachable" to CN2
> 
> 3. CN3 has problems, because CN3 himself will find out (by neighbor
> discovery)
>    that MN is "unreachable". No router is involved in the traffic CN3 <->
> MN,
>    when MN is at home.
> 
> Consequences for a network allowing mobility for its nodes:
> 
> - must every leaf-router be a HA to be able to intercept all packets
> destined to any MN
>   coming from any CN ???
> 
>   and/or
> 
> - must a MN (being away from home) send BUs to all HAs on its home link ???
> 
>   and/or
> 
> - must every HA listen for all packets for all MNs that have an entry in the
> "binding cache"
> 
> What's wrong with my understanding ???
> 
> Toni


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 08:17:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13586
	for ; Fri, 30 Mar 2001 08:17:47 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27117;
	Fri, 30 Mar 2001 05:17:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22443;
	Fri, 30 Mar 2001 05:17:21 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UDGNIm014546
	for ; Fri, 30 Mar 2001 05:16:23 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UDGMYI014545
	for mobile-ip-dist; Fri, 30 Mar 2001 05:16:22 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UDGEIm014538
	for ; Fri, 30 Mar 2001 05:16:14 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00866
	for ; Fri, 30 Mar 2001 05:16:12 -0800 (PST)
Received: from mailhost.tbit.dk (mailhostnew.tbit.dk [194.182.135.150])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13877
	for ; Fri, 30 Mar 2001 05:16:11 -0800 (PST)
Received: from ted.ericsson.dk (IDENT:root@mailhost.tbit.dk [194.182.135.150])
	by mailhost.tbit.dk (8.9.3/8.9.3) with ESMTP id OAA09298;
	Fri, 30 Mar 2001 14:16:07 +0200
Message-ID: <3AC48719.1DB272DD@ted.ericsson.dk>
Date: Fri, 30 Mar 2001 15:16:09 +0200
From: Peter Grimstrup 
Organization: Ericsson Telebit A/S
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.15-4mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] CNs in/near MN's home subnetwork
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Toni,

Althoug I'm fairly new in this business, I'll try to solve your problem(s) - If
I'm wrong, I'm sure somebody will lead me back on the track.

When the MN sends a BU to R1 asking R1 to be HA, R1 will act as a proxy for MN on
the home network of MN. This means, that other nodes through neighbor-discovery
mechanisms will learn to use the MAC address of R1 as target for traffic to MN.

ad. 2. Thus CN sends the packet destined for MN to R2, R2 learns/has learnt that
MN's MAC now is MAC of R1 and sends packet to R1. R1 tunnels packet to MN.

ad 3. Same mechanism.

/Peter
---------------------------------------
Erdmann Antonius ICM N MC MI E 3 wrote:
> 
> Hi,
> 
> I'm a bit confused about the following problem(s):
> 
> Here the possible configuration:
> 
> Rx is a router
> 
>     CN1                 R                R                 CN2
>      |                  |                |                  |
> -----+--------+---------+--            --+------+-----------+------
>               |                                 |
>              R1 (HA1)                          R2 (not HA)
>               |                                 |
>     --+-------+---------------+-----------------+-------+---
>       |                       |                         |
>      CN3                     (MN)                       R
>                    (home network of MN,
>                     but MN is away from home)
> 
> 1. CN1 has no problems with MN being away from home, because R1-HA1 _can_
>    intercept any packets to MN and tunnel them to the CoA
> 
> 2. CN2 has problemes, because AFAIK R2 will send
>    a message "host unreachable" to CN2
> 
> 3. CN3 has problems, because CN3 himself will find out (by neighbor
> discovery)
>    that MN is "unreachable". No router is involved in the traffic CN3 <->
> MN,
>    when MN is at home.
> 
> Consequences for a network allowing mobility for its nodes:
> 
> - must every leaf-router be a HA to be able to intercept all packets
> destined to any MN
>   coming from any CN ???
> 
>   and/or
> 
> - must a MN (being away from home) send BUs to all HAs on its home link ???
> 
>   and/or
> 
> - must every HA listen for all packets for all MNs that have an entry in the
> "binding cache"
> 
> What's wrong with my understanding ???
> 
> Toni

-- 
Peter Grimstrup          Systems Developer
Ericsson Telebit A/S     tel: +45 89 38 52 75
Skanderborgvej 232       fax: +45 89 38 51 01
DK 8260 Viby J, Denmark  e-mail: peter.grimstrup@ted.ericsson.dk


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 09:15:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16442
	for ; Fri, 30 Mar 2001 09:15:10 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07167;
	Fri, 30 Mar 2001 06:14:53 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11400;
	Fri, 30 Mar 2001 06:14:48 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEDdIm014612
	for ; Fri, 30 Mar 2001 06:13:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UEDcSc014611
	for mobile-ip-dist; Fri, 30 Mar 2001 06:13:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEDUIm014604
	for ; Fri, 30 Mar 2001 06:13:30 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11306
	for ; Fri, 30 Mar 2001 06:13:30 -0800 (PST)
Received: from hotmail.com (f302.law7.hotmail.com [216.33.236.180])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08465
	for ; Fri, 30 Mar 2001 06:13:30 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Mar 2001 06:13:30 -0800
Received: from 206.98.219.240 by lw7fd.law7.hotmail.msn.com with HTTP;	Fri, 30 Mar 2001 14:13:30 GMT
X-Originating-IP: [206.98.219.240]
From: "Hemant Chaskar" 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
Date: Fri, 30 Mar 2001 14:13:30 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 30 Mar 2001 14:13:30.0284 (UTC) FILETIME=[98ACF6C0:01C0B923]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Yes we did intimate some of these requirements in NSIS BOF at IETF 50 (we 
had only 3 minutes though :-(.

>From: gabriel montenegro 
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: mobile-ip@sunroof.eng.sun.com
>Subject: Re: [mobile-ip] QoS Work Item
>Date: Fri, 30 Mar 2001 00:31:30 +0200
>
>Hemant Chaskar wrote:
>
> > 8. What other working groups may find this item within their scope?
> > Definitely not MPLS, DiffServ or IntServ as they would not care how the
> > information used by them arrives at a router. RSVP WG studies RSVP by 
>its
> > very name. However, RSVP, at least as it exists today, is not suitable 
>to be
> > used with Mobile IP. And also, its not only a small tweak to it that 
>would
> > work. It would be a major revision.
>
>did anybody follow or try to submit requirements to the nsis bof?
>does that seem like an appropriate venue for this?
>
>http://www.ietf.org/ietf/01mar/nsis-agenda.txt
>
>-gabriel
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 09:38:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17721
	for ; Fri, 30 Mar 2001 09:38:51 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25933;
	Fri, 30 Mar 2001 06:38:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29138;
	Fri, 30 Mar 2001 06:38:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEXDIm014666
	for ; Fri, 30 Mar 2001 06:33:13 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UEXDPk014665
	for mobile-ip-dist; Fri, 30 Mar 2001 06:33:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEX2Im014658
	for ; Fri, 30 Mar 2001 06:33:04 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13472
	for ; Fri, 30 Mar 2001 06:33:02 -0800 (PST)
Received: from hotmail.com (f165.law7.hotmail.com [216.33.237.165])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21723
	for ; Fri, 30 Mar 2001 06:33:02 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Mar 2001 06:33:01 -0800
Received: from 206.98.219.240 by lw7fd.law7.hotmail.msn.com with HTTP;	Fri, 30 Mar 2001 14:33:01 GMT
X-Originating-IP: [206.98.219.240]
From: "Hemant Chaskar" 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] QoS Work Item
Date: Fri, 30 Mar 2001 14:33:01 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 30 Mar 2001 14:33:01.0711 (UTC) FILETIME=[52E689F0:01C0B926]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,

I tend to think that signaling is the main issue. More so if we want our 
solution to be compatible with the techniques developed in other QoS WGs 
such as MPLS, DiffServ, IntServ, ISSLL and so on. Clearly, no or minimal 
signling would be needed for web transactions. However, signaling will be 
essential for say VoIP call, an important application from mobile terminals. 
We should not be developing wireless diffserv vs diffserv that exists today. 
Also, the QoS signaling must be intelligent enough to trigger end-to-end QoS
programming whenever needed and refrain from doing so when it is not needed. 
An example of the former case is the handover from indoor LAN to cellular 
network. In that case, the path of packets in the core will change as well. 
An example of the latter case will be micro-mobility. In other words, our 
thinking should not be limited to access side alone.

(Aside:

Thanks for informing about the Infocom paper. Frankly, I have not read it 
yet, but will do so soon. I would also like to point to another paper 
related to wireless diffserv:

A framework for QoS differentiation on 3G CDMA air interfaces, by Yile Guo 
and Hemant Chaskar, IEEE Wireless Comm. and Networking Conference (WCNC), 
September 2000.

)

Regards,
Hemant



>From: "Andrew T. Campbell" 
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: 
>Subject: RE: [mobile-ip] QoS Work Item
>Date: Thu, 29 Mar 2001 18:01:34 -0800
>
>I think the application of diffserv control to the
>wireless domain make good sense as a starting
>point. But there are many open questions there.
>
>Signaling is another issue. May be point-to-point
>implicit/explicit signaling makes sense for some
>continuous media services with holding times. But for web
>data its not practical - but some QOS control
>may be need for that web data.
>
>Clearly, there is no divorcing the wireless MAC capability
>from the solution space. We found that you could
>provide some simple support for wireless diffserv
>providing effective admission control:
>
>Barry, M., Campbell, A.T and A. Veres , "Distributed Control Algorithms for
>Service Differentiation in Wireless Packet Networks ", Proc. IEEE
>INFOCOM'2001, Anchorage, Alaska, 2001
>
>http://www.comet.columbia.edu/~campbell/andrew/publications/papers/infocom20
>01.pdf
>
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of
> > Hemant Chaskar
> > Sent: Thursday, March 29, 2001 10:20 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: Re: [mobile-ip] QoS Work Item
> >
> >
> > Hi,
> > It will be a good idea to use some premises while discussing
> > this issue
> > (please feel free to add to this list):
> >
> > 1. We should concentrate on QoS _signaling_ protocol that a
> > _host _ would
> > use to signal the QoS requirement of its flows along the new
> > end-to-end
> > path. Please note the distinction between the
> >
> > QoS protocols as used by network domains/routers for purposes
> > such as QoS
> > management, admission control, setting up LSPs or Label
> > switched paths,
> > MPLS-TE, Diffserv SLAs etc.
> >
> > and
> >
> > the QoS _signaling_ protocol used by _host_.
> > As long as the QoS _signaling_ protocol can deliver
> > sufficient (possible
> > more) information to the network/router level QoS modules, it
> > interoperates
> > with the QoS modules in the end-to-end path. It should not
> > matter if this
> > flow-level information (QoS requirement, traffic volume, packet
> > classification parameters etc.) is delivered to the router by
> > QoS signaling
> > protocol X or Y.
> >
> > 2. QoS signaling protocol must work with heterogeneous QoS
> > schemes: IntServ,
> > DiffServ or MPLS. MN may switch between IntServ and DiffServ
> > access domains
> > due to handovers. Also, handover may cause the path in the
> > core network
> > (which may be using MPLS) to change as well (consider
> > handover between
> > indoor LAN and cellular network).
> >
> > 3. We need to consider _fast_ QoS signaling along the new
> > end-to-end path
> > after handover. It is not acceptable that the QoS signaling
> > scheme takes one
> > round trip time (as in RSVP) before QoS contexts are set up in the
> > intermediate nodes after handover. Note that handover may
> > occur in the
> > middle of running QoS-sensitive session such as VoIP session.
> >
> > 4. We need to discuss what is more important from mobility
> > perspective. Few
> > examples are as follows:
> >
> > - QoS signaling protocol such as RSVP has been optimized with
> > central focus
> > on multicast. However, Mobile IP is not used if MN is
> > receiving multicast
> > session. In other words, in multicast case there are no
> > binding messages, MN
> > uses IGMP to register at the new AR.
> >
> > - Should QoS signaling protocol be designed with central
> > focus on topology
> > changes or frequent handoffs.
> >
> > - Pure static policy based QoS may not work in mobile
> > environment. For
> > example, MN may land up in the visited domain during a
> > session where its
> > flow parameters are not compliant with the QoS policy
> > parameters in that
> > domain. For example, the policy in the visited network may be
> > to use port
> > number x for an EF call and y for best effort if you are
> > accessing Internet
> > from that domain. However, MN already using port y for VoIP
> > session may land
> > up in this visited domain.
> >
> > Prioritizing these issues from mobility perspective will be
> > important as
> > single QoS _signaling_ protocol may not satisfy all the requirements.
> >
> > 5. Interoperability and optimization with micro-mobility
> > solutions. Here, we
> > should also think if we need to provide QoS _signaling_
> > solution at IP layer
> > or transport layer. Micro-mobility information is most
> > readily available at
> > IP layer. A secondary issue that arises here is whether CoA
> > information
> > should be accessible anywhere above IP layer. Because if
> > transport layer
> > protocol can grab this information, any other application can
> > also do so
> > thereby causing privacy concerns.
> >
> > 6. We need thin protocol as it may not be desirable to add
> > another protocol
> > software on sleek mobile terminals.
> >
> > 7. Issues like security, scalability are important as they
> > always have been.
> >
> > 8. What other working groups may find this item within their scope?
> > Definitely not MPLS, DiffServ or IntServ as they would not
> > care how the
> > information used by them arrives at a router. RSVP WG studies
> > RSVP by its
> > very name. However, RSVP, at least as it exists today, is not
> > suitable to be
> > used with Mobile IP. And also, its not only a small tweak to
> > it that would
> > work. It would be a major revision.
> >
> > Hemant
> >
> >
> > >From: Phil Roberts Reply-To: mobile-ip@sunroof.eng.sun.com To:
> > >"'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] QoS
> > Work Item Date:
> > >Thu, 29 Mar 2001 16:02:43 -0500
> > >
> > >
> > >We have a charter item to consider the relationship between
> > MIP and QoS.
> > >That's pretty vague. We've seen a couple of drafts on this,
> > and actually
> > >have a request to make one a working group item. This is
> > premature. The
> > >working group needs to consider what exactly we need to do.
> > >
> > >Our charter says: "In the longer term, the WG needs to
> > address: - QoS in
> > >the mobile IP environment using diff-serv and/or int-serv/RSVP."
> > >
> > >The problem is that MNs may be using QoS mechanisms on their
> > flows and
> > >these MNs will sometimes move using MIP mechanisms. We have
> > some options to
> > >explore about how to address this. We could address QoS
> > issues related
> > >specifically to mobile IP in this WG based on QoS work done
> > in other WGs
> > >(DiffServ, IntServ). We could just provide requirements from a MIP
> > >perspective to WGs working on these QoS mechanisms and ask
> > them to solve
> > >it. We could work jointly with folks in other working groups
> > to produce
> > >some proposals about how to proceed. It is clear we don't
> > have the option
> > >to invent another QoS protocol and we shouldn't be doing
> > this work in
> > >isolation.
> > >
> > >So, we'd like to know the working group's opinion on the
> > direction we take.
> > >
> > >
> > >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >
> >
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 09:52:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18524
	for ; Fri, 30 Mar 2001 09:52:54 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07568;
	Fri, 30 Mar 2001 06:52:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15243;
	Fri, 30 Mar 2001 06:52:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEp0Im014709
	for ; Fri, 30 Mar 2001 06:51:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UEp0QH014708
	for mobile-ip-dist; Fri, 30 Mar 2001 06:51:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UEopIm014701
	for ; Fri, 30 Mar 2001 06:50:52 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15056
	for ; Fri, 30 Mar 2001 06:50:51 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03675
	for ; Fri, 30 Mar 2001 06:50:50 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2UEomI02007
	for ; Fri, 30 Mar 2001 16:50:48 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id QAA14544; Fri, 30 Mar 2001 16:50:37 +0200
Message-ID: <3AC49D6E.70BB3C84@era.ericsson.se>
Date: Fri, 30 Mar 2001 16:51:26 +0200
From: Mattias Pettersson 
Organization: Ericsson Radio Systems AB
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
	 <3AC3EBC6.A8B9C32C@Kniveton.com> <3AC45921.270FFB2F@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

Thierry Ernst wrote:
> 
> Hi,
> 
> > I don't see exactly why this scenario is a problem. As long as the
> > network is in the routing tables of the home link's routers as having a
> > next hop of the MR, there's no problem.
> 
> Yes there is a problem because the prefix of the mobile network is not
> the same as the prefix of the MR's home address.
> 
> > This draft states in section 3.2.4:
> >       When the packet gets to the home
> >       network, BR checks its routing table to reach SN1. BR has a route
> >       to the mobile network; MR's home address is the next hop towards
> >       SN1. . . The HA intercepts
> >       the packet, but does not have a route to the mobile network.
> >
> > Why would the BR have a route to the mobile node, and the HA wouldn't?
> 
> Both BR and HA have one, and this route is via the MR (i.e. via
> int0).    I used the BR to point out the problem.
> 
> Then, the route recorded in the routing table says "route packets which
> destination is the mobile network prefix to the MR".   Unfortunately, MR
> has moved, what do you do then ?  HA does only know how to encapsulate a
> packet which destination = MR, not a packet which next hop = MR.    We
> have done the experiment on FreeBSD, has it is described in the draft.
> 
>  ---          ---
>  |BR|          |HA|
>  ---          ---
>    |               |
>    |               |
>  _____________ home link  P1::/64
>           |
>           | int0 P1::/64
>           |
>         ---
>         |MR|
>         ---
>          |
>          | int1 P2::/64
>          |
>    __________________  link internal to the home network
>       |                     |
>       | int3  P2::64    |  int4 P2::/64
>       |                     |
>     ---               ---
>    | H  |               | R  |
>     ---               - --
> 
> o The mobile network is attached to the Internet via the mobile router
> MR
> 
> o MR has (at least) 2 interfaces:
>         - int0 points to the home link, and has prefix 
>         - int1 points to a link internal to the mobile network and has prefix
> 
> 
> o All addresses in the mobile network have the same prefix P = the
> mobile network prefix
>         - length P = Lp  /   length P1 = Lp1 / length P2 = Lp2
>         - Lp  < Lp2.
>         - Lp first bits of P2 = P
>         - Lp first bits of P1 <> P
>         - Lp fitst bits of P1 <> Lp first bits of P2
> 
> o Both BR and HA have an entry in their routing table corresponding to
> the mobile network prefix : this entry says that packets to the
> mobile network should be routed to MR via int0.
> 
> o HA has received a binding update which says "packets sent to
> int0::/128  should be encapsulated".  Then, HA pretends to be int0.  It
> gets the packets directed to P2 and those directed to int0.
>         - Once HA gets a packet to MR (int0), no problem, encapsulation to MR's
> COA.
>         - If packet has a destination in the mobile network with prefix P2, HA
> won't know what to do with it, because the next hop to P2 is the HA
> itself.  It does not know how to handle it because it has only been
> instructed to redirected packet sent a 128 bits address, and not to
> prefix P.

I agree that the BU should express more, maybe a flag like "also forward
traffic destined to prefixes behind the MN".

> 
> > They are on the same link, so it seems like the HA is not picking up the
> > same routing info as the BR. This would be a configuration issue.
> 
> You may configure your routing tables in a way that it works, but this
> is more like a hack.  MIPv6 does not says how to re-route a packet wich
> is not sent to the home address.

But it says what to do with packets that have been intercepted. Please
see below.

> 
> The problem comes from the information carried in the Binding update
> which says "it destination = int0::/128 bits, encapsulate packet to the
> MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
> work, but you need to specify it in the spec.
> 

I agree that the spec is not 100% explicit on this. However, I see it
possible to interpret the spec as follows:

The HA's intercepting function is to pick up packets destined to the
MN's layer 2 address. It's ND proxy function will see to that all nodes
on the home link map the MN's int0 layer 3 address to the HA's layer 2
address. This is done by NS/NA mechanisms.

All routers on the home link should know, as you say, to forward packets
to P2::/64 to int0. They will end up in the HA. HA won't drop them,
since they are destined to it's layer 2 address.

At least in BSD, next check in HA is to check if this is a packet to the
HA itself. Since it doesn't have the int0 address configured on one of
its interfaces, it will see if it is forwardable, or drop the packet.

The HA will try to forward it, and would look in its routing tables. It
would have two interesting entries:
	dest P2::/64   use next-hop int0	(determine gateway)
	dest int0      use next-hop MN-tunnel	(determine interface and 
						layer 2 address)
It will end up sending it into the MN-tunnel.

This is not necessarily the exact behaviour of all implementations, but
I would like to see it as the correct conceptual behaviour.

/Mattias

PS. Don't get me wrong. I like your draft.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 10:27:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20610
	for ; Fri, 30 Mar 2001 10:27:44 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06139;
	Fri, 30 Mar 2001 07:27:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04770;
	Fri, 30 Mar 2001 07:27:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFQFIm014748
	for ; Fri, 30 Mar 2001 07:26:16 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UFQF9Q014747
	for mobile-ip-dist; Fri, 30 Mar 2001 07:26:15 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFQ6Im014740
	for ; Fri, 30 Mar 2001 07:26:06 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14628
	for ; Fri, 30 Mar 2001 07:26:04 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15045
	for ; Fri, 30 Mar 2001 07:26:04 -0800 (PST)
Received: from FRED-W2K.cisco.com (sjc-vpn-19.cisco.com [10.21.64.19])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA17211;
	Fri, 30 Mar 2001 07:26:25 -0800 (PST)
Message-Id: <5.0.2.1.2.20010330073026.02a5cd50@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 30 Mar 2001 07:30:43 -0700
To: mobile-ip@sunroof.eng.sun.com
From: Fred Baker 
Subject: RE: [mobile-ip] QoS Work Item
Cc: "'mobile-ip@sunroof.eng.sun.com'" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

At 04:42 PM 3/29/2001 -0600, Haseeb Akhtar wrote:
>I propose this group comes up with the requirements and then form
>a design team (that comprises of the both sides - QoS groups and us)
>to come up with a solution.

I'd be willing to work with such a working group or design team.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 11:17:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23242
	for ; Fri, 30 Mar 2001 11:17:44 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00714;
	Fri, 30 Mar 2001 08:17:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25483;
	Fri, 30 Mar 2001 08:17:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGF1Im014855
	for ; Fri, 30 Mar 2001 08:15:01 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UGF0OE014854
	for mobile-ip-dist; Fri, 30 Mar 2001 08:15:00 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGEqIm014847
	for ; Fri, 30 Mar 2001 08:14:52 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06637
	for ; Fri, 30 Mar 2001 08:14:52 -0800 (PST)
From: zhigang.liu@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27052
	for ; Fri, 30 Mar 2001 08:14:51 -0800 (PST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2UGEsg22345
	for ; Fri, 30 Mar 2001 10:14:54 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 30 Mar 2001 10:14:50 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 30 Mar 2001 10:14:50 -0600
Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213BB7C@daeis05nok>
To: Lars-Erik.Jonsson@epl.ericsson.se, rajeev.koodli@nokia.com,
        micke@cs.arizona.edu, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se,
        seamoby@cdma-2000.org
Subject: [mobile-ip] RE: [rohc] Compression startup behavior
Date: Fri, 30 Mar 2001 10:14:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> However, it is not a header compression issue.
> 
> /L-E

Sorry, I still don't get it after the statement has been 
repeated many times (both this and last year). Do you mean 
that the logic (e.g. not sending IR packets to reestablish
context over the air after receiving context from the old
compressor) is not a header compression issue?

Br,
Zhigang


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 11:38:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24653
	for ; Fri, 30 Mar 2001 11:38:28 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24013;
	Fri, 30 Mar 2001 08:38:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20537;
	Fri, 30 Mar 2001 08:00:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFxcIm014833
	for ; Fri, 30 Mar 2001 07:59:39 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UFxcQP014832
	for mobile-ip-dist; Fri, 30 Mar 2001 07:59:38 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UFxTIm014825
	for ; Fri, 30 Mar 2001 07:59:29 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20947
	for ; Fri, 30 Mar 2001 07:59:29 -0800 (PST)
From: zhigang.liu@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13291
	for ; Fri, 30 Mar 2001 07:59:28 -0800 (PST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2UFxPg20380
	for ; Fri, 30 Mar 2001 09:59:30 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 30 Mar 2001 09:59:17 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 30 Mar 2001 09:59:17 -0600
Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213BB7B@daeis05nok>
To: Lars-Erik.Jonsson@epl.ericsson.se, Hesham.Soliman@era.ericsson.se
Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org
Subject: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
Date: Fri, 30 Mar 2001 09:59:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> However, since 
> context transfer is out of scope for header compression 
> development (snip)
>  
> /L-E

Why do you say that? Context transfer requires some new
signaling between the new and old compressor (decompressor).
The logic of ROHC also needs to be amended. Do you think
all of those should not be part of the protocol and just
an implementation issue? How about interoperability?

(The emails from other people seems indicating just the opposite.)

Zhigang


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 11:50:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25394
	for ; Fri, 30 Mar 2001 11:50:47 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05767;
	Fri, 30 Mar 2001 08:50:35 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01558;
	Fri, 30 Mar 2001 08:50:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGmtIm014992
	for ; Fri, 30 Mar 2001 08:48:55 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UGmtmd014991
	for mobile-ip-dist; Fri, 30 Mar 2001 08:48:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UGmkIm014984
	for ; Fri, 30 Mar 2001 08:48:46 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02604
	for ; Fri, 30 Mar 2001 08:48:45 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06071
	for ; Fri, 30 Mar 2001 08:48:44 -0800 (PST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2UGmhs06622
	for ; Fri, 30 Mar 2001 18:48:43 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 30 18:47:17 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 30 Mar 2001 18:44:28 +0200
Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD07@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Mobile Netwoks in MIPv6
Date: Fri, 30 Mar 2001 18:48:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


> > So do you think the draft or at least the problem should
> > be considered as part of the charter ?
> > If so, you might like to consider this draft as one proposal
> > (a good one IMHO).
> 
> Can you please give an example of how a network which is properly
> configured would fail in this circumstance? It seems like it would
> already be handled by whatever routing protocol is used, and the base
> Mobile IPv6 spec.
> 
	=> Hopefully this would answer your previous comments 
	(that I removed). 
	When the HA forwards packets to MNs behind the MR, 
	it doesn't address thse packets to the MR. Since the MR
	has "gone", no one is advertising reachability to it's 
	subnet. So the HA will not know what to do with it. 
	Thierry mentioned in his presentation that he proved 
	this case in thei labs.

	We need to make sure the MR sends a BU for the 
	entire prefix. 

	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 12:08:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26416
	for ; Fri, 30 Mar 2001 12:08:37 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21529;
	Fri, 30 Mar 2001 09:08:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19481;
	Fri, 30 Mar 2001 09:08:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UH7AIm015096
	for ; Fri, 30 Mar 2001 09:07:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UH79qU015095
	for mobile-ip-dist; Fri, 30 Mar 2001 09:07:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UH71Im015088
	for ; Fri, 30 Mar 2001 09:07:01 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UH5jP04119;
	Fri, 30 Mar 2001 09:05:45 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103301705.f2UH5jP04119@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <034BEFD03799D411A59F00508BDF7546013DBD07@esealnt448.al.sw.ericsson.se>
 from "Hesham Soliman  (ERA)" at "Mar 30, 2001 06:48:40 pm"
To: Hesham.Soliman@era.ericsson.se
Date: Fri, 30 Mar 2001 09:05:45 -0800 (PST)
CC: mobile-ip@sunroof.eng.sun.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>>
>> Can you please give an example of how a network which is properly
>> configured would fail in this circumstance? It seems like it would
>> already be handled by whatever routing protocol is used, and the base
>> Mobile IPv6 spec.
>>
>       => Hopefully this would answer your previous comments
>       (that I removed).
>       When the HA forwards packets to MNs behind the MR,
>       it doesn't address thse packets to the MR. Since the MR
>       has "gone", no one is advertising reachability to it's
>       subnet. So the HA will not know what to do with it.
>       Thierry mentioned in his presentation that he proved
>       this case in thei labs.

When MR was at home it was advertising reachability and as soon
as it moved to the foreign link one would expect that to still
happen and this time,  tunneled to HA. If tunnel is yet another
interface, then  the reachability should be advertised, right ?
Why isn't this happening ?

If there were static routes on the Home agent, then this is
not a problem too. Just to make the picture clearer.

-mohan

>
>       We need to make sure the MR sends a BU for the
>       entire prefix.
>
>       Hesham
>



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 12:25:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27231
	for ; Fri, 30 Mar 2001 12:25:14 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05373;
	Fri, 30 Mar 2001 09:25:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23216;
	Fri, 30 Mar 2001 09:24:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UHNlIm015145
	for ; Fri, 30 Mar 2001 09:23:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UHNlDk015144
	for mobile-ip-dist; Fri, 30 Mar 2001 09:23:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UHNcIm015137
	for ; Fri, 30 Mar 2001 09:23:38 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09658
	for ; Fri, 30 Mar 2001 09:23:38 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06220
	for ; Fri, 30 Mar 2001 09:23:36 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA11848
	for ; Fri, 30 Mar 2001 09:23:36 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UHNXY14075
	for ; Fri, 30 Mar 2001 09:23:33 -0800
X-mProtect:  Fri, 30 Mar 2001 09:23:33 -0800 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdqsBVgi; Fri, 30 Mar 2001 09:23:10 PST
Message-ID: <3AC4C0FE.3B657109@cs.ucl.ac.uk>
Date: Fri, 30 Mar 2001 09:23:11 -0800
From: Theo Pagtzis 
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multiple tunnels over unoptimized route packets f or 
 Extended mode
References: <034BEFD03799D411A59F00508BDF7546013DBD06@esealnt448.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>

Hi Hesham,

   more elaboration below,


>
>
> > In that case I can only assume that the
> > fixed MAP case is dealt by the Basic mode.
> >
>         => The spec says, that Extended mode can handle the MR case and
>         the normal (fixed) case. Basic mode can only handle the fixed case.
>
>         So just because a MAP is fixed that doesn't mean it has to be
>         Basic mode, either one would work.
>

correct. This is unquestionable. But till now in our discussion you have not showed me
where Basic Mode is used for the fixed case. Remember you have to setup/configure manually
the thing. So once you describe for fixed nodes that Basic mode is used and then when the
extended mode comes in you swap the use of basic mode for the fixed MAP case with extended
mode. How are you going to reconfigure your MAP and advertising point manually?  Is there
a magic stick around? By the time you configure things manually (yeah right ...out of
scope for this document but basicaly the beast is hiding inside it....) then you have to
stick by your guns...you can't just say that the spec does not preclude it...sure it
doesn't...as it sure doesn't preclude that the thing is not going to work if the spec goes
on like that..because we have to stick with something with this spec in this version not
one coming out sometime soon..

You could ponder for ever for 'potentially' nice things of Basic mode but hey tell me
where are you using the thing but consistently...otherwise I will get a headache and drop
using the spec alltogether as an implementor...



>
> > If you say that the fixed map case is NOW,
> > NOT dealt by basic mode,
> >
>         => Did I say that ??? I said both modes can handle it.

yes the spec says that but reality proves the opposite when it comes to it...just follow
the reasoning..(if you want that is...)

>
>
> > I am left with no option but AGREE with Charlie on his
> > request that the Basic mode should really go AWAY... I cannot see any point why the
> > basic mode need stay there anymore. I would be grateful if you could convince me for
> > the opposite....
> >
>         => I can try. BTW there is a coparison between the two modes
>         in the draft.
>         Anyway,

you can try but you don't...this is the problem in this sort of interactions..I never get
the answer


> Basic mode provides some features that Extended mode
>         doesn't. For example location privacy is one of the major advantages.

location privacy for who ?

the MN with respect to the visiting domain  (1)
       or
the MN with respect to the world. ?????? (2)

(1)   the MN with respect to the visited domain is certainly not hidden. The MAP knows its
LCoA so that it can tunnel to it.
(2)    the MN with respect to the world is definetely not hidden. Remember that upstream
you send packet with your src addr as the LCoA as the egress filtering won't let you out.
Also you do not specify anywhere that upstream data packets have the source addr as the
RCoA, and you know very well why.

So if a node really wants to get the so called private LCoA of the node it simply bypasses
the core CN functinality (on its own box) by not substituting the src addrs with the Home
Address dest option. And that will be the end of location privacy. When it comes to
security people are not
holding a cross in their hands..they are really nasty. And to bypass that CN function is
only easy

so location privacy is a gonner...


>
>
>         Also Basic mode does not require any modification to the HA.
>         Extended mode does. This is needed to enable forwarding of
>         packets addressed to the MN's Site local home address.
>

Sure the extended mode does what different to the MAP (so-called HA) it keeps the home
address instead of the RCoA in the B-Cache and detunnels before it retunnels....year
right....this is too much...I don't think this wins as an argument..with all due
respect...


>
>         In addition if we work out a redundancy mechnism for MAPs
>         or HA's then it would be much easier to design it for
>         Basic mode.
>

In greece we have a saying that if my dog had wheels he would be a skateboard....I think
you are providing me with a similar argument here...
consider: you are designing a whole mode in the core of the protocol for something that is
out of scope of the core of the protocol....hmmmmm
I could then say with no remorse that this is DEFINETELY OUT of the scope of this draft...

By the way don't get picky now about the comment...see what I mean behind it....


>
>         So there are pros and cons for each one. Since the interface
>         (MAP option and BU) to the MN is very similar, we thought
>         it would be a good idea to have both.
>         Also people on this list and others expressed interest in
>         having Basic mode for location privacy to hide the
>         operator's addresses (in outgoing packets).

operator's addresses ....?????   you mean the LCoA...please see above...

I would like to hear people that ARE supporting location privacy through HMIPv6 on that.
Please give me some arguments as well. If I cannot hear anybody I don't think they
exist.....


>
>
> > I need not emphasize further as negative point of Basic mode,  that the generation of
> > multiple RCoA for MN so as to sustain unique representation of the MN in the visited
> > domain, while you have a unique Home Addr already at hand (but you don't divulge that
> > to the MAP - I wonder why???) is also bound to find problems:
> >
> > 1) by the management of MANY RCoA for no apparent reason
> >
>         => Where does MANY come from ? Only one is needed.
>         or does MANY = MANY MNs ? If so how is it different
>         in the HA case.

ok back to the spec. The basic mode mentions that an MN is receiving the MAPs prefix and
creates a CoA. This is the RCoA that is sent back for DAD to the MAP. I can only assume
that each MN will create a different RCoA in Basic mode, since this is the entry in the
home addr option B-Cache of the MAP. THAT MUST BE UNIQUE and thus one per MN. That implies
if X is the number of registering MNs with THAT MAP then X will be the number of
DIFFERENT RCoAs in the B-Cache of THAT MAP. This is of course unless all MNs conspire and
produce one RCoA but then the B-Cache in that MAP is useless....



>
>
> > 2) DAD checks by the hunderds for no apparent reason
> >
>         => hundreds ? where does a hundred come from ?
>         You mean hundreds of MNs ? Actually there
>         maybe hundreds of thousands ! But the same goes
>         for the HA.
>

According to the above reasoning you will have as many DADs as RCoAs for the X number of
MNs registering under that MAP.



>
> > If however the Basic mode is destined for fixed MAPs then, all I am crying out loud
> > is that when route unoptimized packets leaving from the MN's HA (when that HA has not
> > received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the
> > mean time)
> >
>         => Let me get this right. You're saying the MN's HA already has a binding
>         for the MN. This binding was based on the MN's previous location (before
>         it appeared on the MR's subnet) Correct ?

No the binding in the MN's HA maintain (at that moment in time) the last  IP address (the
last LCoA) of the MR/MAP before it flew off.

>
>
>         If the MN doesn't / can't send another BU to its HA because it doesn't
>         have the MR/MAP's address or because the MR disappeared (ie. no
>         connectivity) then packets from its HA will be delivered to the old
>         address, ie. lost.
>

Nooooooooope.... remember that in extende mode you have given to the MN's HA the IP
address of the MR/MAP in that MR/MAP home domain.
Now the MR/MAP has flown off. So as far as the protocol is concerned the MR/MAP is just
another HMIPv6 node. So what does that node do. It provides to its HA (that is the
MR/MAP's HA) its latest binding. This MUST be a RCoA since it registers with fixed MAP. So
the HA of the MR/MAP/HMIPv6 node will now intercept all packets that come on its IP
address. That includes all packets that arrive tunneled from the MN's HA according that
the aformentioned binding. That is the old IP address of the MR/MAP as the alt-CoA for the
MN BEFORE the MR/MAP/HMIPv6 node flew off !!!!!!!!!!!!

So guess what...one more tunnel from the MR/MAP/HMIPv6 node on the received packets from
MN's HA... (this make a total of 2 so far). The third is effected by the fixed MAP as a
good old HA local instantiation....


>
> > towards the MN,  AND the MR is away but the BU from the MN has not reached the MN's>
> > HA (MR/MAP has not got yet  its own LCoA), then the MR/MAP's HA will have to>
> > intercept the packet and tunnel it to the RCoA
> >
>         => How does the MR's HA do that ? How can it even receive the
>         MN's packets ?

That is the thing I am not talking about upstream packets (the MN is still waiting on the
MR/MAP/HMIPv6) to get its own LCoA and attach on a subnet. so no BU to it HA yet...

I am talking about downstream packets sent tunneled by the MN's HA. That is packets coming
from new CN's towards the MN. They will have to go through the MN's HA and they get
tunnelled and blah blah ...see above...



>
>         If the MR's HA is the same as the MN's HA then the MN isn't
>          reachable and it doesn't even know that it
>         moved because it is still receiving its Home RA.
>

I did not say such a thing in the slightest...wrong turn here... both HAs are different
and defend different addr

The MN's HA is intercepting packets at that time for the MN's home address. But in
extended mode it has to destine them to the MR/MAP/HMIPv6 node IP address (remember?)
The MR/MAP/HMIPv6's HA is intercepting packets that arrive to the IP addr of that
MR/MAP/HMIPv6 node...Guess what these are (since it is a router)...they are (among others)
packets that arrive tunneled to the IP addr of the MR/MAP/HMIPv6.....see?




>
>         If the MN's HA is different from the MR's HA, then the packets
>         will never be tunnelled or even received by the MR's HA.
>         This is the problem identified by Thierry's draft. This is
>         a problem in MIPv6 but you seem to assume that it's
>         solved and that the MR's HA will just tunnel packets
>         for the MR's entire subnet.
>         Have you read Thierry's draft ? If not then reading it
>         would help.

not so fast here....in extended mode the MN is providing the IP addr of the MAP. If the
MAP moves (MR) it behaves like a standard HMIPv6 node. So it needs a HA to intercept
packets for it. Again guess what these packets are? Amongs others, packets that arrive
tunneled to the MR/MAP/HMIPv6 node. So who will intercept them???? .....the MR/MAP/HMIPv6
node's HAAAAAAA.....so another encapsulation until the fixed MAP of the MR/MAP/HMIPv6
node....


>
>         Packets from the CN to the MN will be tunnelled by the MN's
>         HA to the CoA in the Binding Cache. If there is no entry
>         there is no tunnelling. If there is an entry that is no longer
>         valid (because the MN moved) the HA will comtinue tunnelling
>         to that CoA in the Binding Cache regardless, until it's
>         given a new CoA. I really can't see how the scenario you're
>         describing is possible.
>
>

Yes but what is the
CoA......?????????????????????????????????????????????????????????????????????????
the IP addr of the MR/MAP/HMIPv6 node...so the packet will arrive somewhere and will be
encapsulated again as soon as the HA for that MR/MAP/HMIPv6 intercepts them...

Basic assumption here....all nodes have a HA when moving.... even MR/MAP/HMIPv6
nodes......


So you just said it but did not continue here....please move your thoughts on that
scenario...I think you do see it ..... :)))))))


If you still cannot see the scenario...I seriously suspicious here....just to make it a
little more fun...I think you need to take off the Ericsson hat (understandable), again
with all due respect....and put your research engineer hat on


and a great day to all


Theo


UCL / Mobile Systems


>         Hesham
>



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 12:54:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29649
	for ; Fri, 30 Mar 2001 12:54:18 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18669;
	Fri, 30 Mar 2001 09:53:57 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06523;
	Fri, 30 Mar 2001 09:53:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UHqSIm015270
	for ; Fri, 30 Mar 2001 09:52:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UHqR08015269
	for mobile-ip-dist; Fri, 30 Mar 2001 09:52:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UHqIIm015262
	for ; Fri, 30 Mar 2001 09:52:19 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00080
	for ; Fri, 30 Mar 2001 09:52:18 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29413
	for ; Fri, 30 Mar 2001 09:52:17 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15006
	for ; Fri, 30 Mar 2001 09:52:16 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UHqD017271
	for ; Fri, 30 Mar 2001 09:52:13 -0800
X-mProtect:  Fri, 30 Mar 2001 09:52:13 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90)
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdk7JbjA; Fri, 30 Mar 2001 09:51:25 PST
Message-ID: <3AC4C79D.794BDF32@iprg.nokia.com>
Date: Fri, 30 Mar 2001 09:51:25 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
References:  <3AC3B7C2.8E2A3420@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Gabriel,

I did make my 3 minute presentation. FYI, following were the key points.

1. Any mobility-aware signaling protocol must be able to limit the
extent of signaling to only those nodes (in the packet stream path)
affected by mobility.

2. It must be able to provide fast response time. This includes how
quickly the protocol is able to detect that the mobile node has moved,
as well as the how fast the protocol itself is.

3. It should be able to make use of intrinsic IP mobility signaling.


Regards,

-Rajeev


gabriel montenegro wrote:
> 
> Hemant Chaskar wrote:
> 
> > 8. What other working groups may find this item within their scope?
> > Definitely not MPLS, DiffServ or IntServ as they would not care how the
> > information used by them arrives at a router. RSVP WG studies RSVP by its
> > very name. However, RSVP, at least as it exists today, is not suitable to be
> > used with Mobile IP. And also, its not only a small tweak to it that would
> > work. It would be a major revision.
> 
> did anybody follow or try to submit requirements to the nsis bof?
> does that seem like an appropriate venue for this?
> 
> http://www.ietf.org/ietf/01mar/nsis-agenda.txt
> 
> -gabriel


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 13:32:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03015
	for ; Fri, 30 Mar 2001 13:32:33 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02974;
	Fri, 30 Mar 2001 10:31:34 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27649;
	Fri, 30 Mar 2001 10:31:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UITYIm015378
	for ; Fri, 30 Mar 2001 10:29:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UITYA9015377
	for mobile-ip-dist; Fri, 30 Mar 2001 10:29:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UITPIm015370
	for ; Fri, 30 Mar 2001 10:29:25 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27022
	for ; Fri, 30 Mar 2001 10:29:24 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12057
	for ; Fri, 30 Mar 2001 10:29:22 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA12059
	for ; Fri, 30 Mar 2001 10:29:42 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADG14406;
	Fri, 30 Mar 2001 10:29:19 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA04017; Fri, 30 Mar 2001 10:29:19 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15044.53375.595420.107599@thomasm-u1.cisco.com>
Date: Fri, 30 Mar 2001 10:29:19 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
In-Reply-To: <3AC4C79D.794BDF32@iprg.nokia.com>
References: 
	<3AC3B7C2.8E2A3420@sun.com>
	<3AC4C79D.794BDF32@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev Koodli writes:
 > Hello Gabriel,
 > 
 > I did make my 3 minute presentation. FYI, following were the key points.
 > 
 > 1. Any mobility-aware signaling protocol must be able to limit the
 > extent of signaling to only those nodes (in the packet stream path)
 > affected by mobility.

   This is a tautology though. I believe that the
   desirable characteristic is that the QoS
   reestablishment converges locally. If we need
   to go clear back to the CN (which also fits
   your definition), speed of light considerations
   may produce unacceptible results.
 
 > 2. It must be able to provide fast response time. This includes how
 > quickly the protocol is able to detect that the mobile node has moved,
 > as well as the how fast the protocol itself is.

   I'll just throw out here that damping
   mechanisms for route flapping are going
   to be problem.
 
 > 3. It should be able to make use of intrinsic IP mobility signaling.

   This is a huge leap. In fact as it currently
   stands, there is no need for a mobile to have
   any mobility signaling local to its attachment
   point. That, if anything, argues for just the
   opposite: we should not explicitly link QoS
   signaling to mobility signaling.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 13:51:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04520
	for ; Fri, 30 Mar 2001 13:51:45 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19431;
	Fri, 30 Mar 2001 10:51:31 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01268;
	Fri, 30 Mar 2001 10:51:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UInvIm015427
	for ; Fri, 30 Mar 2001 10:49:57 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UInu2W015426
	for mobile-ip-dist; Fri, 30 Mar 2001 10:49:56 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged))
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UInmIm015419
	for ; Fri, 30 Mar 2001 10:49:48 -0800 (PST)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2UInkWI598834;
	Fri, 30 Mar 2001 10:49:47 -0800 (PST)
Message-Id: <200103301849.f2UInkWI598834@jurassic.eng.sun.com>
Date: Fri, 30 Mar 2001 10:50:49 -0800 (PST)
From: Samita Chakrabarti 
Subject: Re: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover
To: Hesham.Soliman@era.ericsson.se
Cc: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: URUmNXTDOWMt4PHD31N3ug==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hesham,

> > I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
> > provide header compression support, which involves context initialization,
> > which in turn could be avoided during handovers using context relocation!
> > 
> 	=> No, I disagree. IP_deployment_in cellular networks relies 
> 	on ROHC. MIPv4/v6 in general relies on ROHC to be deployed
> 	in cellular networks. This is the reality. If you're sending complete
> 	IP headers in a VOIP call, then I'll just stick to my GSM phone.
> 
> 	Hesham


But the fact is that HMIPv6 draft is making an assumption that ROHC  is a 
pre-requisite to implement HMIPV6 support. 

So, from your above statement, it is clear that hmipv6 is only targeting
cellular systems that will have ROHC or rfc2507 HC implemented.

BTW, HMIPV6 draft talks about hierarchical networks in general, why do you
assume that ROHC will be implemented in all hierarchical networks. There
may be small  scale wireless networks which may not have header compression
at the access points.
Also, in regular netwroks, if I have a choice of saving
40 bytes, why don't I do that ?  The third mode proposal is not complex at all
and it does only destination address substitution once at MAP and once at MN, 
mobileIpv6 is doing similar mechanism at end nodes  with homeaddress option.
So may be 10-15 lines of additional code.

-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 14:09:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06039
	for ; Fri, 30 Mar 2001 14:09:16 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29054;
	Fri, 30 Mar 2001 11:09:03 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18869;
	Fri, 30 Mar 2001 11:08:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJ7aIm015460
	for ; Fri, 30 Mar 2001 11:07:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UJ7aYo015459
	for mobile-ip-dist; Fri, 30 Mar 2001 11:07:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJ7RIm015452
	for ; Fri, 30 Mar 2001 11:07:27 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05264
	for ; Fri, 30 Mar 2001 11:07:26 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11930
	for ; Fri, 30 Mar 2001 12:07:25 -0700 (MST)
Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id VAA28403
	for ; Fri, 30 Mar 2001 21:07:24 +0200 (MET DST)
Message-ID: <3AC4D96C.84A92A3@inrialpes.fr>
Date: Fri, 30 Mar 2001 21:07:24 +0200
From: Thierry Ernst 
Organization: INRIA Rhone-Alpes
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
		 <3AC3EBC6.A8B9C32C@Kniveton.com> <3AC45921.270FFB2F@inrialpes.fr> <3AC49D6E.70BB3C84@era.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

Thanks to your comments, Mattias.

> I agree that the BU should express more, maybe a flag like "also forward
> traffic destined to prefixes behind the MN".

I think this is not enough.   It would be better to explicitly specify
the said prefix in the BU.    How would the HA knows what is the prefix
behind the MR - I mean, how would it do this if you don't add anything
in the MIPv6 spec and if you strickly follow the spec ?

> > > They are on the same link, so it seems like the HA is not picking up the
> > > same routing info as the BR. This would be a configuration issue.
> >
> > You may configure your routing tables in a way that it works, but this
> > is more like a hack.  MIPv6 does not says how to re-route a packet wich
> > is not sent to the home address.
> 
> But it says what to do with packets that have been intercepted. Please
> see below.
> 
> > The problem comes from the information carried in the Binding update
> > which says "it destination = int0::/128 bits, encapsulate packet to the
> > MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
> > work, but you need to specify it in the spec.
> 
> I agree that the spec is not 100% explicit on this. However, I see it
> possible to interpret the spec as follows:

Hum, interpretation always leaves room for misunderstanding and
misinterpretation ...

> The HA's intercepting function is to pick up packets destined to the
> MN's layer 2 address. It's ND proxy function will see to that all nodes
> on the home link map the MN's int0 layer 3 address to the HA's layer 2
> address. This is done by NS/NA mechanisms.
>
> All routers on the home link should know, as you say, to forward packets
> to P2::/64 to int0. They will end up in the HA. HA won't drop them,
> since they are destined to it's layer 2 address.
>
> At least in BSD, next check in HA is to check if this is a packet to the
> HA itself. Since it doesn't have the int0 address configured on one of
> its interfaces, it will see if it is forwardable, or drop the packet.

Agreed.

> The HA will try to forward it, and would look in its routing tables. It
> would have two interesting entries:
>         dest P2::/64   use next-hop int0        (determine gateway)
>         dest int0      use next-hop MN-tunnel   (determine interface and
>                                                 layer 2 address)
> It will end up sending it into the MN-tunnel.

Thanks for your clarification.  

If I follow you, you mean that the HA already has all the necessary
information in its routing table to do it right, but that some
implementations might not do it.

I do not exaclty know how algorithms for searching the routing table
really work, but I would think that finding an entry and then searching
for a second one is rather complex and may end up in routing loops.  I
am just wondering.

> This is not necessarily the exact behaviour of all implementations, but
> I would like to see it as the correct conceptual behaviour.
For sure, the FreeBSD's HA is getting confused.

> PS. Don't get me wrong. I like your draft.
It wouldn't arm me anyway :-) Just trying to fix the trick.

Thierry.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 14:15:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06546
	for ; Fri, 30 Mar 2001 14:14:59 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08142;
	Fri, 30 Mar 2001 11:14:43 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07482;
	Fri, 30 Mar 2001 11:14:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJCmIm015491
	for ; Fri, 30 Mar 2001 11:12:48 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UJClZv015490
	for mobile-ip-dist; Fri, 30 Mar 2001 11:12:47 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJCdIm015483
	for ; Fri, 30 Mar 2001 11:12:39 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19948
	for ; Fri, 30 Mar 2001 11:12:38 -0800 (PST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06281
	for ; Fri, 30 Mar 2001 11:12:37 -0800 (PST)
Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id VAA28472
	for ; Fri, 30 Mar 2001 21:12:36 +0200 (MET DST)
Message-ID: <3AC4DAA4.E5B44641@inrialpes.fr>
Date: Fri, 30 Mar 2001 21:12:36 +0200
From: Thierry Ernst 
Organization: INRIA Rhone-Alpes
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <200103301705.f2UH5jP04119@locked.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> >       => Hopefully this would answer your previous comments
> >       (that I removed).
> >       When the HA forwards packets to MNs behind the MR,
> >       it doesn't address thse packets to the MR. Since the MR
> >       has "gone", no one is advertising reachability to it's
> >       subnet. So the HA will not know what to do with it.
> >       Thierry mentioned in his presentation that he proved
> >       this case in thei labs.
> 
> When MR was at home it was advertising reachability and as soon
> as it moved to the foreign link one would expect that to still
> happen and this time,  tunneled to HA. If tunnel is yet another
> interface, then  the reachability should be advertised, right ?
> Why isn't this happening ?

Indeed, nothing should prevent the MR to advertise reachability to its
the subnets behind it and nobody stated this.    Yes, advertisments
should effectively be tunneled to HA.   (I can not remember if this is
pointed out in the MIPv6 draft or not, or somewhere else;  could someone
say where ?)

The problem comes from what it being recorded in the Binding Cache at
the HA: nothing tells the HA to encapsulate packets sent to the
mobile_network_prefix P2.   If some implementations do it, this is an
interpretation of the MIPv6 specification and would add room for
hacking:  why should the HA encapsulate packets sent to prefix P2 to the
MR's coa if it wasn't instructed to do it ?
 
Any comments on what the HA should be allowed to do ?


> If there were static routes on the Home agent, then this is
> not a problem too. Just to make the picture clearer.


Thierry.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 14:48:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09317
	for ; Fri, 30 Mar 2001 14:48:43 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03918;
	Fri, 30 Mar 2001 11:46:55 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15386;
	Fri, 30 Mar 2001 11:46:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJjLIm015540
	for ; Fri, 30 Mar 2001 11:45:21 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UJjLNq015539
	for mobile-ip-dist; Fri, 30 Mar 2001 11:45:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UJjCIm015532
	for ; Fri, 30 Mar 2001 11:45:12 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14978
	for ; Fri, 30 Mar 2001 11:45:11 -0800 (PST)
Received: from hotmail.com (f180.law7.hotmail.com [216.33.237.180])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02505
	for ; Fri, 30 Mar 2001 11:45:10 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Mar 2001 11:45:10 -0800
Received: from 206.98.219.240 by lw7fd.law7.hotmail.msn.com with HTTP;	Fri, 30 Mar 2001 19:45:10 GMT
X-Originating-IP: [206.98.219.240]
From: "Hemant Chaskar" 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
Date: Fri, 30 Mar 2001 19:45:10 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 30 Mar 2001 19:45:10.0098 (UTC) FILETIME=[EDE39B20:01C0B951]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
>From: Michael Thomas 
>Reply-To: mobile-ip@sunroof.eng.sun.com
>To: mobile-ip@sunroof.eng.sun.com
>Subject: Re: [mobile-ip] QoS Work Item
>Date: Fri, 30 Mar 2001 10:29:19 -0800 (PST)

>
>Rajeev Koodli writes:
>  > Hello Gabriel,
>  >
>  > I did make my 3 minute presentation. FYI, following were the key 
>points.
>  >
>  > 1. Any mobility-aware signaling protocol must be able to limit the
>  > extent of signaling to only those nodes (in the packet stream path)
>  > affected by mobility.
>
>    This is a tautology though. I believe that the
>    desirable characteristic is that the QoS
>    reestablishment converges locally. If we need
>    to go clear back to the CN (which also fits
>    your definition), speed of light considerations
>    may produce unacceptible results.

I disagree with this speed of light consideration. Speed of light 
"limitation" applies to both signaling packet and data packet. So a smart 
signaling scheme will put QoS signaling trigger before any data packet to 
overcome the speed of light or satellite propagation delay limitation. This 
is exactly why we cannot live with schemes that involve one round-trip 
latency in QoS programming. However, it is definitely possible to achieve 
fast response time even if we need to go clear back to the CN, I just 
describe how!

>
>  > 2. It must be able to provide fast response time. This includes how
>  > quickly the protocol is able to detect that the mobile node has moved,
>  > as well as the how fast the protocol itself is.
>
>    I'll just throw out here that damping
>    mechanisms for route flapping are going
>    to be problem.

What is the probability that route flapping happens in the end-to-end path 
upon every handover? Also, modern techniques such as MPLS will greatly 
reduce route flapping. In modern QoS mechanisms such as DiffServ and MPLS, 
QoS signaling scheme will be insensetive to intra-domain route flapping. It 
is safe to assume that the ingress and egress routers of an intermediate 
network domain in the end-to-end path remain constant. So, it looks to me 
that fast signaling is still doable.

>
>  > 3. It should be able to make use of intrinsic IP mobility signaling.
>
>    This is a huge leap. In fact as it currently
>    stands, there is no need for a mobile to have
>    any mobility signaling local to its attachment
>    point. That, if anything, argues for just the
>    opposite: we should not explicitly link QoS
>    signaling to mobility signaling.
>
>		Mike

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 15:46:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13212
	for ; Fri, 30 Mar 2001 15:46:57 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14261;
	Fri, 30 Mar 2001 12:46:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10084;
	Fri, 30 Mar 2001 12:46:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UKjBIm015585
	for ; Fri, 30 Mar 2001 12:45:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UKjAap015584
	for mobile-ip-dist; Fri, 30 Mar 2001 12:45:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UKj1Im015577
	for ; Fri, 30 Mar 2001 12:45:01 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18389
	for ; Fri, 30 Mar 2001 12:45:00 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11054
	for ; Fri, 30 Mar 2001 13:44:59 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA04707
	for ; Fri, 30 Mar 2001 12:45:03 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADG18331;
	Fri, 30 Mar 2001 12:44:57 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA04039; Fri, 30 Mar 2001 12:44:57 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15044.61513.251295.650822@thomasm-u1.cisco.com>
Date: Fri, 30 Mar 2001 12:44:57 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hemant Chaskar writes:
 > I disagree with this speed of light consideration. Speed of light 
 > "limitation" applies to both signaling packet and data packet. So a smart 
 > signaling scheme will put QoS signaling trigger before any data packet to 
 > overcome the speed of light or satellite propagation delay limitation. This 
 > is exactly why we cannot live with schemes that involve one round-trip 
 > latency in QoS programming. However, it is definitely possible to achieve 
 > fast response time even if we need to go clear back to the CN, I just 
 > describe how!

   We've been through this before. Installing QoS
   state is always slower than forwarding. You have
   a built in race condition.

 > >    I'll just throw out here that damping
 > >    mechanisms for route flapping are going
 > >    to be problem.
 > 
 > What is the probability that route flapping happens in the end-to-end path 
 > upon every handover? Also, modern techniques such as MPLS will greatly 
 > reduce route flapping. 

   Tell me: how do, at some interior node in the
   network, differentiate a "good" topology
   change (read: does not require flap protection)
   from a "bad" topology change (ie, requires
   damping)?

 > In modern QoS mechanisms such as DiffServ and MPLS, 
 > QoS signaling scheme will be insensetive to
 > intra-domain route flapping. 

   That's a pretty bold statement. Your sources for
   that are, what?

 > It 
 > is safe to assume that the ingress and egress routers of an intermediate 
 > network domain in the end-to-end path remain constant. So, it looks to me 
 > that fast signaling is still doable.

   Um, no. Not by a long shot. This is trivial:
   within the same provider, I move from one AS to
   another AS communicating to another AS. My
   egress/ingress to the new AS will change. In
   fact, the paths may be arbitrarily different.

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:06:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17051
	for ; Fri, 30 Mar 2001 17:06:29 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13184;
	Fri, 30 Mar 2001 14:06:07 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10914;
	Fri, 30 Mar 2001 14:06:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UM4eIm015679
	for ; Fri, 30 Mar 2001 14:04:40 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UM4ekR015678
	for mobile-ip-dist; Fri, 30 Mar 2001 14:04:40 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UM4VIm015671
	for ; Fri, 30 Mar 2001 14:04:31 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10311
	for ; Fri, 30 Mar 2001 14:04:30 -0800 (PST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26871
	for ; Fri, 30 Mar 2001 14:04:29 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA14704
	for ; Fri, 30 Mar 2001 14:04:29 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f2UM4Rp31320
	for ; Fri, 30 Mar 2001 14:04:27 -0800
X-mProtect:  Fri, 30 Mar 2001 14:04:27 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdI4X68g; Fri, 30 Mar 2001 14:03:54 PST
Message-ID: <3AC502C9.48F4CB70@iprg.nokia.com>
Date: Fri, 30 Mar 2001 14:03:53 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QoS Work Item
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hemant Chaskar wrote:

> >
> >Rajeev Koodli writes:
> >  > Hello Gabriel,
> >  >
> >  > I did make my 3 minute presentation. FYI, following were the key
> >points.
> >  >
> >  > 1. Any mobility-aware signaling protocol must be able to limit the
> >  > extent of signaling to only those nodes (in the packet stream path)
> >  > affected by mobility.
> >
> >    This is a tautology though. I believe that the
> >    desirable characteristic is that the QoS
> >    reestablishment converges locally. If we need
> >    to go clear back to the CN (which also fits
> >    your definition), speed of light considerations
> >    may produce unacceptible results.
>
> I disagree with this speed of light consideration. Speed of light
> "limitation" applies to both signaling packet and data packet. So a smart
> signaling scheme will put QoS signaling trigger before any data packet to
> overcome the speed of light or satellite propagation delay limitation. This
> is exactly why we cannot live with schemes that involve one round-trip
> latency in QoS programming. However, it is definitely possible to achieve
> fast response time even if we need to go clear back to the CN, I just
> describe how!
>
> >
> >  > 2. It must be able to provide fast response time. This includes how
> >  > quickly the protocol is able to detect that the mobile node has moved,
> >  > as well as the how fast the protocol itself is.
> >
> >    I'll just throw out here that damping
> >    mechanisms for route flapping are going
> >    to be problem.
>
> What is the probability that route flapping happens in the end-to-end path
> upon every handover? Also, modern techniques such as MPLS will greatly
> reduce route flapping. In modern QoS mechanisms such as DiffServ and MPLS,
> QoS signaling scheme will be insensetive to intra-domain route flapping. It
> is safe to assume that the ingress and egress routers of an intermediate
> network domain in the end-to-end path remain constant. So, it looks to me
> that fast signaling is still doable.
>
> >
> >  > 3. It should be able to make use of intrinsic IP mobility signaling.
> >
> >    This is a huge leap. In fact as it currently
> >    stands, there is no need for a mobile to have
> >    any mobility signaling local to its attachment
> >    point. That, if anything, argues for just the
> >    opposite: we should not explicitly link QoS
> >    signaling to mobility signaling.
> >
>

I don't follow you. Perhaps what I said was unclear. I said a mobile should be
able to make use of the natural point in time that IP detects mobility in order
to trigger and expedite the signaling process. I guess you are familiar with
our draft: there we make use of mobile IP signaling. What is this got to do
with a MN signaling to its local attachment point as you describe above ?

Regards,

-Rajeev





> >               Mike
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:32:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18022
	for ; Fri, 30 Mar 2001 17:32:51 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01865;
	Fri, 30 Mar 2001 14:32:32 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24428;
	Fri, 30 Mar 2001 14:32:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMTMIm015798
	for ; Fri, 30 Mar 2001 14:29:22 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UMTLOb015797
	for mobile-ip-dist; Fri, 30 Mar 2001 14:29:21 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMT9Im015787
	for ; Fri, 30 Mar 2001 14:29:10 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17786
	for ; Fri, 30 Mar 2001 14:29:10 -0800 (PST)
Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04795
	for ; Fri, 30 Mar 2001 14:29:09 -0800 (PST)
Received: from Kniveton.com (eldorado.kniveton.com [192.168.1.70])
	by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f2UMT2P20231
	for ; Fri, 30 Mar 2001 14:29:04 -0800 (PST)
Message-ID: <3AC508AA.16E66F9@Kniveton.com>
Date: Fri, 30 Mar 2001 14:28:59 -0800
From: "T.J. Kniveton" 
Organization: NOKIA Research
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se> <3AC3EBC6.A8B9C32C@Kniveton.com> <3AC45921.270FFB2F@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Thierry Ernst wrote:

>
> There is nothing to do with the routing protocol unless you want to
> update the routing tables of all nodes in the AS.    My draft proposes
> to use base Mobile IPv6, but we need an extension to specify to the HA
> that it should also encapsulate packets intended to nodes in the mobile
> network with prefix P2.
>
> Is this clearer ?
> Thierry

Yes, I see what you mean now. Thanks. There are a few problems here:

1. Section 9.6 says to "intercept any packets on the home link addressed to the
mobile node's home address," but doesn't talk about packets where the next hop is
the MR.
  - As Mattias noted, you should be able to insert an entry to the routing table,
through a tunneled RA, to map this prefix to the MN's link-local address, but that
brings us to problem 2:
2. Section 9.6 also says NOT to forward packets destined to the MN'S LL address.
When the MN is a MR, packets for the LL address really need to be forwarded.
  - We could potentially add a rule that the LL packets should be discarded
UNLESS the HA has a routing entry for this prefix to the MR. This is getting very
close to what your draft does.
3. Distributing prefix and routing information when you're away from home seems to
always be messy. What would happen according to your draft when the MR sends
prefix info to the HA, the HA inserts the prefix entry into its routing table, and
then the MN asks for prefix info ("tunneled" mobile RS) from the home agent and
gets that prefix back?

I agree this is a sticky situation, and it's hard to get MRs working, although I'm
open to the idea it may be possible with a few tweaks to the existing draft.

--
T.J. Kniveton
NOKIA Research



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:38:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18311
	for ; Fri, 30 Mar 2001 17:38:23 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01832;
	Fri, 30 Mar 2001 14:37:30 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25548;
	Fri, 30 Mar 2001 14:37:22 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMZsIm015839
	for ; Fri, 30 Mar 2001 14:35:54 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UMZrf6015838
	for mobile-ip-dist; Fri, 30 Mar 2001 14:35:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMZjIm015831
	for ; Fri, 30 Mar 2001 14:35:45 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UMYUm04281
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Mar 2001 14:34:30 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103302234.f2UMYUm04281@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <3AC4DAA4.E5B44641@inrialpes.fr> from Thierry Ernst at "Mar 30,
 2001 09:12:36 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 30 Mar 2001 14:34:30 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> > >       => Hopefully this would answer your previous comments
> > >       (that I removed).
> > >       When the HA forwards packets to MNs behind the MR,
> > >       it doesn't address thse packets to the MR. Since the MR
> > >       has "gone", no one is advertising reachability to it's
> > >       subnet. So the HA will not know what to do with it.
> > >       Thierry mentioned in his presentation that he proved
> > >       this case in thei labs.
> > 
> > When MR was at home it was advertising reachability and as soon
> > as it moved to the foreign link one would expect that to still
> > happen and this time,  tunneled to HA. If tunnel is yet another
> > interface, then  the reachability should be advertised, right ?
> > Why isn't this happening ?
> 
> Indeed, nothing should prevent the MR to advertise reachability to its
> the subnets behind it and nobody stated this.    Yes, advertisments
> should effectively be tunneled to HA.   (I can not remember if this is
> pointed out in the MIPv6 draft or not, or somewhere else;  could someone
> say where ?)
> 
> The problem comes from what it being recorded in the Binding Cache at
> the HA: nothing tells the HA to encapsulate packets sent to the
> mobile_network_prefix P2.   If some implementations do it, this is an
> interpretation of the MIPv6 specification and would add room for
> hacking:  why should the HA encapsulate packets sent to prefix P2 to the
> MR's coa if it wasn't instructed to do it ?
>
Agreed that the spec is not clear. HA is defending for "MR" and would
encapsualte packets only meant for MR's home address.  We need
HA to defend for the prefix(es) that is hidden behind MR. Having
the routing entries for those prefixes is not sufficient.

-mohan
> Any comments on what the HA should be allowed to do ?
> 
> 
> > If there were static routes on the Home agent, then this is
> > not a problem too. Just to make the picture clearer.
> 
> 
> Thierry.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:45:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18562
	for ; Fri, 30 Mar 2001 17:45:30 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10207;
	Fri, 30 Mar 2001 14:45:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22648;
	Fri, 30 Mar 2001 14:45:06 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMhbIm015864
	for ; Fri, 30 Mar 2001 14:43:38 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UMhbi0015863
	for mobile-ip-dist; Fri, 30 Mar 2001 14:43:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMhSIm015856
	for ; Fri, 30 Mar 2001 14:43:28 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22322
	for ; Fri, 30 Mar 2001 14:43:29 -0800 (PST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14342
	for ; Fri, 30 Mar 2001 14:43:27 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2UMhQs28247
	for ; Sat, 31 Mar 2001 00:43:26 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id AAA25923; Sat, 31 Mar 2001 00:43:24 +0200
Message-ID: <3AC50C3E.C38F31C5@era.ericsson.se>
Date: Sat, 31 Mar 2001 00:44:14 +0200
From: Mattias Pettersson 
Organization: Ericsson Radio Systems AB
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
	 <3AC3EBC6.A8B9C32C@Kniveton.com> <3AC45921.270FFB2F@inrialpes.fr>
	 <3AC49D6E.70BB3C84@era.ericsson.se> <3AC4D96C.84A92A3@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


Thierry Ernst wrote:
> 
> Hi,
> 
> Thanks to your comments, Mattias.
> 
> > I agree that the BU should express more, maybe a flag like "also forward
> > traffic destined to prefixes behind the MN".
> 
> I think this is not enough.   It would be better to explicitly specify
> the said prefix in the BU.    How would the HA knows what is the prefix
> behind the MR - I mean, how would it do this if you don't add anything
> in the MIPv6 spec and if you strickly follow the spec ?

If I read the spec word by word I would end up with my interpretation.
If I read behind the lines maybe I would miss this and think the HA
should only forward packets to the MN itself. I don't think the draft
should need special care for cooperation with every other protocol out
there. It should say as little as possible, with the correct wording.

> 
> > > > They are on the same link, so it seems like the HA is not picking up the
> > > > same routing info as the BR. This would be a configuration issue.
> > >
> > > You may configure your routing tables in a way that it works, but this
> > > is more like a hack.  MIPv6 does not says how to re-route a packet wich
> > > is not sent to the home address.
> >
> > But it says what to do with packets that have been intercepted. Please
> > see below.
> >
> > > The problem comes from the information carried in the Binding update
> > > which says "it destination = int0::/128 bits, encapsulate packet to the
> > > MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
> > > work, but you need to specify it in the spec.
> >
> > I agree that the spec is not 100% explicit on this. However, I see it
> > possible to interpret the spec as follows:
> 
> Hum, interpretation always leaves room for misunderstanding and
> misinterpretation ...
> 
> > The HA's intercepting function is to pick up packets destined to the
> > MN's layer 2 address. It's ND proxy function will see to that all nodes
> > on the home link map the MN's int0 layer 3 address to the HA's layer 2
> > address. This is done by NS/NA mechanisms.
> >
> > All routers on the home link should know, as you say, to forward packets
> > to P2::/64 to int0. They will end up in the HA. HA won't drop them,
> > since they are destined to it's layer 2 address.
> >
> > At least in BSD, next check in HA is to check if this is a packet to the
> > HA itself. Since it doesn't have the int0 address configured on one of
> > its interfaces, it will see if it is forwardable, or drop the packet.
> 
> Agreed.
> 
> > The HA will try to forward it, and would look in its routing tables. It
> > would have two interesting entries:
> >         dest P2::/64   use next-hop int0        (determine gateway)
> >         dest int0      use next-hop MN-tunnel   (determine interface and
> >                                                 layer 2 address)
> > It will end up sending it into the MN-tunnel.
> 
> Thanks for your clarification.
> 
> If I follow you, you mean that the HA already has all the necessary
> information in its routing table to do it right, but that some
> implementations might not do it.
> 
> I do not exaclty know how algorithms for searching the routing table
> really work, but I would think that finding an entry and then searching
> for a second one is rather complex and may end up in routing loops.  I
> am just wondering.

Well, if the MR is at home, what routing table entries would the HA
have? It should have one for the prefix P2::/64 being routed towards
layer 3 address of MR. If this is statically configured or learnt by
routing protocols wouldn't matter. If I am wrong on this please correct
me.
  Next, it would also have a neighbor cache entry for MR, in order to
map layer 3 address to a layer 2 address for delivery of the packet. In
the environment I'm familiar with (KAME) the neighbor cache is
integrated in the routing table, but this is a minor detial.
  Summary, two entries. Same as above, but now with a layer 2 address in
the second entry's next hop field instead of the tunnel pointer.

This has little to do with implementation. I can't see that you could go
around this behaviour in a correctly implemented IPv6 router (such as a
HA).

When the MR moves, the HA can't just wipe out all previous routing table
entries for the MR. It needs to just replace the neighbor cache entry
with the pointer to the tunnel.

Please note that the intercepting consists of two quite separate parts:
1. The ND proxy. To redirect neighbors layer 3 address resoltion to the
HA's layer 2 address.
2. The forwarding and encapsulation. Packets that appear in the routing
process of the HA that are not originated by the HA but destined to the
MR or the network behind the MR are simply forwarded (and ends up being
encapsulated). HA doesn't have to check whether packets are destined to
the network behind the MR by looking in its binding cache. It should
only look in its routing table. 

> 
> > This is not necessarily the exact behaviour of all implementations, but
> > I would like to see it as the correct conceptual behaviour.
> For sure, the FreeBSD's HA is getting confused.

Well, you actually need to be aware of this intended behaviour so that
it can be implemented the proper way. I would argue for a clearer
description in the draft.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:52:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18782
	for ; Fri, 30 Mar 2001 17:52:27 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07899;
	Fri, 30 Mar 2001 14:52:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24120;
	Fri, 30 Mar 2001 14:52:03 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMolIm015890
	for ; Fri, 30 Mar 2001 14:50:47 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UMokTU015889
	for mobile-ip-dist; Fri, 30 Mar 2001 14:50:46 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMobIm015882
	for ; Fri, 30 Mar 2001 14:50:38 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12946
	for ; Fri, 30 Mar 2001 14:50:38 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17814
	for ; Fri, 30 Mar 2001 15:50:37 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA26115
	for ; Fri, 30 Mar 2001 14:50:41 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ADH01827;
	Fri, 30 Mar 2001 14:50:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04073; Fri, 30 Mar 2001 14:50:36 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15045.3516.415464.529371@thomasm-u1.cisco.com>
Date: Fri, 30 Mar 2001 14:50:36 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <200103302234.f2UMYUm04281@locked.eng.sun.com>
References: <3AC4DAA4.E5B44641@inrialpes.fr>
	<200103302234.f2UMYUm04281@locked.eng.sun.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Mohan Parthasarathy writes:
 > > The problem comes from what it being recorded in the Binding Cache at
 > > the HA: nothing tells the HA to encapsulate packets sent to the
 > > mobile_network_prefix P2.   If some implementations do it, this is an
 > > interpretation of the MIPv6 specification and would add room for
 > > hacking:  why should the HA encapsulate packets sent to prefix P2 to the
 > > MR's coa if it wasn't instructed to do it ?
 > >
 > Agreed that the spec is not clear. HA is defending for "MR" and would
 > encapsualte packets only meant for MR's home address.  We need
 > HA to defend for the prefix(es) that is hidden behind MR. Having
 > the routing entries for those prefixes is not sufficient.

   I'm puzzled. I noticed that Theirry's subnet prefix
   is now in the mipv6 binding update in the -13
   draft. Thus, a binding update is nothing more
   or less than a routing update announcing new
   reachability of a given prefix. Normal longest
   prefix match algorithms would assumedly work
   as usual, right?

   Or am I misconstruing the issue?

      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 17:54:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18898
	for ; Fri, 30 Mar 2001 17:54:43 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16220;
	Fri, 30 Mar 2001 14:54:30 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24122;
	Fri, 30 Mar 2001 14:54:25 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMrFIm015915
	for ; Fri, 30 Mar 2001 14:53:15 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UMrEru015914
	for mobile-ip-dist; Fri, 30 Mar 2001 14:53:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UMr6Im015907
	for ; Fri, 30 Mar 2001 14:53:06 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24392
	for ; Fri, 30 Mar 2001 14:53:06 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18385
	for ; Fri, 30 Mar 2001 14:53:05 -0800 (PST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2UMr4I07884
	for ; Sat, 31 Mar 2001 00:53:04 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id AAA26155; Sat, 31 Mar 2001 00:53:02 +0200
Message-ID: <3AC50E81.DB4CF3BF@era.ericsson.se>
Date: Sat, 31 Mar 2001 00:53:53 +0200
From: Mattias Pettersson 
Organization: Ericsson Radio Systems AB
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se>
	 <3AC3EBC6.A8B9C32C@Kniveton.com> <3AC45921.270FFB2F@inrialpes.fr> <3AC508AA.16E66F9@Kniveton.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


"T.J. Kniveton" wrote:
> 
> Thierry Ernst wrote:
> 
> Yes, I see what you mean now. Thanks. There are a few problems here:
> 
> 1. Section 9.6 says to "intercept any packets on the home link addressed to the
> mobile node's home address," but doesn't talk about packets where the next hop is
> the MR.
>   - As Mattias noted, you should be able to insert an entry to the routing table,
> through a tunneled RA, to map this prefix to the MN's link-local address, but that
> brings us to problem 2:

I'm not so sure that that the MR should tunnel a RA to the HA. Do you
really mean that?

However, it's a whole lot better if the HA's route to P2::/64 uses MR
*global* address, instead of the link-local. It's possible, but maybe
routing protocols don't like other than link-locals.

/Mattias

> 2. Section 9.6 also says NOT to forward packets destined to the MN'S LL address.
> When the MN is a MR, packets for the LL address really need to be forwarded.
>   - We could potentially add a rule that the LL packets should be discarded
> UNLESS the HA has a routing entry for this prefix to the MR. This is getting very
> close to what your draft does.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:05:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19321
	for ; Fri, 30 Mar 2001 18:05:57 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12358;
	Fri, 30 Mar 2001 15:02:44 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15687;
	Fri, 30 Mar 2001 15:02:39 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UN1RIm015957
	for ; Fri, 30 Mar 2001 15:01:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UN1Q0u015955
	for mobile-ip-dist; Fri, 30 Mar 2001 15:01:26 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UN1GIm015944
	for ; Fri, 30 Mar 2001 15:01:16 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25749
	for ; Fri, 30 Mar 2001 15:01:17 -0800 (PST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22587
	for ; Fri, 30 Mar 2001 16:01:15 -0700 (MST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2UN1EI08734
	for ; Sat, 31 Mar 2001 01:01:14 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id BAA26386; Sat, 31 Mar 2001 01:01:12 +0200
Message-ID: <3AC5106A.1C3A4C1F@era.ericsson.se>
Date: Sat, 31 Mar 2001 01:02:02 +0200
From: Mattias Pettersson 
Organization: Ericsson Radio Systems AB
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en, sv
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
References: <200103302234.f2UMYUm04281@locked.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Mohan Parthasarathy wrote:

> Agreed that the spec is not clear. HA is defending for "MR" and would
> encapsualte packets only meant for MR's home address.  We need
> HA to defend for the prefix(es) that is hidden behind MR. Having
> the routing entries for those prefixes is not sufficient.

The entries in all routers on the home link saying that P2 is behind MR
just don't appear out of thin air. Prefixes are manually configured (or
maybe distributed by some fancy mechanism). Then routing protocols
propagate this information. But the prefix must be manually configured
first, at some point. There's no difference to how P2 was assigned to MR
no matter if MR is mobile or not.

I don't see why you would need to defend this prefix like you do e.g.
for DAD for the MR's home address.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:11:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19470
	for ; Fri, 30 Mar 2001 18:11:21 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26914;
	Fri, 30 Mar 2001 15:11:07 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02309;
	Fri, 30 Mar 2001 15:10:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UN99Im015983
	for ; Fri, 30 Mar 2001 15:09:10 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UN99sf015982
	for mobile-ip-dist; Fri, 30 Mar 2001 15:09:09 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UN8wIm015975
	for ; Fri, 30 Mar 2001 15:08:58 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16799
	for ; Fri, 30 Mar 2001 15:08:59 -0800 (PST)
From: rajeev.koodli@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25347
	for ; Fri, 30 Mar 2001 15:08:58 -0800 (PST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2UNB0w19271
	for ; Fri, 30 Mar 2001 17:11:00 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 30 Mar 2001 17:08:56 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id ; Fri, 30 Mar 2001 17:08:56 -0600
Message-ID: 
To: Lars-Erik.Jonsson@epl.ericsson.se, rajeev.koodli@nokia.com,
        zhigang.liu@nokia.com, micke@cs.arizona.edu,
        mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@cdma-2000.org
Subject: [mobile-ip] RE: [rohc] Compression startup behavior
Date: Fri, 30 Mar 2001 17:08:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> 
> Sorry that I forgot to say "unfortunately" in the beginning 
> of the sentence below...
> 

Sorry that it is unfortunate for you..

Regards,

-Rajeev

> Anyway, I do not care if someone wants to do context transfer 
> as part of the handover procedures used for certain 
> environments. Personally, I think it is overkill and makes 
> things more complicated, but that is not up to me to judge. 
> However, it is not a header compression issue.
> 
> /L-E
> 
> 
> > > > I guess that context transfer is a mechanism 
> > > > that will be developed (snip)
> > > 
> >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > This is a good starting position.
> > 
> > Regards,
> > 
> > -Rajeev
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:14:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19576
	for ; Fri, 30 Mar 2001 18:14:39 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16849;
	Fri, 30 Mar 2001 15:13:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17828;
	Fri, 30 Mar 2001 15:13:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNCIIm016007
	for ; Fri, 30 Mar 2001 15:12:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UNCICD016001
	for mobile-ip-dist; Fri, 30 Mar 2001 15:12:18 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNC8Im015994
	for ; Fri, 30 Mar 2001 15:12:08 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UNAr804306
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Mar 2001 15:10:53 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103302310.f2UNAr804306@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <15045.3516.415464.529371@thomasm-u1.cisco.com> from Michael Thomas
 at "Mar 30, 2001 02:50:36 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 30 Mar 2001 15:10:53 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Mohan Parthasarathy writes:
>  > > The problem comes from what it being recorded in the Binding Cache at
>  > > the HA: nothing tells the HA to encapsulate packets sent to the
>  > > mobile_network_prefix P2.   If some implementations do it, this is an
>  > > interpretation of the MIPv6 specification and would add room for
>  > > hacking:  why should the HA encapsulate packets sent to prefix P2 to the
>  > > MR's coa if it wasn't instructed to do it ?
>  > >
>  > Agreed that the spec is not clear. HA is defending for "MR" and would
>  > encapsualte packets only meant for MR's home address.  We need
>  > HA to defend for the prefix(es) that is hidden behind MR. Having
>  > the routing entries for those prefixes is not sufficient.
> 
>    I'm puzzled. I noticed that Theirry's subnet prefix
>    is now in the mipv6 binding update in the -13
>    draft. Thus, a binding update is nothing more
>    or less than a routing update announcing new
>    reachability of a given prefix. Normal longest
>    prefix match algorithms would assumedly work
>    as usual, right?
>
Could you point out the section ?

Binding update packets contain the home address option from which
you get the home address and a Care of Address either in the
source address or in a sub-option. It tells the home agent that
defend for this home address and tunnel the packet to the
care of address. In this case, it *will* tunnel only if it
sees a packet destined to MR's home address. In the example
described, the packet's destination address is not the
MR's home address. The only issue i have is, what tells
HA to tunnel this packet ?

-mohan 

>    Or am I misconstruing the issue?
> 
>       Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:23:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19871
	for ; Fri, 30 Mar 2001 18:23:33 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03999;
	Fri, 30 Mar 2001 15:23:20 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00408;
	Fri, 30 Mar 2001 15:23:14 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNLhIm016046
	for ; Fri, 30 Mar 2001 15:21:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UNLhJr016045
	for mobile-ip-dist; Fri, 30 Mar 2001 15:21:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNLYIm016037
	for ; Fri, 30 Mar 2001 15:21:34 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UNKLZ04315
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Mar 2001 15:20:21 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103302320.f2UNKLZ04315@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <200103302310.f2UNAr804306@locked.eng.sun.com> from Mohan Parthasarathy
 at "Mar 30, 2001 03:10:53 pm"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 30 Mar 2001 15:20:21 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> > Mohan Parthasarathy writes:
> >  > > The problem comes from what it being recorded in the Binding Cache at
> >  > > the HA: nothing tells the HA to encapsulate packets sent to the
> >  > > mobile_network_prefix P2.   If some implementations do it, this is an
> >  > > interpretation of the MIPv6 specification and would add room for
> >  > > hacking:  why should the HA encapsulate packets sent to prefix P2 to the
> >  > > MR's coa if it wasn't instructed to do it ?
> >  > >
> >  > Agreed that the spec is not clear. HA is defending for "MR" and would
> >  > encapsualte packets only meant for MR's home address.  We need
> >  > HA to defend for the prefix(es) that is hidden behind MR. Having
> >  > the routing entries for those prefixes is not sufficient.
> > 
> >    I'm puzzled. I noticed that Theirry's subnet prefix
> >    is now in the mipv6 binding update in the -13
> >    draft. Thus, a binding update is nothing more
> >    or less than a routing update announcing new
> >    reachability of a given prefix. Normal longest
> >    prefix match algorithms would assumedly work
> >    as usual, right?
> >
> Could you point out the section ?

There is a prefix length field. You are correct. But the definition
is slightly different. Home Agent forms other addresses using
the interface identifier present in the home address of the option.
But nothing says it defends for the prefix.

-mohan
> 
> Binding update packets contain the home address option from which
> you get the home address and a Care of Address either in the
> source address or in a sub-option. It tells the home agent that
> defend for this home address and tunnel the packet to the
> care of address. In this case, it *will* tunnel only if it
> sees a packet destined to MR's home address. In the example
> described, the packet's destination address is not the
> MR's home address. The only issue i have is, what tells
> HA to tunnel this packet ?
> 
> -mohan 
> 
> >    Or am I misconstruing the issue?
> > 
> >       Mike
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:34:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20274
	for ; Fri, 30 Mar 2001 18:34:23 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24511;
	Fri, 30 Mar 2001 15:34:08 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22295;
	Fri, 30 Mar 2001 15:34:01 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNWbIm016075
	for ; Fri, 30 Mar 2001 15:32:37 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UNWbTY016074
	for mobile-ip-dist; Fri, 30 Mar 2001 15:32:37 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNWSIm016067
	for ; Fri, 30 Mar 2001 15:32:29 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UNVF304329
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Mar 2001 15:31:15 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103302331.f2UNVF304329@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <3AC5106A.1C3A4C1F@era.ericsson.se> from Mattias Pettersson at "Mar
 31, 2001 01:02:02 am"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 30 Mar 2001 15:31:15 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> Mohan Parthasarathy wrote:
> 
> > Agreed that the spec is not clear. HA is defending for "MR" and would
> > encapsualte packets only meant for MR's home address.  We need
> > HA to defend for the prefix(es) that is hidden behind MR. Having
> > the routing entries for those prefixes is not sufficient.
> 
> The entries in all routers on the home link saying that P2 is behind MR
> just don't appear out of thin air. Prefixes are manually configured (or
> maybe distributed by some fancy mechanism). Then routing protocols
> propagate this information. But the prefix must be manually configured
> first, at some point. There's no difference to how P2 was assigned to MR
> no matter if MR is mobile or not.
>
I never said anything about prefixes appearing out of thin air.
I think the spec is not clear enough. So, just having the
routing information for all the prefixes behind MR is not
sufficient.

> I don't see why you would need to defend this prefix like you do e.g.
> for DAD for the MR's home address.
> 
Look at the steps involved :

1) MR moves to the foreign link and asks HA to defend for its home
   address.

2) Packet from some CN goes toward HA. Reading 9.5 and 9.6 sections
   of the draft says that it will encapsulate only for packets
   destined to the MR's home address. Any packet for which MR
   is the router, it will try to send it to MR. Hhmm MR itself is
   not home. So should it encapsualte ? But it is not defending
   for those addresses.

I agree that we can clarify the existing draft rather than having
another draft.

-mohan


From owner-mobile-ip@sunroof.eng.sun.com  Fri Mar 30 18:43:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20587
	for ; Fri, 30 Mar 2001 18:43:20 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15961;
	Fri, 30 Mar 2001 15:43:09 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04140;
	Fri, 30 Mar 2001 15:43:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNftIm016103
	for ; Fri, 30 Mar 2001 15:41:56 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2UNftip016102
	for mobile-ip-dist; Fri, 30 Mar 2001 15:41:55 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from locked.eng.sun.com (locked [129.146.85.189])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2UNflIm016095
	for ; Fri, 30 Mar 2001 15:41:47 -0800 (PST)
Received: (from mohanp@localhost)
	by locked.eng.sun.com (8.11.2+Sun/8.10.1) id f2UNeX404336
	for mobile-ip@sunroof.eng.sun.com; Fri, 30 Mar 2001 15:40:33 -0800 (PST)
From: Mohan Parthasarathy 
Message-Id: <200103302340.f2UNeX404336@locked.eng.sun.com>
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6
In-Reply-To: <3AC50C3E.C38F31C5@era.ericsson.se> from Mattias Pettersson at "Mar
 31, 2001 00:44:14 am"
To: mobile-ip@sunroof.eng.sun.com
Date: Fri, 30 Mar 2001 15:40:33 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> 
> > 
> > > > > They are on the same link, so it seems like the HA is not picking up the
> > > > > same routing info as the BR. This would be a configuration issue.
> > > >
> > > > You may configure your routing tables in a way that it works, but this
> > > > is more like a hack.  MIPv6 does not says how to re-route a packet wich
> > > > is not sent to the home address.
> > >
> > > But it says what to do with packets that have been intercepted. Please
> > > see below.
> > >
> > > > The problem comes from the information carried in the Binding update
> > > > which says "it destination = int0::/128 bits, encapsulate packet to the
> > > > MR's coa.  If you allow HA to redirect packets sent to a prefix, it will
> > > > work, but you need to specify it in the spec.
> > >
> > > I agree that the spec is not 100% explicit on this. However, I see it
> > > possible to interpret the spec as follows:
> > 
> > Hum, interpretation always leaves room for misunderstanding and
> > misinterpretation ...
> > 
> > > The HA's intercepting function is to pick up packets destined to the
> > > MN's layer 2 address. It's ND proxy function will see to that all nodes
> > > on the home link map the MN's int0 layer 3 address to the HA's layer 2
> > > address. This is done by NS/NA mechanisms.
> > >
> > > All routers on the home link should know, as you say, to forward packets
> > > to P2::/64 to int0. They will end up in the HA. HA won't drop them,
> > > since they are destined to it's layer 2 address.
> > >
> > > At least in BSD, next check in HA is to check if this is a packet to the
> > > HA itself. Since it doesn't have the int0 address configured on one of
> > > its interfaces, it will see if it is forwardable, or drop the packet.
> > 
> > Agreed.
> > 
> > > The HA will try to forward it, and would look in its routing tables. It
> > > would have two interesting entries:
> > >         dest P2::/64   use next-hop int0        (determine gateway)
> > >         dest int0      use next-hop MN-tunnel   (determine interface and
> > >                                                 layer 2 address)
> > > It will end up sending it into the MN-tunnel.
> > 
> > Thanks for your clarification.
> > 
> > If I follow you, you mean that the HA already has all the necessary
> > information in its routing table to do it right, but that some
> > implementations might not do it.
> > 
> > I do not exaclty know how algorithms for searching the routing table
> > really work, but I would think that finding an entry and then searching
> > for a second one is rather complex and may end up in routing loops.  I
> > am just wondering.
> 
> Well, if the MR is at home, what routing table entries would the HA
> have? It should have one for the prefix P2::/64 being routed towards
> layer 3 address of MR. If this is statically configured or learnt by
> routing protocols wouldn't matter. If I am wrong on this please correct
> me.
>   Next, it would also have a neighbor cache entry for MR, in order to
> map layer 3 address to a layer 2 address for delivery of the packet. In
> the environment I'm familiar with (KAME) the neighbor cache is
> integrated in the routing table, but this is a minor detial.
>   Summary, two entries. Same as above, but now with a layer 2 address in
> the second entry's next hop field instead of the tunnel pointer.
> 
> This has little to do with implementation. I can't see that you could go
> around this behaviour in a correctly implemented IPv6 router (such as a
> HA).
> 
> When the MR moves, the HA can't just wipe out all previous routing table
> entries for the MR. It needs to just replace the neighbor cache entry
> with the pointer to the tunnel.
>
Ok, this made it clear. I think it should work automatically. But
still, one can make this clear in the draft i guess.

-mohan

> Please note that the intercepting consists of two quite separate parts:
> 1. The ND proxy. To redirect neighbors layer 3 address resoltion to the
> HA's layer 2 address.
> 2. The forwarding and encapsulation. Packets that appear in the routing
> process of the HA that are not originated by the HA but destined to the
> MR or the network behind the MR are simply forwarded (and ends up being
> encapsulated). HA doesn't have to check whether packets are destined to
> the network behind the MR by looking in its binding cache. It should
> only look in its routing table. 
> 
> > 
> > > This is not necessarily the exact behaviour of all implementations, but
> > > I would like to see it as the correct conceptual behaviour.
> > For sure, the FreeBSD's HA is getting confused.
> 
> Well, you actually need to be aware of this intended behaviour so that
> it can be implemented the proper way. I would argue for a clearer
> description in the draft.
> 
> /Mattias



From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 31 05:02:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18015
	for ; Sat, 31 Mar 2001 05:02:48 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28340;
	Sat, 31 Mar 2001 02:02:37 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02760;
	Sat, 31 Mar 2001 02:02:28 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VA1KIm016683
	for ; Sat, 31 Mar 2001 02:01:20 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2VA1JxJ016682
	for mobile-ip-dist; Sat, 31 Mar 2001 02:01:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VA19Im016675
	for ; Sat, 31 Mar 2001 02:01:09 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02654
	for ; Sat, 31 Mar 2001 02:01:08 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29542
	for ; Sat, 31 Mar 2001 02:01:07 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2VA15d42821;
	Sat, 31 Mar 2001 11:01:05 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA02133;
	Sat, 31 Mar 2001 12:01:04 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2VA13A93616;
	Sat, 31 Mar 2001 12:01:03 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103311001.f2VA13A93616@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
cc: Pekka Nikander 
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Tue, 27 Mar 2001 13:06:26 -0800.
              
Date: Sat, 31 Mar 2001 12:01:03 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > => we can do something better: send a part of needed things directly
   > to the care-of address and the remainder to the home address (through
   > the home agent) so the MN will need to get the traffic from both paths
   > (and the MITM will need to intercept the traffic on both paths).
   
   While such complexity helps for some threats it doesn't deal with
   MITM positioned close to the CN.

=> if the MITM is close to the CN IMHO only a global PKI can help
and we may not assume this is available.

   But we can't do much about that threat since the CN doesn't have any 
   prestablished association with the HA or MN.
   
=> exactly.

   The most important threat to handle (that we can handle) is MITM
   attacks on the MNs link.
   
=> the ESP on the HA->MN tunnel idea gives a good way to handle this.
I have more detailed idea about a solution but I have more to 1000 mails
to read too (:-)...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 31 05:37:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20930
	for ; Sat, 31 Mar 2001 05:37:18 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01436;
	Sat, 31 Mar 2001 02:37:02 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02771;
	Sat, 31 Mar 2001 02:36:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VAZDIm016721
	for ; Sat, 31 Mar 2001 02:35:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2VAZDMU016720
	for mobile-ip-dist; Sat, 31 Mar 2001 02:35:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VAZ4Im016713
	for ; Sat, 31 Mar 2001 02:35:05 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03930
	for ; Sat, 31 Mar 2001 02:35:04 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04855
	for ; Sat, 31 Mar 2001 02:35:02 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2VAZ1d27129
	for ; Sat, 31 Mar 2001 11:35:01 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA02290
	for ; Sat, 31 Mar 2001 12:35:00 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2VAZ0A93690
	for ; Sat, 31 Mar 2001 12:35:00 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103311035.f2VAZ0A93690@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Drafty draft about key establishment for Binding Update 
In-reply-to: Your message of Tue, 27 Mar 2001 14:05:39 -0800.
             <200103272206.f2RM6rxf401271@jurassic.eng.sun.com> 
Date: Sat, 31 Mar 2001 12:35:00 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   From RFC 2408, ISAKMP, section 1.7.3,
   
   Man in the middle attacks include interception, insertion, deletion,
   and modification of messages, reflecting messages back at the
   sender, replaying old messages and redirecting messages.
   
   Do we want all this protection ?

=> There are three segments (MN-CN, MN-HA and HA-CN) where the MITM can be.
My idea (split messages on MN-CN and MN-HA-CN) protects against a MITM
which is not on both paths. Drafty draft idea (protect MN-HA tunnel)
makes this a bit stronger: the MITM must be on MN-CN and HA-CN segments
(ie. close to the CN).
Summary:
 - no protection, signaling via MN-CN: MN-CN vulnerable.
 - no protection, signaling via HA: MN-HA-CN vulnerable.
 - drafty draft (signaling via HA): HA-CN vulnerable.
 - split signaling: MN-CN+MN-HA-CN vulnerable.
 - split signaling+drafty draft: MN-CN+HA-CN vulnerable.
If MITM close to the MN must be safe then the drafty draft idea must be used.

   I am not sure how long/easy is to analyse all this once
   we have a solution ?

=> just do it in order to know ?

   I think ISAKMP/IKE seems to be safe from all the above.

=> ISAKMP/IKE uses Diffie-Hellman with strong authentication so it is as
safe as the Diffie-Hellman (ie. large enough groups) and the strong
authentication are. I believe the strong authentication with PKIs is
the most easy to attack (reuse the recent attacks against SSL: provide
a fake DNS (for names/identities) and a fake LDAP (for certificates)
to a peer. In our case the vulnerability is again with an attacker close
to the CN... Previous MIPv6 security is vulnerable to this kind of attacks
on both ends (CN and MN) and a global PKI is by definition more vulnerable
so the new MIPv6 security can be more vulnerable in some points (MITM
close to CN more easy) and less vulnerable in some other points (because
the MN-HA interaction is easier to protect than MN-CN's one for a random CN).
This different trade-off is IMHO a good answer to IESG concerns...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 31 05:49:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21895
	for ; Sat, 31 Mar 2001 05:49:04 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02639;
	Sat, 31 Mar 2001 02:48:51 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03234;
	Sat, 31 Mar 2001 02:48:43 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VAlAIm016752
	for ; Sat, 31 Mar 2001 02:47:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2VAlADX016751
	for mobile-ip-dist; Sat, 31 Mar 2001 02:47:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VAl1Im016744
	for ; Sat, 31 Mar 2001 02:47:01 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18561
	for ; Sat, 31 Mar 2001 02:47:01 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06816
	for ; Sat, 31 Mar 2001 02:47:00 -0800 (PST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2VAkwd15193
	for ; Sat, 31 Mar 2001 11:46:58 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA02336
	for ; Sat, 31 Mar 2001 12:46:57 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2VAkvA93733
	for ; Sat, 31 Mar 2001 12:46:57 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103311046.f2VAkvA93733@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ... 
In-reply-to: Your message of Tue, 27 Mar 2001 14:23:43 -0800.
             <01ff01c0b70c$9600cfa0$2000a8c0@dellchan> 
Date: Sat, 31 Mar 2001 12:46:57 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Which brings me to another thought.  Do we want different mechanisms for
   different cases.

=> I believe we need some kind of negotiation.

   Talking to yahoo.com is completely different from talking
   to my PC at home or my corporate VPN.

=> I agree: in the second case we have public/private key pairs and
not be able to use them would be silly.

   Not sure one size fits all applies, though I have no idea what the practical
   implications of the brilliantly pedantic observation are...
   
=> two exchanges: the first one with cookies (DoS protection) and proposals,
the second one with the crypto stuff negociated in the first exchange.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 31 08:28:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04057
	for ; Sat, 31 Mar 2001 08:28:01 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14554;
	Sat, 31 Mar 2001 05:27:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08830;
	Sat, 31 Mar 2001 05:27:17 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VDPmIm016878
	for ; Sat, 31 Mar 2001 05:25:49 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2VDPmZg016877
	for mobile-ip-dist; Sat, 31 Mar 2001 05:25:48 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VDPeIm016870
	for ; Sat, 31 Mar 2001 05:25:40 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23940
	for ; Sat, 31 Mar 2001 05:25:38 -0800 (PST)
Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14102
	for ; Sat, 31 Mar 2001 05:25:37 -0800 (PST)
Received: from Kniveton.com (eldorado.kniveton.com [192.168.1.70])
	by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f2VDPWP23359
	for ; Sat, 31 Mar 2001 05:25:33 -0800 (PST)
Message-ID: <3AC5DAC6.B144938F@Kniveton.com>
Date: Sat, 31 Mar 2001 05:25:27 -0800
From: "T.J. Kniveton" 
Organization: NOKIA Research
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile Prefix Advertisements
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

At IETF50, I presented some problems with Network Renumbering and
Tunneled Router Advertisements, and also presented a solution that had
been discussed on this mailing list -- namely, to create a new ICMP type
for transporting prefix info from home link router advertisements to the
mobile node away from home.

So far, this idea is generally agreed upon as a reasonable solution, so
I am hoping people are open to trying this out. I have just finished
writing proposed changes to the Mobile IPv6 draft which..
1. incorporate these new ICMP types
2. clean up the text in the renumbering section to make it easier to
understand, and
3. simplify and re-evaluate rules and streamline the specified mechanism
a bit
4. keep as much of what was there as possible

Although there is still more work to get this right, I put these files
on my web site so people can take a look. Please point out errors, and
especially glaring problems, or make suggestions, whatever..

http://www.kniveton.com/tj/specs/

The resultant file is MIPv6-13tj2.txt -- my suggestion on how to look at
these changes would be download MIPv6-13.txt (the original draft) and
MIPv6-13tj2.txt, and run "Compare Two Files" under xemacs's Tools menu.

--
T.J. Kniveton
NOKIA Research




From owner-mobile-ip@sunroof.eng.sun.com  Sat Mar 31 08:32:48 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04474
	for ; Sat, 31 Mar 2001 08:32:48 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17346;
	Sat, 31 Mar 2001 05:32:36 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09370;
	Sat, 31 Mar 2001 05:32:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VDVXIm016937
	for ; Sat, 31 Mar 2001 05:31:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f2VDVW6f016936
	for mobile-ip-dist; Sat, 31 Mar 2001 05:31:32 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f2VDVOIm016929
	for ; Sat, 31 Mar 2001 05:31:24 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09241
	for ; Sat, 31 Mar 2001 05:31:24 -0800 (PST)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18319
	for ; Sat, 31 Mar 2001 06:31:23 -0700 (MST)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2VDVLd27112
	for ; Sat, 31 Mar 2001 14:31:22 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA02928
	for ; Sat, 31 Mar 2001 15:31:21 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f2VDVKA95148
	for ; Sat, 31 Mar 2001 15:31:20 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200103311331.f2VDVKA95148@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Netwoks in MIPv6 
In-reply-to: Your message of Fri, 30 Mar 2001 02:14:11 +0200.
             <034BEFD03799D411A59F00508BDF7546013DBD04@esealnt448.al.sw.ericsson.se> 
Date: Sat, 31 Mar 2001 15:31:20 +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

If one of the questions is this draft (draft-ernst-mobileip-v6-network-01.txt)
should be a WG draft I vote in favor of this.

Regards

Francis.Dupont@enst-bretagne.fr